Privacy¶
AURA Privacy
Confidential finance, not anonymous finance¶
A bank statement is private. When you pay someone, they learn that you paid them and how much, not your balance, your other payments, or who else you deal with. A public blockchain inverts this: anyone with your address can read your whole financial life. AURA Privacy closes that gap without becoming a tool for hiding from the law.
The standing rule
Private to the public. Visible to the people you choose. Provable to a regulator when the law requires it. Privacy here is an architecture and a disclosure model, never a promise of anonymity.
The problem with a transparent wallet¶
Suppose Alice holds 100,000 USDC and pays Bob 5,000.
| Party | Should learn | On a transparent chain actually learns |
|---|---|---|
| Bob | Alice paid him 5,000 | 5,000, plus Alice's 95,000 balance, her history, her other payees |
| The public | Nothing meaningful | Alice's full balance, transaction graph, counterparties, timing |
| AURA / Guard | Enough to screen for KYC, sanctions, risk | (off-chain, unchanged) |
| An auditor / regulator | Only what a lawful request covers | (nothing, or everything, neither of which is right) |
Hiding a single wallet address is not enough: the balance and history behind an address stay visible, and reused addresses re-link everything. Confidentiality has to be built into how value is represented and moved, not painted over the top.
Confidential by architecture, accountable by design¶
AURA's target is a layered model where the right information reaches the right party and nobody else.
flowchart TB
U["Alice"] --> ACC["AURA Account<br/>one balance, many keys"]
ACC --> PRIV["AURA Privacy<br/>encrypted notes · ZK proofs"]
PRIV --> CH["Public chain<br/>sees a valid state change, not the details"]
PRIV --> B["Bob<br/>sees only the payment to him"]
PRIV --> AUD["Auditor / regulator<br/>sees what a scoped viewing key allows"]
ACC --> G["AURA Guard<br/>KYC · KYT · sanctions, off-chain"]The public chain verifies a cryptographic proof that the transaction is valid, funded, and within policy, without the amount, sender, or recipient being published. Disclosure is then a deliberate act by the account owner, not the default.
Money as encrypted notes¶
A conventional token balance is a public mapping of address -> amount, which is why it leaks.
AURA's private layer represents value as encrypted notes (a UTXO model), where only the
owner can tell which notes are theirs.
Spending proves, in zero knowledge, that the inputs exist, are owned by the spender, have not already been spent, and that inputs equal outputs plus fee:
flowchart LR
N["Private note<br/>25,000"] --> ZK{"ZK proof<br/>own · unspent · balanced"}
ZK --> OUT1["to Bob<br/>5,000"]
ZK --> OUT2["change to Alice<br/>20,000"]
ZK --> NUL["nullifier<br/>old note cannot be reused"]The chain learns that the arithmetic is correct. It does not learn that Alice held 25,000 and sent Bob 5,000. This is the same shape of construction used by modern privacy systems such as Starknet's STRK20 and Aztec.
Selective disclosure: the view-key model¶
Privacy without disclosure is useless to a regulated product. Every account separates the key that spends from the keys that view, so showing someone your history can never let them move your money.
| Holder of the key | Can see |
|---|---|
| You (full) | Everything in your account |
| A recipient | Only the transaction involving them |
| Your accountant | A business's transactions, within scope |
| An auditor | A named account and period, under authorisation |
| A regulator | Only what a lawful request covers |
| The public | Nothing meaningful |
A viewing key is not a spending key
Compromising a viewing key must reveal information and nothing more. It must never authorise a payment. This separation is a hard security requirement, not a convenience.
Compliance without exposure¶
AURA proves a user is allowed to transact without putting identity on-chain. AURA Guard remains the off-chain engine that performs KYC, KYT, sanctions and risk screening; the result it issues is a signed attestation, and the chain checks a zero-knowledge proof of it.
The chain is asked to verify "this sender passed KYC, is not sanctioned, is in an eligible jurisdiction, and is within their limit", not "this sender is a named person with this passport." Identity stays with the user and SBX ID; only the claim travels.
This is the same AI boundary the rest of the system follows: the assistant may explain and propose, deterministic policy authorises, the contract enforces, the human approves, and the chain settles. See AI architecture.
Stealth addresses, one component not the whole¶
AURA also supports stealth addresses (ERC-5564, with the ERC-6538 registry) so a recipient need not reuse one public address. This hides the link between a payee and a permanent address, but it does not by itself hide the sender's balance, the amount, the transaction graph, or timing. Stealth addresses are one layer; the note model and selective disclosure are the substance.
What AURA builds, and what it stands on¶
AURA does not build a new blockchain. It owns the account, privacy, compliance, routing and experience layers, and settles on existing networks chosen per payment by AURA Flow.
| Component | Role |
|---|---|
| AURA Shield | Private balances (shield / unshield) |
| AURA PrivateSend | Confidential transfers with ZK verification |
| AURA View | Selective disclosure and viewing-key management |
| AURA Proof | Zero-knowledge compliance attestations |
| AURA Address | Stealth and single-use receiving addresses |
| AURA PrivateRPC | Private reads, so queries do not leak what you hold |
| Rail | Role in AURA | Status for AURA |
|---|---|---|
| Starknet + STRK20 | Primary private-payment rail: shielded USDC, private transfers, viewing keys | Evaluating |
| Aztec | Private programmable contracts (private state + execution) | Research |
| Ethereum | Settlement and security anchor, not the private execution layer | Planned |
| Native USDC + CCTP | The asset, and burn-and-mint cross-chain movement | Planned |
| Polygon CDK | A separate institutional private-chain option for banks | Research |
A privacy adapter sits between the AURA account and whichever rail is used, so the product is never hard-wired to one protocol. Starknet's STRK20 is the first rail AURA would prototype against because it already shields ERC-20 assets, including USDC, with a viewing-key disclosure model that matches "private by default, accountable when required." Aztec is tracked as research rather than a production dependency: its mainnet is still Alpha and disclosed a proving-system vulnerability in 2026.
One honest limitation, stated plainly¶
Privacy is not anonymity
No architecture on a public settlement network can promise that nobody can ever learn anything. The points where value enters and leaves the private layer, transaction timing, and network metadata can still create linkage. AURA commits to confidentiality of balances and relationships, plus selective disclosure, and designs routing to minimise metadata. It does not promise anonymity, and it is built so that a court order reaches the right records rather than an empty set.
In depth¶
This overview is the map. Each area has its own page:
| If you want | Read |
|---|---|
| How a balance becomes private and a payment proves itself | Private-money architecture |
| The key hierarchy and who can see what | Viewing keys & selective disclosure |
| Proving KYC and sanctions without exposing identity | Zero-knowledge compliance |
| Which networks AURA uses, and why Starknet first | Rails & chain strategy |
| What privacy does not hide, and how that is handled | Privacy threat model |
Status¶
Planned AURA Privacy is the roadmap, not the current demo. The live testnet application still uses transparent balances on Base Sepolia; see Implementation status. The note model, viewing-key separation, ZK compliance attestations, and the Starknet/STRK20 prototype are designed and under evaluation, and nothing here handles real customer funds today. The private-money MVP is the first phase of the roadmap.