Bunny on GitHub

Built in the open.

Explore the open-source direction of Bunny Financial, review protocol components, follow technical development and understand how code, documentation and releases connect across the ecosystem.

Explore Repositories Read Documentation

Review code independently before relying on any deployment.

Open Repository

Development model Open and documented

bunny.protocol main

// Bunny Financial architecture interface: wallet_based; exchange: decentralized; liquidity: transparent; settlement: on_chain; development: open_source;

Protocol Contracts Core blockchain logic

Code

Bunny Interface User application components

App

Developer Resources Integration references

Build

View Repository Structure

01 Inspectable

Technical components can be reviewed beyond the visible interface.

02 Versioned

Changes can be organized through documented development history.

03 Collaborative

Developers can discuss improvements and contribute through review.

04 Documented

Code should be supported by clear architecture and usage information.

Why open source matters

Verification should extend beyond the interface.

DeFi users interact with interfaces, wallets and smart contracts. Open-source development allows technical participants to examine how those components are intended to connect.

GitHub provides a structured environment for publishing source code, documenting technical decisions, discussing issues and reviewing changes before they become part of a release.

Public code does not automatically guarantee security. It creates an opportunity for independent inspection, testing and discussion, but users should still verify deployed contracts and official releases.

Repository structure

Separate components with clear responsibilities.

Bunny development resources are organized by function so developers can distinguish protocol logic, interface code, integration resources and supporting documentation.

01 / PROTOCOL

Protocol Contracts

Smart-contract architecture and blockchain logic supporting compatible Bunny protocol functions, including exchange, liquidity and related on-chain interactions.

Smart contracts Protocol logic Blockchain

02 / INTERFACE

Bunny Interface

Application components responsible for presenting protocol information, preparing wallet requests and organizing user-facing DeFi workflows.

Application Wallet access User interface

03 / INTEGRATION

Integration Resources

Developer-facing references for understanding supported interfaces, data structures, protocol connections and application integration concepts.

Developers Integration References

04 / DOCUMENTATION

Technical Documentation

Architecture explanations, development conventions, protocol concepts and practical information supporting technical review and responsible use.

Architecture Guides Standards

Review workflow

From repository discovery to verified deployment.

Find the official source

Access repositories only through the verified Bunny website or official technical documentation. Avoid copied repositories and links distributed by unknown accounts.

Identify the component

Determine whether the repository contains smart contracts, application code, integration resources or documentation.

Review the development history

Inspect branches, commits, release notes and issue discussions to understand how the component has changed over time.

Test independently

Developers should review dependencies, run available tests and use controlled environments before relying on the code.

Verify the deployed version

Repository code and a live blockchain deployment are not automatically identical. Confirm deployed contract addresses and relevant version information.

Report findings responsibly

Submit code improvements through the documented contribution process and report potential security issues privately.

Interface repositories User layer

Application

Wallet UX

Data Views

Integration resources Connection layer

Interfaces

Data Models

Examples

Protocol repositories Logic layer

Contracts

Tests

Deployment

Documentation Knowledge layer

Architecture

Security

Guides

Development architecture

Code, interfaces and documentation should remain distinguishable.

Separating project components helps reviewers understand where transaction logic is defined, where user information is presented and where integration assumptions are documented.

01
Interface code
Presents protocol functions and prepares requests for compatible wallets.
02
Integration resources
Help external developers understand supported technical connections and data structures.
03
Protocol contracts
Define executable blockchain rules for relevant decentralized interactions.
04
Documentation
Explains intended architecture, development conventions, risks and review procedures.

Open-source principles

Transparency requires more than public files.

A useful open-source project also needs readable structure, version history, documentation, review standards and a clear process for technical discussion.

01 / READABILITY

Understandable structure

Repositories should separate major responsibilities and provide enough context for reviewers to navigate the project.

02 / HISTORY

Visible changes

Commit history and release information help reviewers understand how code changed and which decisions affected a version.

03 / TESTING

Reproducible checks

Tests and development instructions make it easier to examine expected behavior in a controlled environment.

