Resilience Network
Pre-mainnet research network No public testnet yet Protocol manifest r28 Shielded transfers experimental Current status
Protocol

Protocol overview

A transaction crosses seven boundaries between a signature and a finalized receipt. Each boundary has one owner in the implementation and one rule it must never break. The five specification pages that follow go into each one.

§1A transaction's path#

Transaction lifecycle: sign, submit, admit, propose, execute, finalize, observe; a syncing node re-executes finalized blocks through the importer. 1Signclient, V2 envelope 2SubmitRPC or gossip 3Admittransaction pool 4Proposeelected proposer 5Executeevery validator, strictly 6Finalize>2/3 precommit 7ObserveRPC, wallets admission is not inclusion whole block Syncing nodefinalized-block importer re-executes with the same rules must match
Figure 1. The seven boundaries. A syncing node never takes a peer's word for state: it re-executes finalized blocks and must reproduce live execution exactly, including fees, epoch transitions and validator sets.
  1. Sign. The client serializes a canonical V2 envelope and signs it, bound to the chain and genesis.
  2. Submit. RPC or gossip decodes it and offers it to the transaction pool.
  3. Admit. Pool checks, repeated on every head change, decide eligibility. Admission is not a promise of inclusion.
  4. Propose. The elected proposer orders candidates and simulates them within block budgets.
  5. Execute. Validators authenticate the proposal and execute the whole block strictly. An invalid transaction invalidates the block; a valid action that fails produces a failed receipt.
  6. Finalize. Validators holding more than two thirds of voting power precommit. The commit persists blocks, receipts, state and validator data together.
  7. Observe. RPC exposes the canonical result. Shielded wallets rebuild their state from authenticated compact blocks.

§2Invariants every change must preserve#

  • Identity is more than a chain ID. Genesis, effective consensus configuration and the protocol commitment together identify a network.
  • Execution is deterministic. Proposer selection never replaces strict execution by every validator.
  • Invalid input never partially commits. A valid transaction that fails follows receipt, fee and nonce rules instead.
  • Safety state survives restarts. Validator locks and signing watermarks persist. Running a duplicate signer or resetting them defeats safety.
  • Consensus changes move together. Encodings, gas schedules, activation rules and state-root commitments are reviewed as one change.
  • Advice is not finality. An RPC simulation, a unit test or a past review result is never evidence of inclusion or of deployment readiness.

§3The protocol commitment#

Protocol rules are pinned in a compiled protocol manifest: domain strings, gas prices, action codes, activation revisions and size limits. The manifest is encoded canonically, with each constant's name next to its value, and hashed with Keccak-256. That hash is written into the genesis header together with the chain ID. Timing and economic parameters, such as slot duration, epoch length, stake and slashing, are bound separately by each node's consensus-configuration commitment, and nodes with different values do not interoperate.

A node refuses a genesis whose commitment differs from the one it was built with. There is no migration between manifest revisions: a semantic change means a coordinated restart from a fresh genesis. The log lists every revision.

Current values
FieldValue
Manifest revision28
Protocol identifierresilience/session-authorization/1
Capabilityresilience/tx-auth/2
Hash functionKeccak-256 with original padding (not NIST SHA3-256)
Development genesis commitment0xcb4f7146ea76f23d2dbf1b5ba6087690f216a2be25e09270195efa27cbfffa8a
Development chain ID1337, replaced at a public genesis

§4Cryptographic primitives#

UsePrimitive
Hashing, state, signing domainsKeccak-256 (original padding), one literal domain label per construction
Account, root, validator and network keysEd25519 (RFC 8032), canonical encodings only
Session keys, optionallyP-256 (secp256r1) ECDSA, raw 64-byte r‖s signatures
Leader election and randomnessECVRF-EDWARDS25519-SHA512-TAI (RFC 9381, suite 0x03)
Shielded transfersOrchard: Halo 2 proofs on the Pallas/Vesta curve cycle, RedPallas signatures
Validator keystorescrypt with AES-256-GCM

§5Component map#

AreaResponsibilityWhere
ConsensusProposals, votes, locks, leader election, finalized importinternal/consensus, internal/blockchain, crypto
ExecutionState transition, EVM, authenticated trie, storageinternal/state, internal/vm, internal/db
Networkinglibp2p gossip, sync, peer scoring, transaction poolinternal/p2p, internal/txpool
AuthorizationRoot, session, recovery and sponsorship rulespkg/sessionauth
PrivacyOrchard bridge, wallet, native Rust librarypkg/shielded
Client boundaryJSON-RPC and the command-line clientinternal/rpc, cmd/resilience-cli

Sources: internal/blockchain/protocol_manifest.go, configs/genesis.json, architecture overview.

Cite this page 
@misc{resilience-protocol,
  title  = {{Protocol overview}},
  author = {{Resilience Network}},
  year   = {2026},
  note   = {Reference implementation c3acec4, protocol manifest r28},
  url    = {https://resiliencenetwork.xyz/protocol/}
}