The architecture, in detail.
v0.0 ships with 3 primitives β Arbitrum + Fhenix + x402/Permit2. What follows is the v0.1+ expansion path: 8 primitives, re-enabled when measured demand validates each one.
v0.0 simple β what ships first
- Arbitrum One β settlement, USDC, sub-cent gas, ~250β500ms blocks.
- Fhenix CoFHE β non-forkable FHE substrate; AES key wrapped as
euint256; runner decrypts under temporaryFHE.allow(). - x402 + Permit2 β HTTP 402 + EIP-3009 (one-shot tasks) and Permit2 + multicall (loop hire). One sig per task. Hard cap: 2 wallet popups.
v0.1+ expansion β what unlocks with measured demand
- EigenDA β hot ciphertext lane (replaces Pinata IPFS at scale).
- Arweave β permanent L4/L5 memory (Arweave bundles for cross-job pattern compounding).
- Lit Protocol V3 β multi-tier access control (replaces server-side Fhenix gateway permits at scale).
- EAS attestations β composable per-iter receipts external apps can reference.
- Phala TEE β attested inference backend; the second backend after AWS Bedrock.
- 0xSplits PullSplit β >3-recipient split waterfalls (royalties, multi-author bundles).
- Multicall3 β atomicity beyond per-iter advance-with-split (multi-checkpoint workflows).
Why ship simple first
Each deferred primitive is a real engineering surface. Shipping all 8 from Day-1 increases the surface area to audit, document, and demo by 8Γ. In contrast, the 3-primitive ship gets to a working buyer journey (chat β 1 sig β result in 60s) with one third the LOC.
Heavy v0.1 features stay in the codebase under services/arbloop/_deferred/ behind feature flags (FEATURE_ARBLOOP_DEFERRED_*). Re-enabling each is a 1-PR change with explicit Gstack-frame justification.
For builders
- β’ arb-loop landing β buyer-side product
- β’ Marketplace β power-user browse
- β’ Seller onboard β gasless EIP-712 publish
- β’ Docs β MCP host config + canonical onboarding prompt
- β’ GitHub β MIT, single-dev, 43/45 Gstack target