04 / DOCUMENTATION

Architecture context

Code should be accompanied by explanations of component roles, dependencies and intended integration.

05 / REVIEW

Discussable decisions

Issue tracking and pull-request review create a visible process for examining changes and technical proposals.

06 / SECURITY

Responsible reporting

Potential vulnerabilities should follow a private disclosure process before exploitable details are published.

Version and release model

A repository branch is not automatically a production release.

Development code may be incomplete, experimental or different from a deployed contract. Users and integrators should verify the exact release and deployment they intend to use.

Proposal

A change or improvement is described for discussion.

Development

The proposed implementation is prepared in code.

Review

Changes, tests and assumptions are examined.

Release

An identified version is prepared for intended use.

Verification

Deployment details are matched with the relevant version.

Community contributions

Contribute with context, tests and clear reasoning.

Useful contributions can include code improvements, documentation, testing, issue reports and technical research. Each contribution should identify the problem and explain the intended result.

Submitting a proposal does not guarantee that it will be merged or included in a release. Changes must be evaluated for technical quality, security, compatibility and relevance to the protocol.

Read Developer Documentation

Contribution checklist

Identify the affected component
Explain the problem being addressed
Keep changes limited and reviewable
Include relevant tests or verification steps
Document new assumptions or dependencies
Avoid including private credentials or secrets
Follow repository formatting conventions
Use private channels for security findings

Open-source boundaries

Public code supports review, but does not remove risk.

Repositories, deployed contracts and user interfaces are related but distinct. Each element should be verified independently.

Open source can support

Inspection, testing and technical discussion.

Independent review of published source code
Visible discussion of proposed changes
Testing in controlled development environments
Documentation of architecture and interfaces
Community contributions and issue reports
Comparison between identified versions

Open source cannot guarantee

Security, deployment identity or financial performance.

That published code contains no vulnerabilities
That a live deployment matches a repository branch
That third-party copies are authentic or safe
That every dependency behaves as expected
That blockchain transactions can be reversed
That protocol activity will produce a profit

Security disclosure

Do not publish an exploitable vulnerability before review.

Security findings should be submitted privately through the official Bunny contact process. A useful report explains the affected component, reproduction steps, possible impact and supporting technical evidence.

Report Security Issue Read Security Guide

Responsible report structure

Component

Identify the repository, contract or interface involved.

Reproduction

Provide controlled steps that demonstrate the issue.

Impact

Explain the users, assets or functions potentially affected.

Evidence

Include logs, transaction data or relevant code references.

GitHub FAQ

Common questions about Bunny open-source development.

Why does Bunny use GitHub?

GitHub provides tools for publishing source code, tracking changes, discussing issues, reviewing proposed contributions and maintaining technical documentation.

Does public code guarantee that Bunny is secure?

No. Public code supports independent review, but it does not guarantee that every vulnerability, unsafe dependency or configuration issue has been identified.

How can I verify an official Bunny repository?

Use repository links published through the official Bunny website and technical documentation. Avoid repositories shared only through unsolicited messages or unknown social accounts.

Is repository code identical to a deployed contract?

Not automatically. Development branches may contain unreleased or experimental code. The relevant version and live blockchain deployment should be verified independently.

Can developers contribute to Bunny?

Developers may propose code, tests, documentation or issue reports through the documented contribution process. Every proposal remains subject to technical and security review.

Where should I report a security vulnerability?

Use the official private contact process described by Bunny. Do not publish exploitable details in a public issue before the finding has been reviewed.

Can I use Bunny code in my own application?

Any use depends on the license, repository terms, technical compatibility and security requirements associated with the specific component. Review those conditions before integration.

Does GitHub contain wallet recovery or private access information?

It should not. Private keys, recovery phrases, production secrets and confidential credentials must never be published in a repository or shared through a contribution.

Explore Bunny development

Review the architecture before building an integration.

Explore the repository structure or continue to the technical documentation for protocol architecture and integration concepts.

Explore Repositories Read Documentation