Smart Accounts for AI Agents
Every wallet address in Loyal is a Smart Account with its own policies and spending caps — so your agents can't spend more or send funds somewhere you didn't approve.
Why we built this
AI agents are getting better at deciding what to do. They're worse at being trusted to do it with money. A trading bot might identify a good rebalance opportunity at 3am, but unless it can sign a transaction without your input, it can't act on it. A subscription agent can spot the API key you need to renew, but it can't pay for it. Today most agents are stuck at the recommend-but-don't-execute boundary.
The obvious fix is to give the agent a key. The obvious problem with that is that a key gives the agent unlimited authority — your entire wallet balance, any address, any contract, forever. A single jailbroken prompt drains the wallet.
Loyal takes a different approach using on-chain policy enforcement: the agent gets a key, but the wallet it points at is a Smart Account that decides what the key can actually do. The policy lives in an Anchor program on Solana — not on a Loyal server, not in a config file the agent could rewrite.
What an agent wallet on Loyal is
Every Loyal wallet is a Smart Account — a Squads-based on-chain program that holds the funds and evaluates every transaction against a policy you set. When you onboard an agent, the agent gets its own sub-account with its own signing key, and you assign it a permission tier plus, optionally, a spending cap and an allowlist of approved destinations.
The agent can sign transactions whenever it wants. The Smart Account decides whether to co-sign and let them land on Solana. If the transaction doesn't match the policy, it's rejected on-chain. There's no Loyal server in the loop that can be bribed or subverted; the rules live in Anchor programs.
Each agent on Loyal also has a name and an avatar — Stash, Spotty, Buddy — so you can see at a glance which agent is holding what and which one is allowed to do what. These are defaults; you can rename them and add more.
The agent layer is separate from the privacy layer. Loyal also makes USDC and SOL transfers unlinkable via a Confidential VM signer and a shielded vault — covered on the private transfers page.
The three permission tiers
Can Suggest
Can Sign
Can Execute
Spending limits and allowlists
Together, permission tier plus spending limits plus address allowlists form the agent guardrails every transaction is checked against on-chain.
Spending cap
Address allowlist
What you can build
Subscription agents
Trading bots
Social and content bots
MCP-driven assistants
Treasury operations
Commerce agents
Security model
On-chain enforcement
There's no off-chain rule-checker that can be compromised.
Squads underneath
The signing model has been battle-tested across thousands of teams.
Self-custodial
Revocable
No hidden execution
The result is a safe wallet for autonomous agent behavior at scale: every constraint is in code, on-chain, with no off-chain authority Loyal or anyone else can override.
For developers
The agent wallet is open-source and composable. Point your agent at a user's Loyal Smart Account with the @loyal-labs/private-transactions SDK — the Smart Account handles permission tier, spending cap, and allowlist enforcement on-chain.
Get started
Runs in the web app, browser extension, Telegram mini-app, and Android app — all backed by the same Squads Smart Account. Supported assets: USDC, SOL, USDT.
Questions?
Answers.
An agent wallet is a self-custodial crypto wallet designed for an AI agent to operate autonomously. It holds funds and signs transactions on the agent's behalf, but is constrained by an on-chain Smart Account policy — permission tier, spending cap, address allowlist — so the agent cannot exceed the limits its user defined. Loyal is an agent wallet on Solana with these guardrails built in.
Every wallet address in Loyal is a Smart Account — a Squads-based on-chain program with its own policies and spending caps. Agents you authorize get sub-accounts with permission tiers; the Smart Account evaluates every transaction against the policy before it lands on Solana.
Loyal has three permission tiers per agent: Can Suggest (agent proposes, you sign), Can Sign (agent co-signs alongside you), and Can Execute (agent signs autonomously within a spending cap and allowlist). Tiers are stackable across a fleet — different agents can run on different tiers at the same time.
No, with a permission tier and a cap or allowlist set. Can Execute is gated by a spending cap per period and an address allowlist. With both active, the agent's worst case is a transfer up to the cap, to an address you already trust. Can Suggest and Can Sign require your signature for every transaction, so an agent on those tiers can't move funds without you.
All three solve the same problem — scoped agent access without giving up the wallet — at different layers of the stack. Coinbase Agentic Wallets are wallet infrastructure for Base; MetaMask Advanced Permissions are an EVM standard (ERC-7715) implemented in the MetaMask Smart Accounts Kit. Loyal is a deployed self-custodial agent wallet on Solana with the same intent-based model, built on Squads smart accounts and the @loyal-labs/private-transactions SDK.
Yes via the SDK today. A dedicated loyal-mcp MCP server is on the roadmap. The current path is to wrap @loyal-labs/private-transactions in a thin MCP layer — straightforward TypeScript, a few hundred lines.
Three reasons. Transaction cost: agents that spend often need micro-spends to stay economical, and Solana fees are sub-cent. Latency: Smart Account policy evaluation finishes in one slot (~400ms), fast enough that agent-driven UX doesn't feel laggy. Composability: Squads, Jupiter, Phoenix, Kamino, and most of the agent-relevant ecosystem are Solana-native — which is why we think the best wallet for AI agents on Solana looks more like Loyal than like a generic EVM smart account.
Yes. Each agent holds its own signing key. You hold the Smart Account control key. Neither Loyal nor any third party can move funds without one of those keys. The Smart Account is policy-enforcement code, not a custodian.