Search...
⌘K
Blockchain Design & Chain Strategy
Authra operates on a dedicated blockchain network designed to maximize data integrity, scalability, and regulatory flexibility. The strategy is to maintain one unified global chain (the “Orbit” chain) rather than fragmenting into multiple regional chains, while using modular features to handle diverse compliance requirements.
Unified Orbit Chain: All Authra activity is settled on a single main chain (anchored periodically to Ethereum for security). This unification ensures
Shared Security and Liquidity: All participants (nodes, users, investors) support the same token and ledger, preventing fragmentation of $ATRX liquidity or duplicative infrastructure.
Developer Simplicity: There is one common chain configuration (sequencer, bridge, and DA/DAC), one SDK, and one integration path globally—partners don’t need to target multiple networks.
Operational Efficiency: The team maintains and upgrades one network, resulting in lower costs and faster iteration than managing many siloed chains. Features and fixes roll out network-wide, and the system’s full network effect is realized globally rather than in isolated pockets.
Base: Arbitrum Orbit (Nitro) L3
Settlement: Arbitrum One (L2) → Ethereum L1
Execution: EVM + Stylus (Rust/C) enabled at genesis for high-perf code paths.
Data availability (DA):
Primary DA: AnyTrust (DAC) at L3 (custom gas in $ATRX; minimal fees). Rollup mode remains our Plan B (L1 calldata/blobs) if DAC trust is questioned or a regulator requires stricter DA; migration is a planned regenesis with dual-run & state snapshot.
DAC policy: publish member list, quorum (e.g., M-of-N signatures), rotation cadence, and failure procedures in docs.
Fall-back / Plan B: Flip to Rollup mode (Ethereum calldata/blobs via L2) if DAC trust is questioned or regulator requires stricter DA. (Operationally this is a planned “regenesis” migration with dual-run & state snapshot). Finality and withdrawals follow the parent chain’s challenge period; users retain censorship-resistant “force-inclusion” via the Delayed Inbox.
AnyTrust Rationale & Policy: AnyTrust DA (cost & UX) with Rollup fallback. We use AnyTrust DA at L3 to keep per-proof fees dramatically lower and inclusion near-real-time by posting commitments on-chain while an independent, geographically dispersed DAC attests to data retention. We publish member list, M-of-N quorum, rotation cadence, and failure procedures, plus per-batch signature sets and signer liveness. If quorum degrades or stricter assurance is required, the chain falls back to Rollup mode (on-chain DA) as the default safety stance. Over time, governance broadens DAC membership (including community-run signers) and evaluates Orbit-compatible DA alternatives as they mature.
Sequencing & ordering: Start with single primary sequencer + hot standby, move to multi-sequencer with Timeboost auctions when we open order-flow (policy controlled by governance; bids in $ATRX). Timeboost is chain-opt-in, supports arbitrary ERC-20 for bids.
Temporal Anchoring Service (TA)
Aggregates multiple external time sources (GNSS, multi-NTP/PTP, cloud).
Validator nodes compute a trimmed-median Canonical Time Block (CTB) every second, signed with quorum keys.
Each proof object carries {canonical_ts, TCS, offset_vector, attestation}.
CTBs are anchored hourly to the data-availability layer for immutability.
Degraded mode: if quorum falls below threshold or source drift exceeds limits, proofs are still sealed but marked with TCS_degraded=true for audit clarity.
Validation & disputes:
(“Arbitrum Timeboost” – optional): The sequencer can auction priority inclusion for fair ordering with economic finality.
(“Arbitrum BoLD” – fraud proofs): Permissionless challengers can dispute invalid state transitions; disputes ultimately resolve on Ethereum, inherit the L2/L1 guarantees.
Censorship resistance:
Explicitly document the Delayed Inbox / force-inclusion path and expose tooling in our docs/UI (force-include after ~24h). Practically, if the sequencer fails to include transactions, users (or relayers) can submit them via the Orbit delayed inbox; after the force-inclusion window elapses, they must be processed per canonical ordering.
Sequencer, Challenger, and Infrastructure Policy (Best Practices)
Inclusion & Censorship-Resistance: The sequencer commits to publish a canonical mempool policy and MUST include any valid transaction within the force-inclusion window. Repeated censorship or failure to include valid transactions triggers automatic rotation procedures. CLI + UI documented for delayed-inbox submission; target ≤24h force-include window.
Liveness & Rotation: A standby sequencer (and/or committee) is designated with on-chain failover conditions (e.g., N consecutive missed intervals). Rotation events, along with the hash of the last processed inbox message, are posted on-chain. ≥99.9% sequencer availability; automatic failover after N missed intervals.
Challenger Set: Any party may run a challenger for BoLD fraud proofs. Minimum hardware specs and reference Docker images will be documented; slashing or bonding parameters for misbehavior (spam challenges) are set by governance pre-mainnet.
DA Provider Policy (AnyTrust DAC): DAC members sign availability certificates; honest majority assumption and key-rotation cadence published. If DA commitments fail (e.g., insufficient signatures), rollup mode activation is the default fallback.
Logging & Transparency: Sequencer and DAC publish audit logs of inclusion, timestamps, and signature sets. Weekly attestation reports, Merkle-rooted inclusion/latency logs and DAC signature sets committed on-chain.
Parameter Governance: All thresholds (e.g., rotation intervals, inbox windows) are set via governance with public RFCs; emergency council may enact temporary overrides with on-chain timelock and mandatory post-mortems.
Authra Chain-Health Oracle:
We continuously compute and publish an integrity score for the chain and DA path so operators, users, and integrators can automate mitigations and audits.
Endpoint: GET /api/v1/oracle/chain_health → { score: 0–100, as_of, components: { sequencer_uptime, inclusion_latency_p50/p95, delayed_inbox_depth, delayed_inbox_tti, dac_quorum_freshness, anchor_lag, open_disputes, challenge_resolution_time } }
Stream: WS /stream/chain_events (sequencer failover, DAC quorum dips/stalls, force-include activations, anchor commits, fraud-proof lifecycle).
Computation: Weighted composite of (i) sequencer availability and inclusion latency, (ii) delayed-inbox queue depth/time-to-force-include, (iii) AnyTrust DAC quorum freshness (M-of-N signer liveness, last cert age), (iv) L3→L2/L1 anchor lag, and (v) active dispute/BoLD metrics.
Governance: Weights and alert thresholds are parameters governed on-chain; sub-thresholds trigger documented actions (e.g., sequencer rotation, DAC escalation, Rollup fallback).
Verifiability: Oracle snapshots post a Merkle root of underlying logs the paper already commits to publishing, enabling third-party recomputation and audit.
Resilient Transport (Layer 3)
Offline/DTN mode: Devices buffer and sign proofs locally; gateways bundle and submit upon connectivity restoration.
Mesh-aware relay (optional/controlled): Where policy allows, nearby devices relay commitments (no PII) to increase chance of inclusion during partial outages.
Audit continuity: Bundle headers include sequence hints and time bounds so auditors can verify no gaps in inclusion after delayed submission.
Non-Consensus Roles (community-run, bountyable)
Scanners. Log/metrics scanners that watch inclusion latency, DAC signer liveness, delayed-inbox depth, and abnormal error rates across the data pipeline and contracts. Emit signed reports to the Chain-Health Oracle and raise alerts.
Indexers. Public, stateless indexer nodes that maintain low-latency query caches (REST/GraphQL) for search/analytics; not part of consensus.
Bridges/Relayers. Attested relayers that publish cross-chain proof bundles (e.g., L3→L2/L1 proof roots, QoE oracle updates) with replay protection and rate limits. Subject to slashing/bounties per governance policy.
(All features described at capability level; no sensitive parameters.)