Skip to content

Identity & Keys

The most expensive thing to get wrong, because every mistake here migrates badly.

The key hierarchy

Key Held by Can it move money? Recoverable?
Passkey (P-256) User's device secure enclave Yes, with the tier satisfied Via platform keychain sync
Privy embedded key Split: provider / device / user Yes, as an account owner Via Privy re-auth
Session key App, scoped and expiring Only within its scope No, it is disposable
Co-signature key 2FA service No, never alone Rotatable by AURA
Sponsorship key Relayer No, only pays gas Rotatable by AURA
Deployer / owner keys Multisig + timelock No user funds Standard multisig procedure

The property that matters

No single key held by AURA can move a user's money, not the relayer's, not the 2FA service's, not the deployer's. That is what makes the non-custodial claim structural rather than promotional.

Two independent factors, on purpose

Privy provides sign-in and an embedded signer. The passkey is a separate validator registered directly with the account.

This redundancy is deliberate. A Privy compromise alone is insufficient to move funds, and it makes the "pluggable signer" real: if the custody read from counsel comes back badly, AURA can drop the Privy signer and run passkey-only, the account already supports it, and no user has to migrate funds.

Session keys: how Tier 0 is possible

Tier 0 (no prompt for small payments to trusted payees) is what makes this feel like a banking app instead of a wallet. It is also the largest self-inflicted risk if left unscoped. Every session key is bound, on-chain, to:

  • a per-transaction cap (proposed: the Tier-1 ceiling)
  • a cumulative daily cap, independent of the per-tx cap
  • trusted payees only, never an arbitrary address
  • the allowlisted tokens only
  • a short expiry (proposed: 7 days, re-issued silently on use)
  • instant revocation from the app

And it is revoked automatically on any new device, any credential change, any recovery, any risk event on a payee in scope, and any policy change.

A session key that could send to an arbitrary address would be a bearer instrument. This one cannot leave a pre-verified set.

Counterfactual deployment

The account address is computed via CREATE2 at signup and shown to the user immediately. The contract deploys on first use, paid for by the paymaster.

This matters for the product: a user can be given their account number and receive money before any contract exists on chain. The receive flow works from the first minute, and the user never learns the word "deployment".

Recovery (ADR-010)

Layered, with no AURA-held capability:

  1. Platform-synced passkey, the default; covers a replaced phone invisibly.
  2. Privy re-auth, the standard path back in.
  3. Optional guardians, M-of-N owner rotation, offered when the account holds value worth protecting, not at signup where nobody engages.

AURA has no rotation key and can never propose a rotation. A timelocked, platform-assisted path was considered and rejected: it would hand AURA a capability over user accounts, precisely the evidence of control that loses the custody argument. Not having it is worth more than the edge case it costs.

Accepted residual risk

A user who loses their device, loses Privy access, and never nominated guardians cannot be helped by us. This is disclosed in onboarding, and it makes guardian prompting a real product responsibility rather than an optional nicety.

AuraRecoveryModule implements guardian rotation behind a proof interface. Every rotation stays timelocked with user veto and all-channel notification; completing one revokes all session keys, un-trusts every payee, and imposes a cooling-off on large payments.

Compliance identity

KYC produces a signed attestation, not a PII record on-chain:

attestation = sign(issuer, { account, kycLevel, jurisdiction, expiresAt, nonce })
  • No name, no document, no date of birth ever reaches the chain.
  • AuraComplianceRegistry verifies the issuer signature and the expiry.
  • The hook can require a valid attestation before permitting an outbound transfer.
  • The issuer is SBX ID where it exists, otherwise a licensed provider.

Phase 4 upgrade path: replace the signature check with a ZK proof verifier, the user proves they hold a valid attestation without revealing which one, breaking the link between identity and on-chain activity. The registry is designed with that slot from day one, so it is an added verifier, not a migration.