Appendix: References & Glossary¶
ADRs¶
The architecture decisions this whitepaper rests on. Each is a recorded, dated decision with its context and consequences.
| ADR | Decision |
|---|---|
| 001 | The product is AURA Money, a name inherited from published work, not reinvented |
| 002 | Base only in v1; code is chain-agnostic, other networks by configuration later |
| 003 | Privy embedded wallet as signer controlling an ERC-4337 smart account; pluggable so it can be dropped for passkey-only |
| 004 | Full app shell, MVP substance, core banking is real; ramps, card, merchant QR are designed coming-soon states, built for an investor/partner demo |
| 005 | Chains are banks, addresses are accounts, the abstraction that drives all IA, copy, and error handling (details) |
| 006–009 | Contract architecture: the untrusted relayer, on-chain policy, Tier-4-to-loosen, the AI holds no key |
| 010 | Recovery, layered, with no AURA-held rotation capability (details) |
| 011 | Self-custody, no KYC in the MVP demo; identity verification arrives with cards and on/off-ramps |
Standards¶
| Standard | Role in AURA |
|---|---|
| ERC-4337 v0.7 | Account abstraction, seedless, gasless, batched operations |
| ERC-7579 | Modular smart-account standard, validators, executors, hooks, fallbacks |
| ERC-7562 | Bundler validation storage rules, why the auth ladder is enforced in execution, not validation |
| EIP-55 | Mixed-case checksum for EVM addresses, the deterministic typo catch |
| WebAuthn / P-256 | Passkey signatures from the device secure enclave |
| CREATE2 | Deterministic, counterfactual account addresses |
Glossary¶
Technical terms used in this whitepaper, with the banking word AURA shows a user.
| Technical term | AURA presents it as | Meaning |
|---|---|---|
| Chain / network | Bank | An independent settlement network (e.g. Base) |
| Address | Account | The destination a transfer settles to |
| Stablecoin | Currency | A fiat-denominated token (USDC, EURC, GBPT) |
| Gas | (hidden) | The fee to execute an operation; paid by the paymaster |
| UserOperation | (hidden) | An ERC-4337 intent submitted to the EntryPoint |
| Bundler / relayer | (hidden) | Submits operations on-chain; cannot authorise them |
Hook (preCheck) |
(hidden) | ERC-7579 interceptor that runs on every execution, the auth ladder |
| Session key | (hidden) | A scoped, expiring, capped key enabling no-prompt small payments |
| Attestation | (hidden) | A signed KYC claim carrying no PII on-chain |
| Reorg | (hidden) | A chain reorganisation; a cleared payment is corrected and the user told |
Links¶
- Live demo (testnet): dapp.sbxaura.com
- Product site: sbxaura.com
- Parent ecosystem: superblock.ai
One more time, because it matters
This document describes an architecture and a testnet demonstration. The contracts are unaudited, no real customer funds are handled, and nothing here is a solicitation or financial advice. See Implementation status and the pre-mainnet checklist.