01Security
What an attacker can reach from outside, what they can reach once inside, and what happens to everything else when one part fails. Anything handling untrusted input is read as though the input is hostile, because eventually it will be.
Found something[email protected], read by a person.Seven passes.
Seven passes.
Still not finished.
Everything that moves value gets an independent audit before mainnet. Until that audit is back, the component cannot show as finished on the build tracker, no matter how many of our own passes it has been through.
That rule lives in the code that computes the number rather than in our good intentions, because a team that has just spent three weeks reviewing something is the least reliable judge of whether it is ready.
- Awaiting audit
- 16
- components, computed live
- Audits returned
- None yet
- there is nothing to audit yet
- Internal passes
- Seven
- before anything is called done
- First response
- 72 hours
- then weekly until it closes
Reporting something
Email us. Do not open an issue.
[email protected] is the one channel that stays open while the rest of the organization is closed to outside contributions, and it is read by a person rather than a form.
Include
- What you found, in whatever detail you have
- How to reproduce it, or the closest you got
- Which repository and which commit
- Your own read on the impact, even if you are unsure
What happens next
- Acknowledgement within 72 hours, from a person
- A status update at least weekly until it closes
- Credit in the changelog entry, unless you would rather not
- No legal threats for good-faith research reported here
A standing bounty program is announced before mainnet. Anything reported before then stays eligible for retroactive recognition and payment, so there is no advantage in sitting on a finding until the program opens. Please do not test against anything you do not control, and please do not go looking in other people's wallets to prove a point.
The seven passes
What every unit goes through before we stop working on it
Findings are recorded for each pass, including the ones that found nothing, because a pass that never reports anything is a pass somebody has quietly stopped running.
02Privacy
What is being stored, whether it needed to be, and what it would reveal if the store leaked. The strongest answer to a data-breach question is not having the data, so the pass keeps asking why each field exists at all.
03Engineering quality
Whether the thing is understandable by somebody who did not write it. Unreadable code is a security problem on a delay: it is where bugs hide from review and where the next person breaks something without knowing they did.
04Consensus and protocol safety
The invariants that cannot bend. No double spend under any order blocks might arrive in, difficulty that cannot go negative or swing wildly on one lane, and a chain that behaves the same on two independent implementations.
05Smart contract security
Reentrancy, arithmetic, access control, upgrade paths, and what an attacker with a flash loan and no scruples can do with the thing in a single transaction. Standard ground, covered because it is standard and still catches people.
06Economic and incentive design
Whether anybody is paid more for behaving badly than for behaving well. A contract can be flawless and still be a bad idea if the cheapest strategy available to a participant is the one that hurts everyone else.
07Whether it still matches what we said
The boundaries on this site are claims, and code drifts. This pass exists to catch the version of us that quietly widens a scope, and it fails the unit if the code no longer matches the page describing it.
Tests come first, and for some things examples are not enough
Tests are written before the implementation, which is ordinary practice. What is less ordinary is that for anything touching consensus, cryptography or money, an example-based test is not accepted as sufficient on its own. Examples prove the cases somebody thought of, and the cases somebody thought of are not where these bugs live.
Those components get property-based and fuzz testing pointed at the invariants themselves, which is to say at the statements that must hold for every input rather than for the inputs we imagined:
- no double spend, under any order blocks arrive in
- difficulty never goes negative, and no lane swings past its cap
- a payout only executes on a genuine majority, never on a tie
- the safety valve reaches its two components and nothing else
- supply never exceeds the cap, by any path through the code
None of that is an audit. It is what ought to happen before one, so that the people we pay to find problems spend their time on the interesting ones rather than on the obvious ones we could have caught ourselves.
Outstanding
16 components that cannot finish without one
This list is computed from the same data as the build tracker, so it cannot be shorter here than it is there.
- consensus
Lane B, the GPU lane
A tensor-friendly memory-hard algorithm, built so consumer GPUs stay competitive.
- consensus
First independent audit of the GPU lane
External cryptographic review of the newest and highest-risk algorithm in the system.
- vm
Cross-VM router
Calls that cross between the two engines. The hardest correctness problem in the execution layer.
- vm
Independent audits of all three engines
Both engines and the router reviewed externally before anything touches mainnet.
- compute-mesh-contracts
Staking and job scheduling
Nodes stake to take work, and work is distributed across them.
- compute-mesh-contracts
Redundant execution and majority verification
Jobs run on several nodes and a majority has to agree on the result before anyone is paid.
- compute-mesh-contracts
Payouts and slashing
The economics of getting it right, and the cost of getting it wrong on purpose.
- governance
Governance Module
On-chain governance, including the scoped safety valve and the thresholds that retire it.
- compute-mesh-contracts
Native oracle service
Price and data feeds served by the same mesh, with the same verification.
- node
Mainnet launch
Both engines, the router, the mesh, governance and the oracle live together.
- compute-mesh-contracts
Third-party compute marketplace
Anyone can submit inference work to the mesh, not just us.
- registries
Founders and referral registries
Both on-chain, both non-transferable by design.
- signal-ledger
Signal Ledger
Every decision committed on-chain as a receipt, timestamped before the market moves rather than after.
- dex
DEX launch, same-VM pairs
Order book and AMM live independently on each engine. Spot only.
- governance
Full protocol governance
The safety valve sunsets. Community governance covers everything.
- dex
Cross-VM trading pairs
Trading across both engines once the router allowlist expands.