What Solana Staking Delegation Teaches Us About AI Agent Authority

Signup Write New Story What Solana Staking Delegation Teaches Us About AI Agent Authority by Kenneth Onyebuchi by Kenneth Onyebuchi | @ kennethbuchi Independent Technical Writer at Self Employed Technical Writer focused on distributed systems, security architecture, cryptography, and AI infrastructure.

Technical Writer focused on distributed systems, security architecture, cryptography, and AI infrastructure.

Solana gives you three ways to let someone else act on your funds, and each one grants a different power. A stake authority can point your stake at a validator but can never withdraw it. An SPL Token delegate can send your tokens to any address, up to a cap you set. A liquid staking pool takes your SOL into a program's custody and hands back a token. This piece compares what each model lets a delegate do, what the three have in common, and how the differences decide which one an AI agent that pays for its own compute should get.

Every Solana stake account has two authorities defined at creation: a stake authority and a withdraw authority. According to Solana's stake account documentation, the stake authority can delegate the account to a validator, deactivate it, split it, merge it, and assign a new stake authority. It cannot withdraw. The withdraw authority can withdraw undelegated SOL, assign a new withdraw authority, and reset the stake authority, which makes it the authority of last resort.

A stolen stake authority key therefore lets an attacker deactivate your stake or move it between validators, which costs you rewards and time. The SOL stays in the account, and whoever holds the withdraw authority can replace the compromised stake authority.

Marinade Native is a live example of this split. According to Marinade's native staking repository, the user keeps the withdraw authority while Marinade's program holds the stake authority. Marinade can direct the stake, and the owner can take the SOL back without Marinade's cooperation.

A Solana token account can name one delegate and an allowance. Solana's spend permissions documentation describes the result: the delegate can transfer tokens out of the account up to the approved amount, and each transfer reduces the remaining allowance. The SPL Token program documentation adds that a delegate may transfer or burn up to the amount it was delegated, and it names that amount as the delegate's only limit, so the approval does not fix a destination. An account holds one active delegate at a time, and the owner's revoke instruction removes all of its permissions at once.

This is a different power from a stake authority. A stake authority has no path to move funds to an address of its choosing, and an SPL delegate has exactly that, bounded by the cap. If a delegate key is stolen, the most an attacker can take is the remaining allowance. The cap is the whole safety mechanism, which makes its size the main design decision.

Neither page describes an expiry. The documented ways an approval ends are revocation and the allowance reaching zero, so a time limit has to come from the owner revoking the approval or from a layer built on top of the token program.

Liquid staking moves custody. In Jito's design, depositors send SOL to a pool built on the SPL stake pool program, which holds the stake accounts and issues JitoSOL in return. Marinade Liquid runs on its own program rather than the SPL one and issues mSOL. In both pools the holder receives a claim token and no longer controls the authorities on any stake account.

Exit works differently too. The owner of a stake account or a token allowance can cut off the delegate with one transaction. A pool holder leaves by redeeming or selling the token, which depends on the pool's liquidity and on the program continuing to behave as written. The trust sits in the code and in whoever can change it. Marinade's contract addresses page lists the Liquid program's upgrade authority as a 6-of-13 multisig.

I've written before about exactly evaluating this tradeoff when comparing Jito and Marinade against wallet-balance reward mechanisms like Seasons. The mechanics differ enough that treating every non-custodial claim as equivalent is a mistake.

Three properties hold across all of them:

That third property is where the models diverge. A stake authority costs you rewards, an SPL delegate costs you the remaining allowance, and a pool's upgrade authority can reach every deposit in the pool.

Depends on the program and its upgrade authority

Reset the stake authority with the withdraw key

Delegating to a validator has not put principal at risk on Solana so far, because slashing is not live on the network. According to Everstake's overview, proposals to add it are still under discussion: SIMD-0204 would record evidence of slashable behavior and SIMD-0212 would set the penalties, which are not finalized. If slashing ships, a stake authority that picks a misbehaving validator could cost the owner part of the principal in addition to rewards, and the maximum loss for that model would no longer be rewards alone.

Scale is easy to overstate, so here are the dated figures. DefiLlama lists Jito at about $1.108 billion in total value locked as of October 16, 2026, and Marinade at about $763 million as of October 17, 2026, roughly $1.87 billion combined. Marinade's figure combines its Native, Liquid, and Select products, and the Native portion stays in accounts whose withdraw authority belongs to users. Total value locked measures how much money relies on each design. It makes no statement about incident history, and I make no safety claim from it.

Pick the narrowest primitive that matches the verb the agent needs:

The spending case is the one most agent builders face first. Suppose an agent rents GPUs at $2 an hour and expects 40 hours of work a week. A weekly cap of $80 in a stablecoin means a leaked key costs at most $80 before the owner revokes it. A raw API key with no cap has no such number, which is the problem I described in an API key is not delegated authority. Because the base approval has no expiry, the owner also needs a routine that revokes or reduces the allowance at the end of each period.

The stake authority is the best fit when an agent should never be able to move funds at all. A pool is the weakest fit for an agent that pays bills, because spending from a pool means redeeming first and the agent's risk then includes the pool's code.

The useful question for an agent on Solana is which verb it needs, because each delegation model grants a different one. Size the grant to the loss you can absorb if the key leaks, and write that number down before you deploy. If you are building agent payments, start with an SPL Token delegate and a cap, then tell me in the comments what cap you would set for a week of GPU rental.

What Bridge Multisigs Get Wrong About Byzantine Fault Tolerance