Read the code. Build on it.
The source is open, the API is public, and patches are welcome. Whether you want to ship a tool on the chain, sharpen the node, write tests, or just see how the thing works — this is where you start.
Four ways in
Read-only REST API
Pull blocks, transactions, addresses, and network status over a plain JSON API. No auth on read-only endpoints. The full reference and live examples sit in the developer docs.
API docs →Run a node
The full node is what everything else stands on. Run one locally on regtest, testnet, or — when it's live — mainnet. Point your app at your own node and stop depending on a shared endpoint.
Node setup guide →Source & tests
The full source is on GitHub. Clone it, run the tests, open a pull request. Good first moves: add test coverage, file a bug with a clean reproduction, or fix the build docs.
GitHub →Design records (ADRs)
Architecture decision records capture every major protocol call — address format, fee cap, block time, emission schedule, and more, with the reasoning attached. Read them before you touch consensus code.
Browse ADRs →Query the chain in one line
The public seed node exposes a read-only JSON API. No API key, no account, just HTTP. Every response comes back in the same {"status": "success", ...} envelope.
curl https://moonbite.org/api/status
# Latest block
curl https://moonbite.org/api/block/latest
# Block by height
curl https://moonbite.org/api/block/1000
# Transaction by txid
curl https://moonbite.org/api/tx/<txid>
# Address balance & history
curl https://moonbite.org/api/address/moon1youraddresshere
The full endpoint list, request and response shapes, and error codes are all in the developer reference.
How to contribute
Standard open-source workflow, no surprises. Here's the short version.
Fork & clone
Fork the repo on GitHub, clone it locally, cut a feature branch. Keep branches tight — one concern per pull request, not five.
Run the tests
There's a test suite. Run it before and after your change. A patch that breaks existing tests won't merge, and new behaviour should ship with new tests.
Open a pull request
Say what the change does and why. Link the related issue. A tight, honest PR description gets reviewed a lot faster than a vague one.
File bugs
Found something broken? Open a GitHub issue with a clear reproduction. Include the platform, the node version, and the exact steps that trigger it.
Improve docs
Docs PRs count just as much as code PRs. A clearer setup guide, a better API example, a fixed typo — all of it matters.
Review open PRs
Reviewing someone else's pull request — spotting edge cases, checking the logic, running it locally — is one of the most valuable things you can do here.
Good places to begin
Understand the design
Before you write code that touches consensus or protocol logic, read the ADRs. They tell you not just what was decided but why — and that context is how you avoid quietly reintroducing an old bug.
ADRs on GitHub →Read the whitepaper
The whitepaper lays out the high-level goals and protocol properties MoonBite is built around. Read it alongside the ADRs to get the intent behind the details.
Whitepaper →Explore the API first
Building an app rather than hacking on the node? The REST API is the fastest path to real data. No build toolchain to fight — just HTTP.
Developer reference →Run regtest locally
Regtest lets you mine blocks instantly and test transactions without ever touching the live network. It's the right sandbox for development and integration work.
Node guide →Get pinged on real milestones
One email when something technical actually ships — new API endpoints, node releases, mainnet launch. No noise in between.
We'll only email you about the exchange listing. No price predictions, no spam.