Safety approach

Autonomy you can verify.

Letting an AI near a treasury is only acceptable if it can’t do the wrong thing. nebula’s answer is to keep the AI advisory and put every fund-moving action through four deterministic gates before it can ever broadcast.

The four-gate write pipeline

01
Policy

Every value-moving intent is checked against deterministic rules — allowlists, per-token and daily caps, slippage and health-factor floors, RWA eligibility. Violations are rejected before anything is signed.

02
Simulate

The transaction is simulated against live chain state first. If it would revert, move more than expected, or breach a limit, it never reaches your wallet.

03
Approve

Material-risk actions require explicit human approval. Low-risk actions can run inside a pre-authorized envelope; anything outside it asks you (or your multisig) to confirm.

04
Execute

Only then does it broadcast — signed by the wallet you chose for that action — and emit an auditable record of what was decided and why.

Principles

The AI advises; code enforces

The model proposes typed intents. It never holds keys and cannot move funds on its own. The guardrails are deterministic code and contracts, not prompts — so a wrong or jailbroken model still cannot break a limit.

No custody

nebula never holds your funds. You connect a wallet (or derive an agent wallet you control); signing happens client-side. There is no server-side key for the public console.

Verifiable identity

Agents carry an on-chain identity via ERC-8004 (Trustless Agents) — identity, reputation, and validation registries — so an agent’s track record can be checked, not just claimed.

Bounded autonomy

Autonomy is opt-in and capped. Leverage and hedging are strictly bounded. You set the envelope; nebula acts only inside it and escalates the rest to you.

Want the technical detail — the policy engine, simulation, and the ERC-8004 identity client?

Safety · nebula