GitHub
Source, issues, pull requests and releases. The only place code changes happen.
Animica is developed in the open by a small group of maintainers with contributions from miners, node operators and developers. There is no foundation forum, Discord or Telegram at the moment; the working channels are GitHub and X, and protocol changes follow a written proposal process.
Source, issues, pull requests and releases. The only place code changes happen.
Bug reports, feature requests and proposal issues (the first step of an AIP).
Release announcements, fork activation notices and outage reports.
Anything that should not be public. Security reports go to security@animica.org.
Anyone claiming to be "Animica support" on a chat platform is not. We never ask for seed phrases or payments.
Changes to parameters, policies and consensus go through Animica Improvement Proposals, documented
in docs/governance/COMMUNITY.md. The path is: open a short proposal issue stating the
problem, the type of change (parameter, policy, upgrade, registry, process) and the risk level, and
collect feedback for at least 72 hours; open an RFC pull request with an AIP-#### id,
rationale, alternatives, success metrics and a rollback plan; a review window of 7 days (14 for
high-risk changes or upgrades) with security, economics and operations reviewers; a 5-day last
call; then, if accepted, a signed governance bundle scheduled for a target height. After activation
the proposal becomes "Enacted" and an impact review is published within 14 days. Parameter changes
can be made without a hard fork; anything touching encoding, state layout or consensus behaviour
ships as a versioned release with a height gate, which is how every mainnet fork so far has been
delivered.
| What | How |
|---|---|
| Code | Pick an issue, keep the PR scoped to one module, write tests under <module>/tests/, run ./testall.sh, and read the relevant spec/ file before touching consensus, execution or wire formats. |
| Documentation | docs/ is CC BY-SA 4.0. Corrections and clarifications are the most welcome PRs; the repo root is full of historical work logs that are not canonical, so improve docs/ and module READMEs. |
| Hashrate | Point a miner at pool.animica.org:3333 (PPS) or :3334 (solo), or run animica up. Every block you find is one more independent confirmation of the chain. |
| Nodes | Run a full node with inbound port 30333 open. More independent nodes mean more peers for everyone and less reliance on the hosted RPC. |
| Compute | Serve inference with animica miner aicf-worker start, or run ENA useful-work jobs on a CPU. Both pay in ANM. |
| Wallet integrations | Third-party wallets can add Animica by following docs/wallet/HD_DERIVATION.md (coin type 4279885) and the bech32m address rules; we answer integration questions by email. |
docs/legal/TRADEMARKS.md).
The monorepo is large, and the root directory contains hundreds of historical work-log files
(*_SUMMARY.md, *_FIX*.md) that are not canonical documentation. The
sources that matter are spec/ (schemas, wire formats, PoIES maths and parameters),
docs/ (guides, with docs/ANIMICA_2026_STATE.md as the authority when
older pages disagree), and each module's README.md. The node lives in
core/, consensus/, execution/, mempool/,
p2p/ and rpc/; contracts in vm_py/ and contracts/;
the L2 in l2/; AI compute in aicf/ and capabilities/; the
PyPI package in python/; wallets in wallet/, wallet-qt/ and
wallet-extension/; the explorer in explorer2/; the pool in
animica-pool/; and this site in website/. There is no
pyproject.toml at the root: run ./setup.sh, which creates a virtualenv and
installs the SDK, the python/ package and the pure-Python PQ backend in the right order.
Tests run with ./testall.sh (pytest across modules, cargo tests for the native crates,
pnpm workspaces, ruff). A fast smoke run is pytest -m "not slow and not integration" -q.
Consensus and execution code must stay pure: no I/O, no clock, no ambient randomness, canonical
CBOR for serialisation, and fixed-point micro-nat maths. A PR that changes a wire format without
updating spec/ will be asked to justify it.
New contributors get the most out of the introduction, the
mining guide, the node guide and
the glossary. Developers should start with the
developer hub and AGENTS.md in the repository, which is the
canonical orientation for both humans and coding agents.
docs/governance/COMMUNITY.md · docs/governance/OVERVIEW.md · AGENTS.md · CONTRIBUTING.md · docs/legal/TRADEMARKS.md · website/src/config/site.ts