FAQ
Answers to common questions about Aegis.
Frequently Asked Questions
Common questions about Aegis
Connected Wallet vs. Bot Signer — which should I use?
The right choice depends on whether a human is in the loop when your agent executes transactions.
Your wallet (MetaMask, Rabby, etc.) signs every transaction. The same wallet that controls the account also signs for it.
Best for:
- Testing and development
- Agents that need human approval per action
- Simple use cases where you're involved in each transaction
Gas:
Paid from your connected wallet's ETH balance.
A generated keypair the agent uses to authorize policy-enforced transactions autonomously. Your connected wallet remains the account owner with full withdrawal rights.
Best for:
- Fully autonomous agents running 24/7 on a server
- Agents that need to act without human interaction
- Multi-agent systems where each agent needs its own key
Gas:
On the recommended direct route, a small balance on the signer pays ordinary gas. On the bundler route, smart-account or EntryPoint prefund pays instead.
If I use a Bot Signer, who controls the account?
Your connected wallet is always the owner of the smart account — it can call execute() directly, which is how withdrawals work from the dashboard. The bot's private key is the restricted signer. On a capability-verified v16 account it can call the policy-enforced direct methods; on the ERC-4337 route it authorizes UserOperations. Neither route gives it the owner recovery bypass.
This means even if a bot key is lost or compromised, your connected wallet retains full access to withdraw funds and remains in control of the account.
Where is the bot's private key stored?
Nowhere on our side. The keypair is generated in your browser and offered once as a provisional signer backup before account creation. We never transmit or store it. Save that backup outside your repository. After permission minting, the browser can place the signer in the handoff ZIP alongside a public descriptor, separate route secrets, integrity hashes, and start instructions. The SDK installer verifies the package and writes secret-bearing files at mode 600.
What happens if my agent tries to exceed its policy limits?
The transaction reverts on-chain before execution. This is enforced inside AgentSmartAccount.validateUserOp(), which calls the PermissionEnforcer contract before any funds move. Because reverted logs are rolled back, the agent or relay reports the denied attempt to the audit API.
When do daily limits reset?
Daily limits reset at 00:00 UTC every day — a fixed calendar-day window, not a rolling 24 hours from the agent's first transaction. If your agent spends its full daily allowance at 11:50 PM UTC, the allowance is topped up again ten minutes later at midnight UTC.
Both the daily volume cap (e.g. ≤ 25 USDC/day) and the daily transaction-count cap reset together at the fixed UTC boundary, and they are tracked independently per asset — spending your USDC allowance doesn't touch your ETH allowance. The first recorded spend anchors that agent-and-asset usage window to its UTC calendar day; grant time does not start a separate window. Multiple permissions for the same on-chain agent and asset share that usage counter.
How do the Advanced time constraints work?
The Advanced section of a policy has two independent time controls, and they do different things:
A one-time window for the whole permission. Before Valid From it isn't active yet; after Valid Until it's permanently expired. Leave Valid Until empty for no expiry, and Valid From empty to start the moment it's granted.
Use it for: “this agent's authority is only good for the next 30 days.”
A recurring daily window. The agent may only transact between the start and end time every day; outside it, every transaction is rejected. The end time is exclusive, and both bounds are in UTC — 09:00 here means 09:00 UTC, not your local time.
Use it for: “the agent may only act during business hours, 09:00–17:00.”
Note: the Approved Time Range can't cross midnight in a single permission — the start must be earlier than the end (an overnight window like 22:00–06:00 isn't supported). Both are enforced on-chain in PolicyRegistry.isPermissionValid, so they apply to every transaction, not just dashboard previews.
Which networks are supported?
Currently Sepolia, Base Sepolia, Base mainnet, and Arc Testnet. Additional EVM-compatible networks can be added — the contracts are chain-agnostic.
How do I withdraw funds from a smart account?
From the Agents dashboard, open the menu on any agent card and select Withdraw. You can withdraw ETH or USDC back to your connected wallet. Gas is paid from your connected wallet — not the smart account — for dashboard withdrawals.
What's the difference between a Policy and a Permission?
A policy is a reusable set of rules — allowed actions, tokens and their limits, protocols, chains, recipients, and validity windows. It describes what is allowed but isn't attached to anyone. A permission binds a specific agent to a specific policy for a time window. It's the permission — once minted on-chain via PolicyRegistry.grantPermission and PermissionEnforcer.setConstraints — that the contract actually checks at runtime. One policy can back many permissions across different agents; the agent references its permissionId in every transaction.
Is the bot signer key the same as my wallet key?
No. The bot signer is a separate, low-privilege key generated just for the agent. It can only authorize only the account's agent execution paths, and every protected-fund action is policy-bounded — it can't move funds beyond the limits you set or to unapproved destinations. Your connected wallet remains the account owner with full withdrawal and revocation rights. The owner key is never needed at runtime and should never be placed in the agent's environment; if the bot key is lost or compromised, the owner still controls the account and the damage is capped by policy.
Do I need to fund the bot signer with gas?
It depends on the selected route. The recommended direct route for a capable generated-signer account needs a small native-token balance on the bot signer; that EOA balance is outside smart-account guardrails, so refill it conservatively. A configured ERC-4337 bundler keeps the signer empty and uses smart-account/EntryPoint prefund instead. Guided setup labels and funds the correct bucket for you.
Can funds only go to approved addresses?
Yes, on the v14 contract generation a policy can carry an allowed-recipients allowlist. It is enforced on-chain for native (ETH) sends and direct ERC-20 transfer / transferFrom calls — a transfer to an address outside the list reverts before it executes. Recipient decoding for funds routed through DeFi protocols (where the destination is buried in protocol-specific calldata) is still expanding, so treat the recipient allowlist as fully binding for direct transfers today, with broader protocol coverage rolling out over time. For LP and collect-style flows, the account can also require that proceeds return to itself.