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.
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 →The full node is what everything else stands on. Run one locally on regtest, testnet, or the live mainnet. Point your app at your own node and stop depending on a shared endpoint.
Node setup guide →The full source is at moonbite.org/git. Clone it, run the tests, send a patch. Good first moves: add test coverage, file a bug with a clean reproduction, or fix the build docs.
Source →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 →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.
The full endpoint list, request and response shapes, and error codes are all in the developer reference.
Standard open-source workflow, no surprises. Here's the short version.
Clone the repository from moonbite.org/git, cut a feature branch. Keep branches tight — one concern per patch, not five.
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.
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.
Found something broken? Email support@moonbite.org with a clear reproduction. Include the platform, the node version, and the exact steps that trigger it.
Docs PRs count just as much as code PRs. A clearer setup guide, a better API example, a fixed typo — all of it matters.
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.
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.
Decision records →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 →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 →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 →