Roadmap (Open Work Only)

Last updated: 2026-05-04

Completed history lives in status.md. This file should only track unfinished work.

Validation corridor

• Carry the Iroha Connect hardening through the remaining SDK and workspace validation corridor.
  • P2P session claims, hashed token storage, focused Rust checks, JavaScript checks, JS dist, Python syntax checks, and shared relay-auth vectors are green as of 2026-05-01.
  • Python pytest, Kotlin/JVM, Java Android, and Swift package tests remain blocked by missing local tools/artifacts.
  • When the validation shell has pytest, a Java runtime, and dist/NoritoBridge.xcframework, rerun the focused Python Connect tests, ./gradlew :core-jvm:test --tests org.hyperledger.iroha.sdk.connect.ConnectWalletRequestTest --console=plain, the matching Java Android Connect wallet tests, and the focused Swift Connect/Torii tests.
  • Fold the Connect session/relay changes into the next broader cargo test -p iroha_torii, cargo test --workspace, and workspace clippy corridor when validation budget allows.
• Carry Offline V2 real-proof support through the remaining release corridor.
  • The native bridge prover FFI focused corridor is green as of 2026-04-30. Fold it into a broader cargo test -p iroha_core --lib, SDK test, and workspace clippy corridor when validation budget allows.
  • The pure Swift Offline V2 prover hot path is green as of 2026-05-01 with subsecond median native audit/redeem proofs on macOS arm64. Keep that benchmark in the next iOS-device corridor and broaden Swift package validation when budget allows.
  • Kotlin/JVM and Java Android now have the native Offline V2 instance-value groundwork and pure Java Halo2/IPA prover path, including focused JVM and Android harness coverage plus env-gated benchmark hooks. Keep the native prover tests, Swift/JVM cross-verification payload, and larger benchmark iteration counts in the next device and full-SDK corridor.
  • The Torii Offline V2 issuer hardening focused corridor is green as of 2026-05-01. Fold it into the next broader cargo test -p iroha_torii, SDK, workspace test, and workspace clippy corridor when validation budget allows.
• Carry native asset escrow through the remaining Aitai application corridor.
  • Wire the Sora Aitai application UI/backend onto the native numeric escrow ISIs and proof-carrying anonymous escrow helper surfaces, then subscribe through the numeric and anonymous escrow query/event APIs.
  • Add app-facing lifecycle events for transparent and shielded offer state changes, and keep any remaining Kotodama wrapper work scoped to app calls that still need contract compatibility.
  • Add end-to-end UI/client smoke coverage once the Sora Aitai application replaces the old contract escrow account path for both transparent XOR and shielded anonymous-asset offers.
  • Rerun the full Kotlin, Java Android, and Swift SDK suites after the Aitai app wiring lands and a Java 21 runtime is available in the validation shell.
  • Keep NFT/RWA escrow and court fee/payout generalization as separate follow-ups; the v1 primitive intentionally resolves only between the escrow seller and accepted buyer.
• Carry the Soracloud production posture hardening through the operator-host rollout corridor.
  • Local focused, portable QEMU, and prior multi-peer load gates are green as of 2026-04-25; the readiness runner now reports missing operator inventory and missing observability evidence as production blockers. Before public rollout, run the mixed-host Inrou smoke with the real operator inventory, attach the real metrics/status/alert/dashboard evidence, and archive a blocker-free readiness report.
• Carry the new Taira devex CLI through the opt-in live rollout corridor.
  • The local CLI/Torii/mock-script validation for iroha taira doctor and iroha taira write-canary is green as of 2026-04-25, but no live Taira write was run from this tree.
  • Before publishing a live receipt, run iroha taira doctor --public-root https://taira.sora.org and an operator-approved iroha taira write-canary --public-root https://taira.sora.org, preserving only the redacted receipt and any stable failure codes.
  • Fold the Taira CLI/Torii changes into the next broader cargo test -p iroha_cli, cargo test -p iroha_torii, workspace test, and clippy corridor when validation budget allows.
• Carry the verified lane relay JSON-state/key change through the next UC6 integration corridor.
  • The focused crate checks are green as of 2026-04-24, but no live UC6 settlement-smoke run or topology reset has been performed from this tree.
  • Before any live deployment, confirm the deploy/Core API smoke path still uses relay_state_key, JSON relay state, and the simulation gate against the exact finalization payload.
  • If a topology plan selects reset mode while validating this change, stop before approval and reassess the rollout scope.
• Carry the Torii routed-read and telemetry fixes through the next workspace validation corridor.
  • The crate-local sweep is green as of 2026-04-24 with cargo test -p iroha_torii --lib --features app_api,telemetry -- --nocapture.
  • When validation budget allows, carry the alias-routing and Torii telemetry slices through the next cargo test --workspace / cargo clippy --workspace --all-targets -- -D warnings corridor and record the result in status.md.
