Smart Accounts for AI Agents

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

You don't trust every agent the same way. Loyal's permission model has three levels, set per agent:

Tiers are per-agent and stackable across a fleet. A trading bot you wrote yesterday can run on Can Suggest while it earns your trust. A subscription paymaster you've been using for six months can run on Can Execute within a $200/month cap.

Spending limits and allowlists

Permission tier sets how an agent can transact. Spending limits and allowlists set what it can transact on. Together, permission tier plus spending limits plus address allowlists form the agent guardrails every transaction is checked against on-chain.

• Spending cap. A dollar amount per day, per week, or per month. The agent cannot exceed the cap, even with Can Execute. Caps reset on the schedule you set.
• Address allowlist. A list of pre-approved destinations: specific routers, payees, or contracts. Off-list destinations are rejected at the Smart Account layer.

The two are orthogonal. Combine them for fully scoped autonomy — for example, Buddy can execute up to $500/month, only to these three addresses.

What you can build

With scoped, on-chain enforcement, entire categories of agent behavior become safe to deploy without supervision.

Subscription agents

Autonomous bots paying for API credits, RPC endpoints, model inference. Can Execute with a monthly cap means a runaway agent can't drain the wallet.

Trading bots

DEX-routing strategies. An allowlist limits the agent to vetted routers — Jupiter, Phoenix, Raydium — so it can't bridge funds to an attacker-controlled venue.

Social and content bots

Agents that tip, reward, or pay creators on Solana. The cap limits the monthly budget; the allowlist restricts to known creator addresses.

MCP-driven assistants

Claude, ChatGPT, or any MCP-connected assistant signing transactions on the user's behalf. The user defines the tier and the cap; the assistant operates within them.

Treasury operations

A DAO or team treasury that delegates routine payouts to an agent (payroll, vendor invoices) while keeping principal signers on the multisig. Can Sign is the natural fit.

Security model

Every constraint is enforced on Solana, not on a Loyal server:

• On-chain enforcement. Permission tier, cap, and allowlist are all evaluated by the Smart Account's Anchor program before a transaction lands. There's no off-chain rule-checker that can be compromised.
• Squads underneath. The Smart Account is a Squads multisig — the most-deployed smart-account framework on Solana — extended with a policy module. The signing model has been battle-tested across thousands of teams.
• Self-custodial. 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.
• Revocable. You can revoke an agent's permissions at any time from the wallet UI. The change takes effect on the next transaction.
• No hidden execution. Every action the agent takes is a regular Solana transaction with the agent's signature on it. Block explorers see exactly what happened.

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. Two integration paths:

• Use the SDK. Your agent points at a user's Loyal Smart Account via @loyal-labs/private-transactions. The SDK exposes typed methods for proposing transactions; the Smart Account handles policy enforcement.
• Use the policy module directly. Extract programs/telegram-private-transfer/ from the loyal-app monorepo and run your own Smart Account stack with Loyal's policy logic.

MCP support today is via the SDK. A dedicated loyal-mcp server is on the public roadmap; until then, wrap the SDK in a thin MCP layer (a few hundred lines of TypeScript).

import { LoyalAgent } from "@loyal-labs/private-transactions"

const agent = new LoyalAgent({ smartAccount: "<address>" })

// The Smart Account evaluates the agent's permission tier,
// the user's cap, and the allowlist, then signs or rejects on-chain.
await agent.transfer({
  to: "<recipient>",
  mint: USDC_MINT,
  amount: 10_000_000n,
})

If the agent's tier is Can Suggest, the SDK returns a pending proposal the user can sign in the wallet UI. If the tier is Can Execute and the destination is on the allowlist and within the spending cap, the SDK co-signs and submits.

Get started

The agent wallet runs in three places, all backed by the same Squads Smart Account:

• Web app — askloyal.com
• Browser extension — Chrome, Firefox, Edge, Brave
• Telegram mini-app — @askloyal_tgbot

Supported assets at launch: USDC, SOL, USDT.

Frequently asked questions

Resources

• SDK quick-start — set up the SDK, propose a transaction, redeem a permission.
• Documentation — concepts, architecture, the full policy API.
• loyal-app on GitHub — the monorepo, including the Smart Account programs and the SDK source.
• Private transfers — how Loyal makes USDC and SOL transfers unlinkable, separate from the agent layer.

Stay Loyal.