A Layer 1 protocol for users who require propertiesno existing programmable chain delivers in combination.
Adamant is a Layer 1 blockchain protocol designed to serve users who require properties no existing programmable chain delivers in combination: privacy by default, high transaction throughput, sub-second finality, post-quantum cryptographic security, phone-verifiable correctness, and credibly neutral governance — with no foundation, no premine, no admin keys, and no upgrade authority after genesis.
The protocol combines a directed-acyclic-graph (DAG) consensus mechanism, an object-based parallel execution model, threshold-encrypted transaction propagation, recursive zero-knowledge proofs of state validity, and a fixed constitutional rule set established at genesis. Every transaction is shielded by default, with users retaining the ability to selectively disclose specific information through cryptographically verifiable view keys. Smart contracts declare their mutability rules — IMMUTABLE, OWNER_UPGRADEABLE, VOTE_UPGRADEABLE, UPGRADEABLE_UNTIL_FROZEN, or a custom rule — at deployment, and these declarations are themselves immutable and visible to users before interaction.
The chain rejects on-chain governance by design. The protocol's consensus rules, virtual machine, token issuance schedule, and validity logic are fixed at genesis and cannot be modified by any party — including the original implementers.
Adamant targets a sustained throughput of at least 200,000 transactions per second on a single shard, a finality latency of approximately 500 milliseconds for transactions not requiring consensus on shared state, and a per-transaction fee floor on the order of $0.0001 USD-equivalent at design throughput. Fee accounting is multi-dimensional, separating the costs of state storage, computation, and proof verification rather than collapsing them into a single gas number. Fees are paid in the native token (working name ADM) and burned via an EIP-1559-style mechanism, producing deflationary token economics under network usage.
The protocol uses standard, peer-reviewed cryptographic primitives — Ed25519 and ML-DSA (CRYSTALS-Dilithium, FIPS 204) for signatures, BLS12-381 for signature aggregation, SHA-3 for hashing, and the Halo 2 proving system for zero-knowledge proofs. No novel cryptography is introduced. The contribution is the systems-level synthesis of these primitives into a coherent architecture meeting the property set described above.
The state of the art (2026)and the gap that remains.
Public blockchains have matured along several distinct axes since the Bitcoin whitepaper appeared in 2008. Each axis has produced exemplary systems, and each has produced trade-offs the broader ecosystem has implicitly accepted as inherent.
The seven properties, and where each is best demonstrated
| Property | Demonstrated by | Year |
|---|---|---|
| 200k+ TPS, sub-second finality | Mysticeti / Sui | 2024 |
| Programmable privacy | Aztec | 2025 |
| Encrypted mempool (in production) | Shutter / Gnosis | 2024 |
| Phone-verifiable chain | Mina | 2021 |
| Native account abstraction | zkSync, StarkNet, Aptos | 2022–24 |
| Post-quantum signatures | NIST standardisation | 2024 |
| Credible neutrality | Bitcoin, Monero | 2009, 2014 |
The protocol's integrated design also enables a permissionless service-node infrastructure market (§9.10) and a validator-funded infrastructure mechanism (§10.5.5). These are not constitutional core properties — the chain functions correctly without them — but they are downstream consequences of the architecture: a chain that is permissionless at the participation layer, with standardised lightweight verification, naturally supports a market for the infrastructure that serves its lightweight clients. Whether this market develops at scale is determined by ecosystem dynamics rather than protocol mechanism, but the standardisation that makes it possible is part of the protocol's design.
No single chain in the present landscape combines more than three of these properties. The chains that combine credible neutrality with anything else (Bitcoin, Monero) lack programmability and high throughput. The chains that combine programmable privacy with anything else (Aztec, Aleo) lack the throughput tier and credibly neutral governance. The high-throughput chains (Sui, Solana, Aptos, Monad) have neither default privacy nor credibly neutral governance.
This is the gap Adamant is designed to fill. The contribution is not the invention of new cryptographic primitives — those are taken from peer-reviewed literature unchanged — but the systems-level synthesis of these properties into a single coherent architecture, with credible neutrality enforced at genesis.
Seven principles,in priority order.
Every protocol decision in this document is derivable from one or more of seven principles. When principles conflict, the higher-numbered principle yields to the lower. The principles are listed in priority order:
Credible neutrality
The protocol MUST NOT admit any party with the unilateral capability to alter its operation.
No on-chain governance. No foundation, treasury, or admin keys. No premine or founder allocation. Forks require individual opt-in. No protected contracts or precompiles favouring the implementers.
Privacy by default
Transactions on the protocol MUST be private by default. Users MUST retain the ability to selectively disclose specific information to specific parties through cryptographically verifiable means.
Default shielded execution. Selective disclosure via view keys. No backdoor decryption. Optional transparency as a per-transaction choice.
Verifiability without trust
Any participant MUST be able to verify the correctness of the protocol's operation using only consumer-grade hardware, without trusting any third party.
Phone-verifiable verification via recursive zero-knowledge proofs. No light-client trust assumptions. Open verification: free, open-source, runnable without permission.
Performance sufficient for use
The protocol MUST provide throughput, latency, and cost properties consistent with practical use as a payment network and smart-contract platform.
200,000 TPS on a single shard. ~500ms finality for non-shared-state transactions. $0.0001 USD-equivalent fee floor. Phone-friendly proving (≤10s for typical operations).
Mutability is a property of objects, not the chain
The chain's consensus rules MUST be immutable. Objects living on the chain MAY declare their own mutability rules at creation, and those declarations MUST themselves be immutable and visible to users before interaction.
Standard policies: IMMUTABLE, OWNER_UPGRADEABLE, VOTE_UPGRADEABLE, UPGRADEABLE_UNTIL_FROZEN, CUSTOM. No proxy-pattern hiding.
Standard primitives, novel synthesis
The protocol MUST use standard, peer-reviewed cryptographic primitives. The protocol MUST NOT introduce novel cryptographic constructions.
Ed25519, ML-DSA (FIPS 204), BLS12-381, SHA-3, Halo 2. Audited libraries from the dalek, arkworks, blst, and ml_dsa ecosystems. Innovation at the systems layer, not the primitive layer.
Permissionless participation
Participation in the protocol MUST NOT require permission from any party.
Permissionless validation, transaction submission, development, and verification. No identity requirements at the protocol layer.
A future revision of this whitepaper that proposes to add on-chain governance, a foundation, an emergency pause mechanism, identity verification at the protocol layer, or any precompiles favouring the implementers, would by definition be specifying a different protocol — not a revised Adamant.
Cryptography. Identity. Objects. VM. Privacy. Consensus. Networking. Service nodes. Economics.
Sections 3 through 10 specify the technical mechanism in detail sufficient to implement. Together they cover roughly two hundred pages: the cryptographic primitives, the identity and account model, the object model and state, the Adamant Move VM, the Halo 2 privacy layer, the DAG consensus mechanism, the libp2p networking layer including the standardised service-node market (§9.10), and the multi-dimensional gas accounting and issuance schedule including validator-funded infrastructure (§10.5.5).
These sections are too dense to inline here. They live in the repo as the canonical source.
What is fixed forever,and how change still happens.
At genesis, the protocol's specification — every section of this whitepaper, the parameters defined within it, and the reference implementation that realises it — is fixed. The fixing is enforced not by a foundation, not by a multisig, not by an on-chain governance mechanism, but by the structural absence of any mechanism to modify the protocol.
There is no party with the authority to:
- ×Add a new validity rule
- ×Change a gas cost
- ×Modify the issuance schedule
- ×Add a new system contract
- ×Freeze any account or transaction
- ×Censor any participant
- ×Pause the chain
- ×Issue an emergency fix
- ×Coordinate an automatic upgrade
- ×Change consensus parameters
Each of these operations is technically possible — anyone can write a modified Rust implementation that does any of them. What is impossible is for any party to make such modifications take effect on the running network without the explicit cooperation of the validators running the existing implementation.
The credibility of credible neutrality comes from the protocol's design making misbehaviour infeasible — not from the implementers' promises.
The fork mechanism
Despite all of the above, the protocol can change. The mechanism is the same one Bitcoin uses:
- 1 Specification revision. Someone proposes a change as a revised section, a new reference implementation, or both.
- 2 Public discussion. The proposal is debated in public forums. Anyone may participate.
- 3 Implementation. A reference implementation of the change is published. Anyone may write or audit it.
- 4 Validator opt-in. Validators choose whether to upgrade their software. Each decision is independent.
- 5 Activation. When a 2/3+1 supermajority by stake has upgraded, the new rules become effective on that network. Validators who didn't upgrade either find themselves on a minority chain or upgrade voluntarily.
There is no point at which any party — including the proposers, the implementers, or any subset of validators — can force the upgrade onto unwilling participants. The minority chain remains operational as long as any validator is willing to maintain it.
Enabled, but not allocated
The protocol additionally enables, but does not fund or specify in detail, a permissionless service-node infrastructure market (§9.10) and a validator-funded infrastructure mechanism (§10.5.5). The protocol-level commitments fixed at genesis are: the standardised query format, the registration mechanism, the smart-contract patterns supporting payment, and the principle that issuance flows only to validators (§10.3.2). The downstream market — its participants, fee schedules, reputation systems, and operational shape — is not constitutionally fixed and may evolve organically without requiring hard-fork coordination. Validators choosing to fund infrastructure do so from their own commission revenue, not from any protocol allocation; the protocol's role is enablement, not allocation.
A maze of compromises.Adamant is for the users not served by them.
The blockchain ecosystem in 2026 is a maze of compromises. Most chains compromise neutrality for governance flexibility; many compromise privacy for compliance friendliness; some compromise verifiability for performance. Each compromise produces real users who chose that chain because the compromise suited them.
Adamant is for the users not served by these compromises. It is for users whose threat model includes their own government, their own foundation, their own validators. It is for users for whom "the chain has a foundation" is a security flaw, not a feature. It is for users who want to commit value to a system whose rules they can verify with cryptographic finality.
Acknowledged open problems
- Operational tooling. Wallets, indexers, block explorers, monitoring — not part of the protocol but essential. The launch must be accompanied by reasonable tooling.
- Service-node market materialisation. §9.10 specifies the infrastructure for a service-node market. Whether one develops at meaningful scale depends on whether wallets prefer service nodes over centralised RPC, whether validators choose to fund infrastructure (§10.5.5), and whether payment-channel UX is good enough for routine wallet usage. The chain functions correctly without it.
- Service-node payment channel UX. Pattern A (direct wallet-to-node payment via channels) inherits the well-documented UX challenges of payment-channel networks. The reference implementation aims to make these flows automatic and invisible — non-trivial polish.
- Reputation system development. §9.10.6 specifies a delivery-receipt primitive but not a reputation system. Practical service-node reputation requires third-party tooling: aggregators of receipts, signed performance attestations, perhaps decentralised reputation networks. Ecosystem work.
What remains to be done
This whitepaper is a specification. Substantial work remains before genesis: a Rust reference implementation estimated at 150,000–250,000 lines across 20–30 crates; calibration of gas costs against hardware benchmarks; formalisation of distributed proof-generation and DKG protocol details; multiple independent security audits; public testnets at progressively realistic load.
A realistic timeline is 24–36 months for one or two engineers, 18–24 months for a small team. The protocol's value is in being right at genesis, not in being early. If delays are needed to ensure correctness, they will be taken.
This whitepaper specifies how to build that chain. The next document — and the next several years of work — is how it gets built.
The full whitepaper — every section in full, including the eight technical sections summarised here — lives in the repository.