• Broaden validation for the new canonical account-alias lease flow beyond the focused onboarding and executor checks.
  • The onboarding auto-renew path now grants the subscriber CanModifyNftMetadata for the subscription NFT before trigger registration; rerun a wider cargo test -p iroha_torii window with the new /v1/accounts/{account_id}/aliases, /renew, and /auto-renew handlers enabled.
  • Add or rerun focused coverage for user-signed enable/disable mutation flows and the SNS subscription auto-renew billing path in crates/iroha_core/src/smartcontracts/ivm/host.rs, not just the onboarding enqueue path.
  • Once the alias lease slice is stable under those focused reruns, fold it into the next broader cargo test --workspace / cargo clippy --workspace --all-targets -- -D warnings corridor.
• Keep the Sumeragi main-loop broad corridor attached to future consensus changes.
  • The 2026-05-03 cargo test -p iroha_core --lib rerun is green (5129 passed, 22 ignored) after fixing execution-witness recorder isolation and hardening the RBC sidecar cooldown fixture.
  • The later 2026-05-03 restarted-peer commit-QC recovery fix is covered by a focused unit regression and the confidential downtime plus timeout localnet scenario. Rerun the full cargo test -p iroha_core --lib corridor after the next main-loop edit or before opening the next full workspace sweep.
  • For the next consensus change, rerun the same broad window so the collector fallback, exact-frontier repair, cached-target, vote replay, roster recovery, future-new-view, and model-backed reschedule fixtures continue to execute together rather than only as isolated filters.
• Broaden Sumeragi verification when new fatal hang classes are identified outside the current two-slot frontier abstraction.
  • The 2026-05-03 frontier formal process hardening is green and covers active pending progress touch, local-vote and commit-QC progress, stale recovery subject-view scope, vote-queue drain, payload recovery, quorum retransmit, retransmit follow-through, and future-slot promotion.
  • For any additional fatal hang shape, first add a focused Rust regression, then add the corresponding finite formal dimension or mutation so the expected-failure suite proves the model would have caught it.
  • If another restarted-peer catch-up issue appears in message admission or deduplication, add a small finite admission-order bridge or mutation before broadening the frontier model itself; the current model intentionally abstracts network-message dedup away.
  • Keep this scoped to the observed hang surface; do not generalize the model into an arbitrary pipeline unless a new bug requires more than the active plus one-future-slot abstraction.
• Reopen the wider validation corridor after the recent focused iroha_core, iroha_torii, and iroha_data_model test additions.
  • cargo test -p iroha_core --lib is green as of 2026-05-03; rerun it only after the next core/consensus change or before opening the full workspace corridor.
  • cargo test -p iroha_torii is green as of 2026-05-03 after fixing the macOS attachment-sanitizer subprocess wrapper path; rerun it after the next Torii/API change or before opening the full workspace corridor.
  • Rerun cargo test -p integration_tests -- --nocapture once the current tree is stable enough for network suites.
  • When validation budget allows, rerun cargo test --workspace and cargo clippy --workspace --all-targets -- -D warnings, then capture failures or green status in status.md.

Consensus and Izanami

• Maintain Izanami communication vulnerability publication evidence.
  • The exact-injector 75% packet-loss 2026-04-26 paper-shaped run at dist/izanami-exact-packet-paper-20260426 is green for both permissioned and NPoS Sumeragi and is recorded in status.md; keep this as the current full-matrix resilience baseline.
  • Native in-process P2P packet-drop injection is wired into packet-loss and leader-targeted leader-isolation; the matrix runner now supports the paper's 133s-266s timed fault window plus configurable packet-loss sweeps (75% quick, 25%/50%/75% paper). The explicit 25%/50%/75% paper packet-loss sweep at dist/izanami-packet-sweep-paper-20260427-loss-only is green for both permissioned and NPoS Sumeragi and is recorded in status.md.
  • The 2026-04-27 quick matrix at dist/izanami-quick-both-20260427 is green for all ten permissioned/NPoS rows, and the post-ingress-hardening leader-isolation rerun at dist/izanami-quick-leader-retry-20260427 keeps both modes resilient with zero acceptance markers.
  • The result-strengthened matrix and sweep tooling is implemented as of 2026-04-28, including bounded shutdown-drain accounting, latency/recovery evidence, NPoS repair-coverage telemetry, generated paper-style-final-report.md, and separate stress-400 / stress-800 profiles.
  • Seed-7 real stress evidence at dist/izanami-stress-400-seed7-20260428 and dist/izanami-stress-800-seed7-20260428 is refreshed and green as of 2026-04-29: both stress-400 and stress-800 report 14/14 resilient rows across permissioned and NPoS Sumeragi, with no real confirmation_queue_dropped pressure in the fresh artifacts. This is recorded in status.md.
  • Run the full paper/stress seed sweep with fresh binaries when validation budget allows: scripts/run_izanami_communication_vulnerability_sweep.sh --profiles paper,stress-400,stress-800 --sumeragi-mode both --seed-list 7,11,13,17,19,23,29,31,37,41. Paper rows must remain resilient; stress rows should stay reported separately as margin evidence across broader seeds.
  • Keep any future publication reruns split with --sumeragi-mode both so permissioned and NPoS Sumeragi classifications are not collapsed, and preserve per-loss packet-loss subrows when comparing against the paper's Algorand/Aptos/Avalanche/Redbelly/Solana baseline.
