Search...
⌘K
Authra Platform Overview and Architecture
tl;dr: Chain Strategy: Single Orbit, Modular Compliance
• One global Orbit L3, anchored to Arbitrum One → Ethereum for security and liquidity, serving as the settlement layer for Yeggina Proofs and their optional lanes.
• Modular compliance at the contract layer (Global, Enterprise, Regulated modes) rather than chain splits.
• AnyTrust DA primary; Rollup fallback for stricter assurance.
• Timeboost (opt-in) and BoLD fraud proofs; censorship resistance via Delayed Inbox.
The Three-Layer Global Trust Fabric (architecture view)
Layer 1 — Device Integrity (auditable, sovereign-ready): Only attested and whitelisted devices contribute proofs. Runtime checks and red-team adversarial testing harden the edge. We publish open verifier tools and proof harnesses so third parties can independently validate device attestations and signature flows. (Pre-NDA: we omit attestation policies, device class whitelists, and rejection thresholds.)
Layer 2 — Presence + Performance Proofs (Authra’s wedge): A single pipeline produces dual proofs: Proof-of-Presence (PoP) via multi-signal coherence (GNSS, cellular, Wi-Fi, Bluetooth) and Quality-of-Experience (QoE) via lightweight, adaptive measurements. Each record is TEE-signed on-device, aggregated into Merkle batches, and committed on-chain for public audit. This is the core for the Extensible Dual-Core Proofs (alt. Yeggina proofs).
We define this as a verifiable primitive that combines two mandatory signals — Proof-of-Presence (PoP) and Proof-of-Performance (PoQ) — into a single, auditable artifact. This dual core anchors the primitive, much as Merkle proofs anchor data inclusion. Crucially, Yeggina proofs are designed as an extensible family: additional optional lanes can be attached depending on market, compliance, or security needs. This construct of Yeggina proofs is a vector of verifiable signals:
{YP} = {PoP Δ, PoQΓ, Ep?, Pp?, Ts?, Cp?,..}
(where Δ, Γ = precision mode parameters for each signal.)
This extensible vector design ensures that Yeggina proofs remain a primitive with a stable core while allowing adaptation to new requirements over time. Currently, the primary candidate lanes include:
• Ep (Energy Proof): estimated device/network energy cost, optionally range-proved for spam resistance and sustainability metrics.
• Pp (Privacy Proof): attested redaction or differential privacy guarantees, optionally reinforced with zero-knowledge proofs.
• Ts (Tamper/Safety Proof): device integrity and attestation signals to prevent rooted/emulated submissions.
• Cp (Continuity Proof): path commitments and kinematic proofs that resist teleport or replay fraud.
Thus, every Yeggina Proof is a vector {PoP, PoQ, Ep?, Pp?, Ts?, Cp?, …} where PoP and PoQ are always present, and additional lanes are optional. This extensible structure ensures the primitive remains durable and adaptable as technology, regulation, and adversarial tactics evolve.
Precision modes (optional): For high-assurance contexts (e.g., SLAs, defense, fraud cases), validators may request GNSS-RTK–enhanced artifacts verified against third-party correction networks (e.g., base-station feeds) to achieve sub-meter confidence. Default PoP remains multi-signal GNSS+RF for broad coverage. As a soft presence corroborant—never as the primary proof—the app may record privacy-preserving BLE encounter sketches in background to strengthen visit/footfall confidence where OS allows.
Examples:
A consumer app may enforce PoP fuzzing of ±200m (Δ = coarse), median-only PoQ (Γ = basic), and activate Pp for privacy.
A defense SLA may require PoP accuracy <5m (Δ = strict), full QoE metrics (Γ = detailed), and enable Ts + Cp while disabling Pp.