§1Rules for evidence#
- A result qualifies only the revision and the profile it ran on. Old passing results are never reused as new evidence.
- Internal and agent-assisted reviews are labeled internal and are never described as independent audits.
- An original report's verdict is never edited after a fix. The fix is recorded next to the report.
- Skipped, blocked or timed-out checks count as open gates, not as passes.
§2How the implementation is tested#
| Layer | What runs |
|---|
| Unit and package tests | 346 Go test files across consensus, state, VM, P2P, RPC, authorization and shielded packages; the full suite also runs under the race detector |
| Live user stories | 70 scripted scenarios on fresh four-validator networks (listed below) |
| Differential testing | The EVM against go-ethereum: seeded random programs, stateful random programs and the Ethereum state tests, with every divergence classified |
| Fuzzing | Targets for RPC, P2P, EVM, session authorization, names, staking shares and shielded decoding |
| Determinism lint | A static check for nondeterministic constructs in consensus paths |
| Reference models | An independent session-authorization model and test vectors; cryptographic vectors such as RFC 9381 and Orchard empty roots |
| Fault injection | Injected disk-full errors, a Byzantine peer, proxy-driven network faults in the style of Jepsen, and restart-phase sweeps |
| Replay equivalence | A recorded multi-epoch chain replayed through the production importer, with a restart at every boundary |
Internal campaign, 2026-09-20 to 09-21About 289 million fuzz executions with zero crashers. The full story suite of the time ran natively twice with 62 of 67 passing, none failing, and every non-pass tracked.
§3The 70 user stories#
Each story runs real binaries over RPC, most on a fresh disposable network. When run with the story-test daemon, every finalized block is also checked for supply, delegation-share, nonce and unbonding invariants. The stories that stress restarts and faults (52, 59, 69 and 70) end with a signing-safety assertion that fails on any signing-guard failure.
Authorization, sessions, recovery and sponsorship (20)
| 01 | Session Key Scoped Delegation & Transfer |
| 02 | Session Policy Boundaries & Security (Negative Tests) |
| 09 | Session Grant Expiry & Deposit Recovery |
| 10 | Session Fee Caps & Security Reserve Limits |
| 11 | Root Activation & Threshold Governance |
| 12 | Root Key Rotation & Reserve Management |
| 13 | Offline Root Signing & Witness Assembly |
| 20 | Session Grant Atomic Replacement Lifecycle |
| 23 | Root Multisig Intent Replay & Domain Separation |
| 26 | Authorization-Mode Transition & Bypass Attempts |
| 27 | Real Domain Separation & Signed-Intent Tampering |
| 28 | Multisig Witness Integrity |
| 29 | Revoke/Replace/Rotate vs Queued Spending |
| 30 | Session Boundary & Refill Matrix |
| 31 | Concurrent Grants Competing for One Balance |
| 32 | Policy Permissions Across Action Types |
| 33 | Cancellation Is Not Revocation |
| 39 | Grant Deposit Ownership & Cleanup Lifecycle |
| 65 | Guardian Recovery: Quorum, Delay and Cancellation |
| 66 | FR-004 Sponsored Transactions: Paymaster Gas Abstraction |
Transfers, transaction pool and fees (8)
| 03 | Transparent Transfers & Nonce Sequencing |
| 07 | Transfer Value Boundaries & Input Hardening |
| 08 | Mempool Gas Economics & Tx Lifecycle |
| 24 | Mempool Nonce Sequencing & Replacement Fee Bumps |
| 34 | Malformed & Forged Raw Transaction Envelopes |
| 37 | Lost Response & Safe Transaction Retry |
| 38 | Exact Balances & Replacement Thresholds |
| 62 | EIP-1559 Fee Market: Base-Fee Burn & Tip |
Shielded transfers (10)
| 04 | Zero-Knowledge Shielded Privacy Pool |
| 14 | Shielded Wallet Lifecycle & Recovery |
| 15 | Shielded Pool Invariants & Proof Safety |
| 25 | Shielded Multi-Party Pool Accumulation & Tree Growth |
| 35 | Shielded Proof & Public-Field Binding |
| 36 | Shielded Duplicate Submission & Activation Gates |
| 41 | Wallet Sync Retry & Untrusted Compact Data |
| 60 | Native Private Payment Lifecycle |
| 61 | Shielded Spend Binding & Double-Spend Defense |
| 63 | FR-001 Selective Disclosure: Audit, Accounting & Receipts |
Staking and validators (7)
| 05 | Validator Staking & Delegation |
| 16 | Staking Boundary Rejections & Guards |
| 21 | Delegation Lifecycle & Undelegation Boundaries |
| 42 | Successful Validator Staking & Exit |
| 43 | Rewards, Delegation Switching & Rounding |
| 55 | Validator Misconduct, Jail & Reward Exclusion |
| 67 | FR-007 Liquid Staking: Share Transfers & Vault Quotes |
EVM (4)
| 17 | EVM Contract Deployment & Call Boundaries |
| 22 | EVM Out-Of-Gas & State Rollback Isolation |
| 44 | Nested EVM Calls & Transaction Isolation |
| 45 | Simulation & Gas Estimation Do Not Mutate State |
RPC, names, tooling and operations (13)
| 06 | Account & Key Management Fundamentals |
| 18 | Chain Inspection & RPC Integrity |
| 19 | Snapshot & Offline Maintenance Guards |
| 40 | Keystore Safety & Interrupted Persistence |
| 46 | History, Receipts, Logs & Authorization Proofs |
| 47 | Strict RPC Transport & JSON Handling |
| 48 | WebSocket Ownership & Reconnect |
| 49 | Explorer & Faucet Journeys and Abuse |
| 51 | Successful Snapshot Restore & Prune |
| 54 | Resource Abuse with an Honest Client |
| 56 | Disk Failure & Incompatible Startup |
| 57 | Health, Metrics & Origin Policy |
| 64 | Native Name Service: Commit-Reveal Lifecycle |
Fault tolerance (8)
| 50 | Graceful Restart & Abrupt Crash Recovery |
| 52 | Validator Outage & Partition Recovery |
| 53 | Fresh Peer Catch-Up & Malicious Peer Isolation |
| 58 | Generated Mixed-Action Sequences |
| 59 | Long-Running Epoch & Recovery Soak |
| 68 | Live/Replay/Restart Equivalence |
| 69 | Jepsen Network Faults & Byzantine Adversaries |
| 70 | Restart Phase Trigger Harness |
§4Threat models#
Seven threat models define assets, attackers, required properties and residual gaps. Each is candidate design material, not an audit.
| Model | Version | Residual gaps |
|---|
| Consensus and BFT | 0.3.0, 2026-09-26 | Three: forced evidence inclusion (mitigated); no median-time clock guard (open); signer custody (partly mitigated by keystore and remote signer) |
| EVM execution | 0.1.0 | Two: gas calibration measured, to confirm on reference hardware; SELFDESTRUCT semantics resolved by decision |
| P2P networking | 0.1.0 | Two: isolation under total anchor denial (partly mitigated); development subnet bypass (warns at startup) |
| Storage | 0.1.0 | Three: snapshot trust; retention override; disk exhaustion (residual) |
| Transaction pool and MEV | 0.1.0 | Two: plaintext mempool (accepted with disclosure); saturation eviction (closed) |
| Session authorization | 0.2.0 | A catalogue of properties and abuse cases, with release gates |
| Shielded | current | Trust boundaries and required properties; external audit outstanding |
§5Load qualification#
Run on 2026-09-20 with four validators on one 10-vCPU host and a mixed load of 80% transfers and 20% storage-writing contract calls. Other tenants saturated the host for the whole campaign, so these results are lower bounds.
| Offered load | Duration | Outcome |
|---|
| 20 TPS | 30 min | Stable. 35,984 of 35,984 included; inclusion p50 1.5 s, p95 3.8 s |
| 50 TPS | 60 s | Stable. Inclusion p50 1.5 s, p95 4.3 s |
| 50 TPS | 32 min | Unstable. Healthy for about 5 minutes, then commit gaps of 42 s to over 133 s; longest block gap 576 s |
| 75 TPS | 45 s | Degraded. 31% included |
| 100 to 200 TPS | short | Finality halts after about 600 to 800 inclusions |
| 500 TPS | 30 s | No blocks produced |
At every saturation point the first bottleneck was consensus liveness, not execution, RPC, the mempool or disk. The gas ceiling, about 300 simple transfers per second at 30 million gas per 2 s slot, was never reached.
Re-measurement pendingA fix that lets delayed rounds catch up from authenticated peer progress merged on 2026-10-08, after this campaign. Until load is measured again on uncontended hardware, the planning figure is 20 TPS sustained.
§6EVM gas-to-time calibration#
On 2026-09-26 an adversarial corpus searched for the slowest block per unit of gas. The worst family projected to about 0.76 s for 30 million gas on the campaign host (best of three runs at 29.6 million gas; observed 0.75 to 0.92 s). ECRecover was the outlier and was repriced to 9,000 gas (decision). The MLOAD family of memory-access opcodes, at about 25 ns per gas, are now the binding constraint, to be confirmed on reference validator hardware.
§7Review history#
| Date | Review | Scope | Outcome |
|---|
| 2026-10-13 | Robustness re-review Internal | Crashes, disk, clocks, load, partitions, upgrades, operator mistakes | Planned; re-tests the September remediations |
| 2026-10-12 | Security review of ef16072 Internal | 14 layers, rated for a transparent-only public testnet | Not ready as configured. Open findings concentrate in availability and validator key custody: 1 critical, 2 high, 6 medium, 8 low, 2 informational. No finalized-state safety violation found. Regression tests for earlier critical and high findings: 13 of 13 pass. |
| September 2026 | Robustness review Internal | Crash recovery, partitions, concurrency, state invariants, sync | 28 findings; remediation recorded alongside |
| 2026-09-12 | Second-pass security audit Internal | Nine subsystems | 44 findings: 42 fixed with regression tests. Of 2 design items, one was later fixed by secret leader election; the other, mempool MEV exposure, was accepted with disclosure |
| September 2026 | First-pass security review Internal | Eight subsystems | Fixes applied in code |
| 2026-09-11 | Functional readiness baseline Internal | Completeness and reliability; security not scored | Not testnet-ready; remediation recorded |
Findings from the 2026-10-12 review are tracked privately. Their details are published after fixes ship, under the disclosure policy.
Sources: Testing guide; threat models; load qualification report of 2026-09-20; EVM gas-to-time report of 2026-09-26; audit index and the reports it lists; internal campaign report of 2026-09-21.
Cite this page
@misc{resilience-assurance,
title = {{Assurance and evidence}},
author = {{Resilience Network}},
year = {2026},
note = {Reference implementation c3acec4, protocol manifest r28},
url = {https://resiliencenetwork.xyz/assurance/}
}
