System Architecture

Governing principle

AURA is an operating system for blockchain: a set of smart contracts with a good user interface. The contracts are the kernel, not plumbing under someone else's rails. Every security guarantee the product makes is enforced in the kernel. If a guarantee lives only in the UI, it is not a guarantee.

The decision everything follows from

The product makes security promises: trusted payees get less friction, large payments to new payees get more, very large ones need a second signer, sanctioned addresses are refused. There are two places those rules can live.

	Rules in the backend	Rules in the contracts
Compromise the backend	Attacker moves everyone's money	Attacker can submit, but not authorise
User verifies the rules	Must trust AURA's word	Reads the contract
"Non-custodial" claim	Weak, you enforce policy on their funds	Genuine, the account enforces its own policy
Enterprise API story	A SaaS product	Infrastructure others build on
Regulatory posture	Looks like control	Looks like software

AURA chooses the right-hand column. That is what "operating system" means here.

Layer map

flowchart TB
    subgraph UI["SHELL, what the user touches"]
        W["Next.js web app<br/>mobile-shaped"]
        AI["AI layer<br/>Concierge · Navigator · Address Intelligence"]
    end
    subgraph SVC["SERVICES, untrusted by design"]
        REL["Relayer<br/>submits, never authorises"]
        VER["Address Intelligence API<br/>AURA Guard"]
        IDX["Indexer<br/>ledger, statements"]
        ATT["Attestation issuer<br/>KYC to signed claim"]
        FAC["Second-factor service<br/>issues co-signatures"]
    end
    subgraph KERN["KERNEL, the product"]
        ACC["AuraAccount<br/>ERC-4337 + ERC-7579"]
        SEC["AuraSecurityManager<br/>hook · the auth ladder"]
        REG["AuraPayeeRegistry<br/>trust state"]
        SES["SessionKeyValidator"]
        PK["PasskeyValidator<br/>WebAuthn P-256"]
        REC["RecoveryModule<br/>timelocked"]
        PM["AuraPaymaster<br/>gas sponsorship"]
    end
    subgraph CHAIN["BASE"]
        EP["EntryPoint v0.7"]
        TOK["USDC · EURC · GBPT · USDT"]
    end

    W --> AI
    W --> REL
    W --> VER
    W --> IDX
    AI -.proposes only.-> W
    REL --> EP
    EP --> ACC
    ACC --> SEC
    SEC --> REG
    ACC --> SES
    ACC --> PK
    ACC --> REC
    EP --> PM
    ACC --> TOK
    ATT -.signed claim.-> ACC
    FAC -.co-signature.-> W

Three layers, one rule: the shell and the services are untrusted; only the kernel and the user's signature are.

The trust boundary that matters most

The relayer is untrusted. It can submit a UserOperation and it can pay for gas. It cannot authorise one. Compromising the relayer costs availability and money; it does not cost users their funds.

This is a deliberate correction to the obvious design. The natural reading of "emit an event, the relayer catches it, does 2FA, then executes" makes the relayer a trusted authoriser, a single point of compromise that can move every user's money. That is a custodian wearing non-custodial clothes.

Instead:

The second factor does not trigger execution. It releases a signature.

A separate second-factor service holds an independent key. When the user passes OTP or approves on a second device, that service returns a co-signature over the exact UserOperation hash. The account verifies both signatures. The relayer only carries bytes.

• The relayer can be a commodity bundler, replaced or run by a third party.
• The second-factor service can only ever co-sign what the user's device already signed.
• Neither service alone, nor both together, can move funds without the user's device signature.

Mapping to the named AURA modules

The app is the first consumer client of the company's infrastructure. Nothing is invented for AURA Money alone.

Capability in the app	AURA module	Where it lives
Payee verification, sanctions, risk scoring	AURA Guard	Service + on-chain policy in AuraSecurityManager
Auth ladder, limits, trusted payees	AURA Guard	Kernel, AuraSecurityManager + AuraPayeeRegistry
Route and currency selection	AURA Flow	Service (single chain in v1, framed honestly)
Transfers between accounts, later cross-chain	AURA Bridge	Service + CCTP adapter, chain 2 onward
Scheduled payments, payroll	AURA Treasury	Kernel module, later
API, SDK, auth, identity	AURA Core	SDK + relayer + attestation issuer

Request lifecycle: a Tier 3 payment

sequenceDiagram
    participant U as User
    participant App
    participant G as Guard API
    participant F as 2FA service
    participant R as Relayer
    participant EP as EntryPoint
    participant A as AuraAccount
    participant S as SecurityManager

    U->>App: Pay Sarah $2,500
    App->>G: re-screen payee (fresh, not cached)
    G-->>App: clear · risk low
    App->>App: build UserOp · compute hash
    U->>App: passkey signature
    App->>F: request co-signature (+ OTP)
    F-->>U: OTP
    U->>F: code
    F-->>App: co-signature over the same hash
    App->>R: submit
    R->>EP: handleOps
    EP->>A: validateUserOp
    A->>A: verify passkey sig + co-signature
    A->>S: preCheck(target, value, payee state)
    S->>S: score · Tier 3 · queue with delay
    S-->>A: QUEUED (not executed)
    Note over S: 30-min cooling-off · user may cancel
    R->>EP: execute queued intent after delay
    EP->>A: execute
    A->>A: transfer USDC

The contract enforces the tier, the delay, the cancellation window, and the two-signature requirement. The UI merely displays them. A malicious client cannot skip any of it.

What is deliberately off-chain

On-chain is expensive, public, and permanent. These do not belong there:

Off-chain	Why
Payee names	"Sarah Chen" on a public ledger is a privacy leak dressed as a feature
KYC documents and PII	Only a signed attestation reaches the chain
Risk scores and sanctions results	Provider data, changes constantly, commercially licensed
Statements and categorisation	Derived; rebuilt from chain rather than stored
AI conversation history	User data, not consensus data

Failure posture

If this dies	Effect	Mitigation
Relayer	No new payments; funds safe and withdrawable	Multiple bundlers; documented direct-submit escape hatch
Guard API	No new payees, no sends, fail closed	Never fail open. Refusing to guess is the product.
2FA service	Tier 2+ blocked; Tier 0/1 still work	Second device as an alternate factor
Indexer	History/statements stale; balances still read from chain	Chain is the source of truth for money
Paymaster funded out	Payments stall	Alerting on balance; user never sees gas
Privy	Users cannot sign in	The escape hatch below

The escape hatch

A non-custodial claim is only true if the user can leave. The user must always be able to withdraw their funds without AURA's cooperation, no relayer, no Guard API, no frontend.

The account contract is fully functional standalone, its address and ABI are published, and an emergency-withdrawal path is documented. It is a hard requirement, it will be tested end to end, and it is what makes the custody conversation with regulators winnable rather than hopeful.