Dytallix L1 · Mainnet
Launch Simulations
Dytallix is the first post-quantum cryptography (PQC) trust and identity L1 built through solo agentic engineering. It is now undergoing a comprehensive end-to-end security assessment of its core functions, covering consensus, cryptography, networking/P2P, execution and state transition, staking, governance, tokenomics, the fee/gas mechanism, and the account/identity model, where the review process itself is conducted in an agentic engineering context.
Source: launch records in DytallixHQ/dytallix, as of 11 October 2026.
The testnet is retired.
The early-alpha Dytallix testnet, its explorer, wallet and faucet were retired for the pre-mainnet launch simulations. Their pages now open this page. Testnet assets had no production value.
How Dytallix is built
Built in public
Agentic engineering lets one engineer increase the scale, scope and speed of a complex project like Dytallix: a post-quantum L1 with its consensus application, cryptography, token economics and launch operations.
The work is public. Every change is a pull request, every launch decision is an approval record, and this page reports each check as its results come in.
Mainnet launch
Status
Prepare1 passed1 in progress1 of 41 passed1 in progress39 not started
Review0 of 5 passed0 in progress5 not started
Launch0 of 35 passed0 in progress35 not started
Not online
Public node. The sentry, the chain's one public node, goes online with the staging runs. Its status will show here.
Eight phases
Order of work
Each phase starts when the phases before it are complete. Select a phase to see its checks.
Phase 01 · PreparePass
Simulation plan
The seven runs, their pass criteria, timings, host access, load source and the statistical campaign, approved as one decision record.
- Approved on 11 October 2026 as one decision record.
- Fixes the pass criteria, the timings, how the console-only hosts are driven, and where test load comes from.
- Thresholds were set before any run, so they cannot be adjusted to fit the results.
Pass
Plan approved
- Pass threshold
- One approval record covering all six decisions
- Current value
- Approved 11 Oct 2026
- What it measures
- Whether the pass criteria, timings, host access, load source and statistical campaign are fixed in an approval record before any run.
- Why it matters
- Thresholds set before the runs cannot be adjusted to fit the results.
- Updated
- 11 October 2026
Phase 02 · PrepareIn progress
Simulation tools
Nine tools (T1 to T9) that build rehearsal genesis, drive the hosts, generate load and attacks, inject faults and record evidence. Each is proven in the CI staging network first.
- Nine tools: rehearsal genesis, the host agent, load, attacks, faults, reconciliation, checkpoint evidence, the upgrade drill and validator recovery.
- Each tool is proven in the CI staging network before it touches a real host.
1 in progress0 of 9 passed1 in progress8 not started
T1In progress
Spendable rehearsal genesis
- Pass threshold
- Built and passing in the CI staging network
- Current value
- Spendable accounts built and passing in CI; shortened timing profile next
- What it measures
- Real keys for every allocation row and the wallet fleet, a fresh chain ID per run and the recorded mapping.
- Why it matters
- A run is only as good as the tool that drives and checks it. Each tool is proven in the CI staging network before it touches a real host.
- Updated
- 11 October 2026
T2Planned
Staging agent and real-host harness
- Pass threshold
- Built and passing in the CI staging network
- Current value
- Not measured yet
- What it measures
- Signed, allowlisted commands on console-only hosts, and the drills' assertions against real hosts.
- Why it matters
- A run is only as good as the tool that drives and checks it. Each tool is proven in the CI staging network before it touches a real host.
- Updated
- 11 October 2026
T3Planned
Load generator and wallet fleet
- Pass threshold
- Built and passing in the CI staging network
- Current value
- Not measured yet
- What it measures
- Workers that sign locally, track nonces and send the transaction mix through the public client channel.
- Why it matters
- A run is only as good as the tool that drives and checks it. Each tool is proven in the CI staging network before it touches a real host.
- Updated
- 11 October 2026
T4Planned
Adversarial generator
- Pass threshold
- Built and passing in the CI staging network
- Current value
- Not measured yet
- What it measures
- Invalid signatures, bad encodings, bad nonces, duplicates, oversized requests and floods.
- Why it matters
- A run is only as good as the tool that drives and checks it. Each tool is proven in the CI staging network before it touches a real host.
- Updated
- 11 October 2026
T5Planned
Fault injector
- Pass threshold
- Built and passing in the CI staging network
- Current value
- Not measured yet
- What it measures
- Latency, packet loss, partitions, peer drops, process kills and host loss, each with recovery timing.
- Why it matters
- A run is only as good as the tool that drives and checks it. Each tool is proven in the CI staging network before it touches a real host.
- Updated
- 11 October 2026
T6Planned
Reconciliation report
- Pass threshold
- Built and passing in the CI staging network
- Current value
- Not measured yet
- What it measures
- Every node's app hash and supply compared at a height; genesis plus emitted minus burned; fees against burns.
- Why it matters
- A run is only as good as the tool that drives and checks it. Each tool is proven in the CI staging network before it touches a real host.
- Updated
- 11 October 2026
T7Planned
Checkpoint recorder
- Pass threshold
- Built and passing in the CI staging network
- Current value
- Not measured yet
- What it measures
- Runs each checkpoint's checks and writes evidence bound to the candidate's digests.
- Why it matters
- A run is only as good as the tool that drives and checks it. Each tool is proven in the CI staging network before it touches a real host.
- Updated
- 11 October 2026
T8Planned
Upgrade drill
- Pass threshold
- Built and passing in the CI staging network
- Current value
- Not measured yet
- What it measures
- Builds the next release for a running chain and runs the signed handover and upgrade end to end.
- Why it matters
- A run is only as good as the tool that drives and checks it. Each tool is proven in the CI staging network before it touches a real host.
- Updated
- 11 October 2026
T9Planned
Validator recovery drill
- Pass threshold
- Built and passing in the CI staging network
- Current value
- Not measured yet
- What it measures
- Fences, reinstalls and resynchronizes a lost validator host and times it against the target.
- Why it matters
- A run is only as good as the tool that drives and checks it. Each tool is proven in the CI staging network before it touches a real host.
- Updated
- 11 October 2026
Phase 03 · PreparePlanned
Staging on production hosts
The three production hosts run the peer tests, the capacity measurements and the root kit drills with rehearsal identities.
- The two production hosts, the validator and the sentry, run with rehearsal identities only: a rehearsal chain ID, throwaway keys and rehearsal root kits.
- Peer tests, capacity measurements and root kit drills run here before the release freeze.
0 of 4 passed0 in progress4 not started
Production hostsPlanned
Production hosts in service
- Pass threshold
- 2 of 2 hosts; validator and sentry in different countries
- Current value
- Not measured yet
- What it measures
- The validator and sentry servers installed from sealed rehearsal bundles. The sentry is the one public node.
- Why it matters
- Simulations only count on the hardware and network the mainnet will use.
- Updated
- 11 October 2026
E03Planned
Negative peer tests
- Pass threshold
- Every case refused as specified
- Current value
- Not measured yet
- What it measures
- Wrong-key, malformed and unexpected peers against the production hosts' post-quantum transport.
- Why it matters
- Only approved peers may reach the validator. A peer that should be refused must be refused.
- Updated
- 11 October 2026
T05Planned
Measured capacity
- Pass threshold
- Confirms about 180 basic Sends a block
- Current value
- Not measured yet
- What it measures
- Basic transfers per block the hosts sustain within the approved queue and connection limits.
- Why it matters
- The load thresholds in R06 depend on a capacity measured on the real hosts, not estimated.
- Updated
- 11 October 2026
Root kitsPlanned
Root kit drill
- Pass threshold
- Control admitted with 3 of 5 signatures
- Current value
- Not measured yet
- What it measures
- Three of five rehearsal kits prepare, sign and submit a root control end to end.
- Why it matters
- Upgrades and emergency controls need three kit holders acting together. The procedure is rehearsed before it is needed.
- Updated
- 11 October 2026
Phase 04 · PreparePlanned
Statistical campaign
Thousands of attack attempts per type, repeated faults and an endurance run of at least 15 days, so results carry statistical confidence.
- Attacks: at least 3,000 attempts per attack type with zero successes, which bounds the success rate below 1 in 1,000 at 95% confidence. Connection-level attacks about 30 times each.
- Faults: quick faults about 30 times each and heavy faults 3 to 5 times, with every recovery time recorded.
- Performance: median block interval at most 6 s and 99th percentile at most 10 s.
- Endurance: at least 15 days at production values, covering unbonding, governance and an upgrade handover.
- Any successful attack is a defect, fixed before the release freeze. Results go to Hashlock with the frozen candidate.
0 of 27 passed0 in progress27 not started
Not measured yet. The marks show the approved limits.
All 27 campaign checks
TransactionsTransactions: attemptsPass thresholdAt least 3,000 per attack typeCurrent valueNot measuredStatusPlanned
- What it measures
- Attempts made per attack type. Covers: Invalid, wrong-key and truncated ML-DSA-65 signatures; malformed and oversized envelopes; wrong chain; expired, stale and conflicting nonces; duplicates; fee caps below the minimum; overspending.
- Why it matters
- At least 3,000 attempts with zero successes bounds the success rate below 1 in 1,000 at 95% confidence (rule of three).
- Updated
- 11 October 2026
TransactionsTransactions: successesPass threshold0Current valueNot measuredStatusPlanned
- What it measures
- Attempts that the chain accepted or that changed state when it should not have.
- Why it matters
- Any success is a defect, fixed before the release freeze. Details are published only after the fix.
- Updated
- 11 October 2026
StakingStaking: attemptsPass thresholdAt least 3,000 per attack typeCurrent valueNot measuredStatusPlanned
- What it measures
- Attempts made per attack type. Covers: Bonds below the minimum or to unknown validators, over-unbonding, early withdrawal, repeated reward claims, bad validator registrations.
- Why it matters
- At least 3,000 attempts with zero successes bounds the success rate below 1 in 1,000 at 95% confidence (rule of three).
- Updated
- 11 October 2026
StakingStaking: successesPass threshold0Current valueNot measuredStatusPlanned
- What it measures
- Attempts that the chain accepted or that changed state when it should not have.
- Why it matters
- Any success is a defect, fixed before the release freeze. Details are published only after the fix.
- Updated
- 11 October 2026
GovernanceGovernance: attemptsPass thresholdAt least 3,000 per attack typeCurrent valueNot measuredStatusPlanned
- What it measures
- Attempts made per attack type. Covers: Proposals below the deposit, votes without a bond, repeated or late votes, replayed execution, out-of-bounds parameter changes.
- Why it matters
- At least 3,000 attempts with zero successes bounds the success rate below 1 in 1,000 at 95% confidence (rule of three).
- Updated
- 11 October 2026
GovernanceGovernance: successesPass threshold0Current valueNot measuredStatusPlanned
- What it measures
- Attempts that the chain accepted or that changed state when it should not have.
- Why it matters
- Any success is a defect, fixed before the release freeze. Details are published only after the fix.
- Updated
- 11 October 2026
Root controlsRoot controls: attemptsPass thresholdAt least 3,000 per attack typeCurrent valueNot measuredStatusPlanned
- What it measures
- Attempts made per attack type. Covers: Too few signatures, keys from the wrong epoch, replayed sequences, expired windows, non-canonical encoding.
- Why it matters
- At least 3,000 attempts with zero successes bounds the success rate below 1 in 1,000 at 95% confidence (rule of three).
- Updated
- 11 October 2026
Root controlsRoot controls: successesPass threshold0Current valueNot measuredStatusPlanned
- What it measures
- Attempts that the chain accepted or that changed state when it should not have.
- Why it matters
- Any success is a defect, fixed before the release freeze. Details are published only after the fix.
- Updated
- 11 October 2026
Account recoveryAccount recovery: attemptsPass thresholdAt least 3,000 per attack typeCurrent valueNot measuredStatusPlanned
- What it measures
- Attempts made per attack type. Covers: Replayed and wrong-key recovery transactions.
- Why it matters
- At least 3,000 attempts with zero successes bounds the success rate below 1 in 1,000 at 95% confidence (rule of three).
- Updated
- 11 October 2026
Account recoveryAccount recovery: successesPass threshold0Current valueNot measuredStatusPlanned
- What it measures
- Attempts that the chain accepted or that changed state when it should not have.
- Why it matters
- Any success is a defect, fixed before the release freeze. Details are published only after the fix.
- Updated
- 11 October 2026
Endpoint and RPCEndpoint and RPC: attemptsPass thresholdAbout 30 per attack typeCurrent valueNot measuredStatusPlanned
- What it measures
- Attempts made per attack type. Covers: Oversized bodies, connection floods beyond the limits, slow clients, invalid handshakes, methods outside the allowlist.
- Why it matters
- Connection- and network-level attacks are slower to run; about 30 repetitions each show consistent behavior.
- Updated
- 11 October 2026
Endpoint and RPCEndpoint and RPC: successesPass threshold0Current valueNot measuredStatusPlanned
- What it measures
- Attempts that the chain accepted or that changed state when it should not have.
- Why it matters
- Any success is a defect, fixed before the release freeze. Details are published only after the fix.
- Updated
- 11 October 2026
NetworkNetwork: attemptsPass thresholdAbout 30 per attack typeCurrent valueNot measuredStatusPlanned
- What it measures
- Attempts made per attack type. Covers: Latency, packet loss, partitions, peer instability, wrong-key and malformed peers.
- Why it matters
- Connection- and network-level attacks are slower to run; about 30 repetitions each show consistent behavior.
- Updated
- 11 October 2026
NetworkNetwork: successesPass threshold0Current valueNot measuredStatusPlanned
- What it measures
- Attempts that the chain accepted or that changed state when it should not have.
- Why it matters
- Any success is a defect, fixed before the release freeze. Details are published only after the fix.
- Updated
- 11 October 2026
Faults and recoveryValidator restartPass thresholdBlocks again within 5 minutes, every timeCurrent valueNot measuredStatusPlanned
- What it measures
- Time from a validator process restart to the next committed block. The chain has one validator, so it pauses meanwhile. About 30 repetitions; recorded as a distribution.
- Why it matters
- Recovery targets are what users can expect from a one-validator launch. Repeated measurement shows the spread, not one lucky run.
- Updated
- 11 October 2026
Faults and recoveryNetwork healPass thresholdCaught up within 2 minutes, every timeCurrent valueNot measuredStatusPlanned
- What it measures
- Time for the sentry to catch up after a network cut is restored. About 30 repetitions; recorded as a distribution.
- Why it matters
- Recovery targets are what users can expect from a one-validator launch. Repeated measurement shows the spread, not one lucky run.
- Updated
- 11 October 2026
Faults and recoverySentry rebuildPass thresholdWithin 4 hoursCurrent valueNot measuredStatusPlanned
- What it measures
- Time to rebuild a destroyed sentry, the public node, from its snapshot. 3 to 5 repetitions; recorded as a distribution.
- Why it matters
- Recovery targets are what users can expect from a one-validator launch. Repeated measurement shows the spread, not one lucky run.
- Updated
- 11 October 2026
Faults and recoveryValidator host recoveryPass thresholdWithin 8 hoursCurrent valueNot measuredStatusPlanned
- What it measures
- Time to recover a lost validator host by the fence-first procedure. 3 to 5 repetitions; recorded as a distribution.
- Why it matters
- Recovery targets are what users can expect from a one-validator launch. Repeated measurement shows the spread, not one lucky run.
- Updated
- 11 October 2026
Faults and recoveryFault alertsPass threshold100% of injected faultsCurrent valueNot measuredStatusPlanned
- What it measures
- Injected faults that raised their alert and resolved it after recovery.
- Why it matters
- The founder runs the chain alone. An outage that does not alert can last until someone notices.
- Updated
- 11 October 2026
PerformanceBlock interval, medianPass thresholdAt most 6 sCurrent valueNot measuredStatusPlanned
- What it measures
- Seconds between consecutive committed blocks, outside injected faults. A day gives about 17,280 blocks.
- Why it matters
- Block interval is how long a user waits for a transaction to be final. The tail matters as much as the median.
- Updated
- 11 October 2026
PerformanceBlock interval, 95th percentilePass thresholdRecordedCurrent valueNot measuredStatusPlanned
- What it measures
- Seconds between consecutive committed blocks, outside injected faults. A day gives about 17,280 blocks.
- Why it matters
- Block interval is how long a user waits for a transaction to be final. The tail matters as much as the median.
- Updated
- 11 October 2026
PerformanceBlock interval, 99th percentilePass thresholdAt most 10 sCurrent valueNot measuredStatusPlanned
- What it measures
- Seconds between consecutive committed blocks, outside injected faults. A day gives about 17,280 blocks.
- Why it matters
- Block interval is how long a user waits for a transaction to be final. The tail matters as much as the median.
- Updated
- 11 October 2026
PerformanceBlock interval, 99.9th percentilePass thresholdRecorded over the endurance runCurrent valueNot measuredStatusPlanned
- What it measures
- Seconds between consecutive committed blocks, outside injected faults. A day gives about 17,280 blocks.
- Why it matters
- Block interval is how long a user waits for a transaction to be final. The tail matters as much as the median.
- Updated
- 11 October 2026
PerformanceInclusion at half capacityPass thresholdAt least 99%Current valueNot measuredStatusPlanned
- What it measures
- Valid transactions committed within 2 blocks of submission while the chain runs at half capacity.
- Why it matters
- Shows that ordinary transactions are not delayed or dropped under normal load.
- Updated
- 11 October 2026
PerformanceClient response time, 99th percentilePass thresholdRecordedCurrent valueNot measuredStatusPlanned
- What it measures
- Time for the public node to answer a client request, under background load.
- Why it matters
- Wallets and applications reach the chain only through the public node. Slow answers look like an outage to users.
- Updated
- 11 October 2026
EnduranceEndurance runPass thresholdAt least 15 daysCurrent valueNot measuredStatusPlanned
- What it measures
- Continuous days at the exact production values with background load, covering full unbonding, governance voting and a release handover.
- Why it matters
- Some lifecycles take two weeks at production values. Slow leaks in state or memory only show over time.
- Updated
- 11 October 2026
EnduranceEpochs and snapshotsPass thresholdAt least 15Current valueNot measuredStatusPlanned
- What it measures
- Reward epochs and state snapshots completed during the endurance run.
- Why it matters
- Emission, rewards and snapshot restore are checked across many boundaries, not one.
- Updated
- 11 October 2026
Phase 05 · ReviewPlanned
Freeze, audit and public review
The release candidate is frozen, audited by Hashlock and opened to a 30-day public review with a DGT bug bounty. Every finding is fixed or answered on the record.
- The release candidate is frozen; a clean CI runner and a fresh container must rebuild it byte for byte.
- Hashlock audits the consensus application, the post-quantum CometBFT fork, the root signing tools and the CLI wallet.
- A 30-day public review with a DGT bug bounty runs alongside, with an AI review labeled as AI.
- Every finding is fixed and re-checked, or answered on the record. The launch is labeled unaudited until Hashlock's report is published.
0 of 5 passed0 in progress5 not started
Public reviewNot started; goal 30 daysE06Planned
Release candidate frozen
- Pass threshold
- Tagged and reproduced
- Current value
- Not measured yet
- What it measures
- A tagged release candidate whose binaries a clean CI runner and a fresh container reproduce byte for byte.
- Why it matters
- The audit, the public review and the simulations must all test the same code.
- Updated
- 11 October 2026
Hashlock auditPlanned
Independent audit
- Pass threshold
- Report published; every finding fixed and re-checked, or answered on the record
- Current value
- Not measured yet
- What it measures
- Hashlock's audit of the consensus application, the post-quantum CometBFT fork, the root authorization tools and the CLI wallet.
- Why it matters
- An independent human audit lowers the risk of defects. The launch is labeled unaudited until the report is published.
- Updated
- 11 October 2026
Public reviewPlanned
Public review
- Pass threshold
- 30 days
- Current value
- Not measured yet
- What it measures
- Days the frozen candidate has been open to public review with a DGT bug bounty.
- Why it matters
- Anyone can inspect the code before it holds value, and reports are rewarded.
- Updated
- 11 October 2026
FindingsPlanned
Open findings
- Pass threshold
- 0 at launch
- Current value
- Not measured yet
- What it measures
- Audit, public review and AI review findings not yet fixed or answered on the record.
- Why it matters
- No finding may be silently dropped before launch.
- Updated
- 11 October 2026
AI reviewPlanned
AI review
- Pass threshold
- Published and labeled as AI
- Current value
- Not measured yet
- What it measures
- An adversarial review by an AI model of the candidate's code, published and labeled as AI.
- Why it matters
- It adds coverage, but it is not independent human review, and it is never presented as one.
- Updated
- 11 October 2026
Phase 06 · LaunchPlanned
Seven launch simulations
Seven full launches (R01 to R07) on the final candidate, each from clean hosts and a fresh rehearsal genesis, each operating for 24 hours.
- Seven full launches, R01 to R07, on the final candidate after the audit fixes.
- Each starts from clean hosts and a fresh rehearsal genesis and runs for 24 hours.
- R01 to R06 shorten long timings so each lifecycle completes in a day; R07 uses the exact production values.
- A missed threshold fails the run. The cause is fixed in a new candidate and the affected runs start again.
0 of 25 passed0 in progress25 not started
| Run | Integrity | Liveness | Inclusion | Recovery | Load | Result |
|---|---|---|---|---|---|---|
| R01 Clean genesisThe full launch with rehearsal identities: genesis, wallets, staking, transfers, fees and rewards, with supply reconciled at each checkpoint. | Planned | Planned | Planned | Not applicable | Not applicable | Planned |
| R02 Infrastructure failureProcess kills, the sentry stopped and restored, a destroyed sentry, a network cut and a lost validator host, each recovered and checked. | Planned | Planned | Planned | Planned | Not applicable | Planned |
| R03 Adversarial networkLatency, packet loss, a partition, malformed and invalid transactions and request floods from outside machines. | Planned | Planned | Planned | Planned | Not applicable | Planned |
| R04 Production upgradeA signed release handover and state upgrade from one candidate to the next, with state checked before and after. | Planned | Planned | Planned | Not applicable | Not applicable | Planned |
| R05 Operator errorWrong configuration, binary, network, genesis, peers and versions, and a second copy of the validator key. Each must be refused or harmless. | Planned | Planned | Planned | Planned | Not applicable | Planned |
| R06 Load and economic activity1,000 wallets, sustained load at full and half capacity, staking, governance and malformed traffic mixed in. | Planned | Planned | Planned | Not applicable | Planned | Planned |
| R07 Final dress rehearsalThe exact production launch procedure with production values, from six hours before genesis to 24 hours after. | Planned | Planned | Planned | Not applicable | Not applicable | Planned |
The thresholds for each column are under Pass criteria.
Phase 07 · LaunchPlanned
Dress rehearsal checkpoints
R07 follows the exact production launch procedure, with checks from six hours before genesis to 24 hours after.
- R07 follows the exact production launch procedure.
- Checks at 6 hours and 1 hour before genesis, at genesis, and 15 minutes, 1 hour, 6 hours and 24 hours after.
- The final simulation report is written after the 24-hour supply reconciliation.
0 of 7 passed0 in progress7 not started
- T-6hPlannedSix hours before
- T-1hPlannedOne hour before
- T0PlannedGenesis
- T+15mPlannedFifteen minutes after
- T+1hPlannedOne hour after
- T+6hPlannedSix hours after
- T+24hPlanned24 hours after
T-6h · Six hours beforePlanned
T-6h checks
- Pass threshold
- All 17 checks pass
- Current value
- Not measured yet
- What it measures
- Verify binaries. Verify checksums. Verify release commit. Verify genesis. Verify all genesis allocations. Verify DRT supply. Verify DGT supply. Verify validators. Verify validator keys. Verify infrastructure. Verify networking. Verify DNS. Verify RPC. Verify monitoring. Verify alerts. Verify backups. Verify recovery procedures.
- Why it matters
- The dress rehearsal follows the exact launch procedure, so the real launch repeats steps that have already passed.
- Updated
- 11 October 2026
T-1h · One hour beforePlanned
T-1h checks
- Pass threshold
- All 9 checks pass
- Current value
- Not measured yet
- What it measures
- Confirm validator coordination. Confirm genesis hash. Confirm binary hash. Confirm peers. Confirm system clocks. Confirm validator keys. Confirm configuration. Confirm token allocations. Confirm network parameters.
- Why it matters
- The dress rehearsal follows the exact launch procedure, so the real launch repeats steps that have already passed.
- Updated
- 11 October 2026
T0 · GenesisPlanned
T0 checks
- Pass threshold
- All 4 checks pass
- Current value
- Not measured yet
- What it measures
- Start validators. Confirm consensus. Confirm block production. Verify expected validator participation.
- Why it matters
- The dress rehearsal follows the exact launch procedure, so the real launch repeats steps that have already passed.
- Updated
- 11 October 2026
T+15m · Fifteen minutes afterPlanned
T+15m checks
- Pass threshold
- All 8 checks pass
- Current value
- Not measured yet
- What it measures
- Verify RPC. Verify wallet connectivity. Execute canonical PQC transaction. Execute DRT transaction. Execute DGT transaction. Create delegation. Verify fee accounting. Verify finalization.
- Why it matters
- The dress rehearsal follows the exact launch procedure, so the real launch repeats steps that have already passed.
- Updated
- 11 October 2026
T+1h · One hour afterPlanned
T+1h checks
- Pass threshold
- All 7 checks pass
- Current value
- Not measured yet
- What it measures
- Verify state consistency across validators. Verify wallets. Verify staking. Verify rewards. Verify token supply. Verify monitoring. Verify RPC infrastructure.
- Why it matters
- The dress rehearsal follows the exact launch procedure, so the real launch repeats steps that have already passed.
- Updated
- 11 October 2026
T+6h · Six hours afterPlanned
T+6h checks
- Pass threshold
- All 7 checks pass
- Current value
- Not measured yet
- What it measures
- Review telemetry. Review logs. Review validator participation. Review token accounting. Review transaction statistics. Review security alerts. Review staking activity.
- Why it matters
- The dress rehearsal follows the exact launch procedure, so the real launch repeats steps that have already passed.
- Updated
- 11 October 2026
T+24h · 24 hours afterPlanned
T+24h checks
- Pass threshold
- All 3 checks pass
- Current value
- Not measured yet
- What it measures
- Perform full supply reconciliation. Perform full validator review. Perform final state consistency review.
- Why it matters
- The dress rehearsal follows the exact launch procedure, so the real launch repeats steps that have already passed.
- Updated
- 11 October 2026
Phase 08 · LaunchPlanned
Genesis
The final inputs are frozen, the release and genesis are reproduced byte for byte, three of five root kits sign, and the founder signs off.
- The allocation ledger and the genesis time are frozen: a weekday at 14:00 UTC, at least 72 hours after the final build.
- A clean CI runner and a fresh container reproduce the release and the genesis byte for byte.
- Three of the five root kits sign the genesis, and the founder signs off.
0 of 3 passed0 in progress3 not started
Input freezePlanned
Final input freeze
- Pass threshold
- Frozen and published; genesis a weekday at 14:00 UTC, at least 72 h after the final build
- Current value
- Not measured yet
- What it measures
- The allocation ledger (buckets, holder grants, validator self-bond, DRT bootstrap) and the genesis time.
- Why it matters
- Genesis is reproducible only if every input is fixed and published first.
- Updated
- 11 October 2026
ReproductionPlanned
Reproduced byte for byte
- Pass threshold
- Both builds produce identical digests
- Current value
- Not measured yet
- What it measures
- Release and genesis digests built independently on a clean CI runner and a fresh container.
- Why it matters
- Anyone can check that the published binaries and genesis come from the published source.
- Updated
- 11 October 2026
Root signaturesPlanned
Genesis signatures
- Pass threshold
- 3 of 5 kits
- Current value
- Not measured yet
- What it measures
- Root key kits that signed the genesis.
- Why it matters
- No one person, and no two, can sign the genesis alone.
- Updated
- 11 October 2026
Approved before any run
Pass criteria
A missed threshold fails the run. All seven runs must pass on the final candidate.
Pass criterion
Integrity
Zero conflicts; one app hash; exact supply; no committed block lost
- What it measures: Conflicting finalized blocks, app hashes on every node at every checkpoint, supply reconciliation (DRT genesis plus emitted minus burned, DGT unchanged) and blocks lost in recovery.
- Why it matters: Safety first: a conflicting block or an unexplained supply difference stops the run.
- R01 Clean genesisPlanned
- R02 Infrastructure failurePlanned
- R03 Adversarial networkPlanned
- R04 Production upgradePlanned
- R05 Operator errorPlanned
- R06 Load and economic activityPlanned
- R07 Final dress rehearsalPlanned
Pass criterion
Liveness
Median at most 6 s; 99th percentile at most 10 s
- What it measures: Median and 99th percentile block interval outside injected faults.
- Why it matters: Shows the chain keeps a steady pace during the whole operating period.
- R01 Clean genesisPlanned
- R02 Infrastructure failurePlanned
- R03 Adversarial networkPlanned
- R04 Production upgradePlanned
- R05 Operator errorPlanned
- R06 Load and economic activityPlanned
- R07 Final dress rehearsalPlanned
Pass criterion
Inclusion
99% within 2 blocks at half capacity; none lost at full
- What it measures: Valid transactions committed within 2 blocks at half capacity, and transactions lost at full capacity.
- Why it matters: A valid transaction must be committed or refused at admission, never silently lost.
- R01 Clean genesisPlanned
- R02 Infrastructure failurePlanned
- R03 Adversarial networkPlanned
- R04 Production upgradePlanned
- R05 Operator errorPlanned
- R06 Load and economic activityPlanned
- R07 Final dress rehearsalPlanned
Pass criterion
Recovery
Validator restart 5 min; network heal 2 min; sentry rebuild 4 h; validator host 8 h; every fault alerts
- What it measures: Time to recover from each injected fault, and whether each fault raised its alert and resolved.
- Why it matters: Faults are certain over time; the targets bound how long users wait.
- R01 Clean genesisNot applicable
- R02 Infrastructure failurePlanned
- R03 Adversarial networkPlanned
- R04 Production upgradeNot applicable
- R05 Operator errorPlanned
- R06 Load and economic activityNot applicable
- R07 Final dress rehearsalNot applicable
Pass criterion
Load
1 h at full capacity and 6 h at half, 1,000 wallets, all other criteria met
- What it measures: Full capacity, about 180 basic Sends a block, held for 1 hour, then half capacity for 6 hours, across 1,000 wallets.
- Why it matters: Shows the production hosts sustain launch demand with the real fee and signature costs.
- R01 Clean genesisNot applicable
- R02 Infrastructure failureNot applicable
- R03 Adversarial networkNot applicable
- R04 Production upgradeNot applicable
- R05 Operator errorNot applicable
- R06 Load and economic activityPlanned
- R07 Final dress rehearsalNot applicable
Architecture and tests
What we test
Each design choice creates its own risks. Select one to see what could go wrong and which tests cover it.
Design choice
Post-quantum signatures
Every transaction, wallet, validator vote and peer identity is signed with ML-DSA-65 (FIPS 204).
What could go wrong
- ML-DSA-65 signatures are 3,309 bytes and cost more to verify than classical ones, so verification load is a way to slow the chain.
- A malformed or wrong-key signature that slips through would let someone spend another account's funds.
How we test it
- Invalid, wrong-key and truncated signatures, non-canonical and oversized envelopes, at least 3,000 attempts each.
- R06 pushes the block limit of 200 signature checks and the admission queue limit of 2,000 pending transactions.
Tested inCampaign: transactionsR03R06
Design choice
Post-quantum network
Nodes and clients connect over ML-KEM-768 key exchange in a post-quantum CometBFT fork, with no classical fallback.
What could go wrong
- A handshake flaw or an unexpected peer could reach the validator or split the network.
- Latency and packet loss change how fresh the sentry, the public node, is.
How we test it
- The negative peer tests: wrong-key, malformed and unexpected peers against the real transport.
- Invalid handshakes and wrong pins at the public node; latency, packet loss and partitions about 30 times each.
Tested inStaging: peer testsCampaign: networkR03
Design choice
One validator at launch
Two hosts: a private validator, and a sentry that is the one public node. The sentry serves clients over the post-quantum client channel, 16 connections and 2 per address.
What could go wrong
- If the validator stops, the chain pauses until it is restored. If the sentry stops, clients are cut off until it is back.
- A second copy of the validator key could sign a conflicting block and end the chain.
- Connection floods could lock wallets out of the public node.
How we test it
- Process kills, sentry restarts and rebuilds, host loss and network cuts, timed against the recovery targets.
- Connection floods, slow clients, oversized bodies and methods outside the allowlist.
- R05 checks that a second key copy at another address cannot reach the network.
Tested inCampaign: faultsCampaign: endpoint and RPCR02R05
Design choice
Bounded blocks and queue
Blocks of 1 MiB with at most 1,000 transactions, about 180 basic Sends; the admission queue refuses new transactions when full instead of dropping old ones.
What could go wrong
- Floods, duplicates and re-signed copies could crowd out valid transactions.
- Under load, transactions could be delayed or lost.
How we test it
- Duplicate bytes, re-signed copies, stale, future and conflicting nonces, and fee caps below the minimum.
- R06 holds full capacity for 1 hour and half capacity for 6 hours across 1,000 wallets.
Tested inCampaign: transactionsCampaign: performanceR06
Design choice
Two tokens, burned fees
DGT is fixed at 1 billion. DRT pays every fee, every fee is burned, and issuance adapts from 1,000 to 500 DRT a block with use.
What could go wrong
- An accounting error could create or destroy tokens without anyone noticing.
- Fee and reward rules are a target for overspending and repeated claims.
How we test it
- Supply is reconciled exactly at every checkpoint: DRT genesis plus emitted minus burned, DGT unchanged, account totals equal to the supply counters.
- Overspending, repeated reward claims and fee caps below the minimum.
Tested inPass criteria: integrityCampaign: transactions and stakingEvery run
Design choice
Staking, governance, recovery
Bonding, 14-day unbonding, reward claims, governance votes with a 2-day timelock, and account recovery are ordinary transactions.
What could go wrong
- Early withdrawals, double claims, replayed votes or out-of-bounds parameter changes.
- A replayed or wrong-key recovery transaction could take over an account.
How we test it
- The staking, governance and recovery attack families, at least 3,000 attempts each.
- The endurance run covers a full unbonding and full governance periods at production values.
Tested inCampaign: staking, governance, recoveryCampaign: enduranceR04R06
Design choice
Three-of-five root controls
Genesis, upgrades and emergency freezes need three of five SLH-DSA key kits, each held by a different person.
What could go wrong
- A control signed by too few kits, replayed, or used outside its window.
- An upgrade that changes state incorrectly or cannot be aborted.
How we test it
- Too few signatures, keys from the wrong epoch, replayed sequences, expired windows and non-canonical encoding.
- Kit drills in staging; R04 runs a signed release handover and state upgrade end to end.
Tested inCampaign: root controlsStaging: root kitsR04Genesis
Design choice
Verifiable state and restores
State is a Merkle tree over SHA3-256; nodes join from snapshots and restore from daily encrypted backups.
What could go wrong
- Nodes could disagree on state, or a restore could lose or reverse committed blocks.
How we test it
- The same app hash on every node at every checkpoint, and no committed block lost in any recovery.
- Snapshot restores, state sync and an old-snapshot restore in R05.
Tested inPass criteria: integrityR02R05