Safety & guardrails
How the wallet keeps you in control
The design principle is simple: the agent can plan, but only you can execute, and you only ever sign something that has been checked and simulated. Here is what stands between a request and your funds.
⚠ Beta — not yet audited
The connectors that move funds have not been externally audited. This is experimental software running on BNB Chain mainnet. Use small amounts you can afford to lose. You are always in self-custody, but unaudited code can still contain bugs.
You are always the signer
The agent never holds your keys and never broadcasts transactions on your behalf. It produces semantic actions only — it cannot produce final calldata. The wallet turns those into a transaction that your own wallet must sign. There are no session keys or delegated signing: every action needs a fresh signature from you.
Plan → encode → check → simulate → sign
Between your request and your signature, the wallet runs a fixed pipeline:
- Plan. The agent emits semantic actions.
- Encode. A deterministic backend expands them into atomic primitive steps and encodes canonical calldata — the single source of truth, not the LLM.
- Check. Policy guardrails run (below). A failed check blocks signing.
- Simulate. The whole bundle is run against live chain state with
eth_simulateV1; you see the balance deltas and resulting position contents. - Sign. Only then does it reach your wallet, as one atomic transaction.
Policy guardrails
Every bundle must pass these checks before it can be signed:
| Contract allowlist | Every call target must be your own account or a known Topaz contract. Anything else is rejected. |
|---|---|
| Connector allowlist | The multicall and every primitive connector must be configured and match the on-chain registry — the single security boundary for what code the account will run. |
| Slippage bounds | Swaps are capped at 5% (500 bps). Defaults are 1.5% for a plain swap and 3% for mid-flow ratio swaps (zap, rebalance, compound, single-token exit); you can override within the cap. |
| On-chain slippage | Runtime-sized swaps are additionally bounded on-chain by the pool's spot price and your slippage tolerance, so a step can't be sandwiched beyond the limit. |
| Deadline bounds | Transactions carry a deadline (default ~10 minutes), bounded to between 30 seconds and 30 minutes, so a stale bundle can't execute much later. |
| Stranded-funds guard | A bundle that frees funds must either sweep them back to your wallet or explicitly acknowledge keeping them in the account — funds are never left stranded by accident. |
| Amount sanity & cap | The native BNB attached must match the steps that consume it, and stays within a configured per-transaction cap. |
| Kill switch | Execution can be globally disabled by an operator flag if something looks wrong. |
On-chain protections
The account contract itself adds defense in depth:
- Owner-only execution — only your wallet can trigger any action.
- Registry-gated connectors— the account refuses to run any code that isn't an allowlisted connector, checked on every call.
- Reentrancy guard and nonce — entry points are reentrancy-protected and the execution nonce prevents replay.
- All-or-nothing batches — if any step in a batch reverts, the entire transaction reverts.
Current limitations
- Not audited. An external security audit of the connector / execution surface is pending before real funds at scale.
- No automation. There are no session keys, recurring jobs, or saved strategies yet — you sign each action as you make it.
- Migration scope. Bringing in existing positions currently covers concentrated-liquidity NFTs, not v2 LP.