Overview

AURA is two programs working together:

• aura-core — the deployed Anchor program. It owns the TreasuryAccount PDA and the full instruction surface: creating and operating agent treasuries, registering dWallets, evaluating policy, requesting FHE decryption, requesting dWallet signatures, and finalizing execution.
• aura-policy — a pure-Rust policy engine with no Anchor dependency. It is consumed on-chain by aura-core and off-chain by SDKs/tooling for simulation and preview, so the same rules govern both.

Why it's split this way

A treasury controlled by an autonomous agent has to satisfy three things at once: keep the agent's strategy private, let it operate freely within limits, and make those limits impossible to bypass. AURA separates concerns to achieve that:

• Solana is the control plane. All policy, limits, approvals, and audit live in aura-core. It never holds external-chain keys.
• Confidential guardrails (daily/per-tx limits + the running spend counter) are stored as FHE ciphertexts and evaluated by the Encrypt network — only a small violation code is decrypted, never the limits.
• Execution is MPC-signed. Approved proposals are co-signed through Ika dWallet records, so the agent is never handed a raw private key, and one Solana program can act across six chains.

How a proposal flows

A spend is never a single call — it moves through a policy gate, an optional confidential branch, an MPC-signing step, and a finalize step. Each stage is enforced on-chain.

For public proposals the policy decision is computed locally by aura-policy; for confidential proposals the amount-sensitive checks run under encryption on the Encrypt network. Either way, the dWallet signature is only requested after policy approves.

Explore the reference