• Recalibrate the Izanami stable-profile acceptance envelope for sustained workload targets.
  • The fresh 4-peer permissioned 1 TPS / 300s / 100 blocks gate at dist/izanami-stable-gate-20260427-target100 is green and recorded in status.md.
  • The matching 200-block diagnostic at dist/izanami-stable-gate-20260427-rerun crossed the prior stall region and reached strict/quorum height 107 with zero submission or confirmation failures, but missed the target because the stable workload drained before 200 blocks.
  • Before the longer 3600s / 2000+ block acceptance pass, choose a sustained-workload gate or lower short-run target so the KPI measures liveness instead of exhaustion of submitted work.
• Root-cause the remaining NPoS soak/localnet collapse instead of keeping it as a log-only symptom.
  • Reproduce with preserved peer dirs and iroha_futures::supervisor=debug.
  • Identify the first exiting supervised child before investigating downstream connection refusals.
  • Cross-check peer logs with /v1/sumeragi/status counters so the fix targets the actual failing layer.

Throughput and query performance

• Re-establish current throughput knees for the de-amplified harness and shared-host localnet.
  • Rerun the stepped single-host sweep.
  • Repeat permissioned and NPoS passes on the same hardware envelope and compare against the archived 25-50 TPS / 75-100 TPS baselines.
  • Record the new knee points and any regressions in status.md.
• Turn the proposal-gap / queue-pressure investigation into a reproducible measurement pass.
  • Rerun the 7-peer load that previously advanced slowly or stalled under backlog.
  • Sample /v1/sumeragi/status, pending-block / commit-inflight metrics, and queue depths throughout the run.
  • Use a load generator that can actually sustain the target rate before changing worker/backlog tuning again.
• Rebaseline sorted asset-definition query performance.
  • Rerun snapshot_ephemeral_sorted_asset_defs_first_batch and snapshot_stored_sorted_asset_defs_first_batch on an isolated host.
  • If stored-mode still regresses, tune stored_sorted_fast_start_params / first-batch thresholds and keep the matching query tests aligned.
  • Restore a green cargo test -p iroha_core baseline for the query-performance branch after any tuning.

Targeted follow-ups

• Broaden Kura replay determinism beyond the focused unit corridor.
  • Add a real 4-peer restart integration test that commits route-sensitive asset, account, alias, and domain-owned state, rebuilds from Kura, and compares canonical WSV snapshot bytes across the restarted peers.
  • Add golden old-block Norito fixtures produced by a pre-context binary, rather than only synthesized absent-field decode tests.
  • Profile the post-commit canonical WSV checkpoint hash under sustained load and either record the accepted overhead or replace it with a cheaper committed state-root path.
  • Decide whether a failed post-commit WSV checkpoint write should escalate the peer immediately after the block is committed, instead of only logging and failing later replay.
  • If operators need a network-authenticated replay proof, promote the WSV root from a local Kura sidecar into block-committed or certificate-bound metadata.
• Broaden alias auto-renew mutation coverage beyond the focused onboarding grant.
  • Add an integration test proving a user-signed enable/disable update can mutate the subscription NFT created by onboarding.
  • If a non-onboarding mutation path still hits Can't modify NFT from domain owned by another account, capture the exact submitter, NFT id, and permission token shape before changing the permission model again.
• Add a live multi-peer multisig test for previously unregistered signatories.
  • Start from the existing materialization coverage in integration_tests/tests/multisig.rs.
  • Add a case where a signatory is materialized by registration and then successfully authors MultisigPropose / MultisigApprove on the network.
  • Assert transaction-authority shape and final instruction execution, not only account materialization.
• Extend and burn down the translation metadata audit backlog.
  • Refresh the translated docs/formal/sumeragi/README.*.md bodies after the English-only frontier formal and 2026-05-03 process-hardening updates so python3 ci/check_docs_i18n_metadata.py --paths docs/formal --require-current can be restored for formal docs.
  • The Sumeragi frontier model, process invariants, mutation suite, TLC cross-check, and longer nightly bound are wired, and CI now publishes a JSON metadata report for the stale translated formal READMEs; the remaining formal-doc task is translation refresh only.
  • Clean the existing docs/source and docs/portal metadata debt, including files missing source_hash and translation_last_reviewed, before adding those trees to the CI gate.
  • Refresh only the files the checker flags, then record the clean audit command in status.md.
• Add a recorded capture gate for the default sora-temple petal styles.
  • Use petal score-styles with a published style set, profile, seed, and minimum success ratio.
  • Record the JSON baseline in status.md and keep the default style honest under aggressive capture.
  • Only add a stronger default variant if the current sora-temple family cannot meet the agreed gate.