How to Let an AI Agent Stake SOL Without Handing Over Its Private Key

TL;DR. You can let an AI agent stake SOL without its private key ever leaving the machine it runs on. The Hubra Agent API builds the stake transaction, the agent signs it locally, and /broadcast submits it. No API key, no sign-up. The agent's wallet keeps stake and withdraw authority. Native delegation goes to Hubra's validator at 5% commission and 0% of MEV.

Look closely at a few agent staking tools and you'll find a parameter called secretKey. It's the one-shot "stake" call: send the wallet address, the amount, and the key, and the server signs for you. It's convenient. It also means your agent's key just traveled over the internet to someone else's server, and you are trusting a promise that it wasn't stored.

For an agent that holds real SOL, that's the wrong default. The signature is the whole security model on Solana. Whoever signs, controls.

So when we built the Hubra Agent API, we made one rule: Hubra builds transactions, it never signs for you.

---

How agents stake SOL today

There are four patterns out there right now, and where Hubra fits.

The SDK route is fine if you want to write and maintain staking code. The institutional APIs are built for custodians and need an account and a key. Agent toolkits are great, but they usually wire you to one liquid staking token. And the one-shot tools trade your key for convenience.

The Hubra Agent API sits in the gap: plain HTTP, nothing to sign up for, and the key never moves.

---

The whole flow, in five calls

Base URL: https://hubra.app/api/v1. Amounts are decimal strings like "1.5", never floats. Errors come back as RFC 9457 problem JSON.

1. Discover

curl https://hubra.app/api/v1/strategies

You get the four live strategy keys. For staking SOL, the two that matter here:

2. Build the transaction

curl -X POST https://hubra.app/api/v1/stake \
  -H 'Content-Type: application/json' \
  -d '{"strategy":"sol-native-stake","wallet":"<agent-wallet>","amount":"1.5"}'

The response carries a base64 transaction, a hubra_token, and for native staking a stakeAccount pubkey. Save that pubkey. You need it later to deactivate or withdraw.

For native staking the transaction comes back partially signed: the server generates a fresh stake-account keypair and signs that slot only. Your agent signs as the wallet. For sol-liquid-stake it comes back unsigned.

3. Sign locally

Deserialize, sign with the agent's keypair, serialize. This happens on your side, with whatever signer you already use. Hubra never sees it.

4. Broadcast

curl -X POST https://hubra.app/api/v1/broadcast \
  -H 'Content-Type: application/json' \
  -d '{"signed_tx":"<base64 signed tx>","hubra_token":"<from step 2>"}'

You get back a signature and a Solscan link. For raSOL mints, also forward route: "sanctum", sanctumKind, and sanctum_order from the build response so the transaction goes through Sanctum's execute endpoint.

5. Exit when you want

• Native: POST /unstake with kind: "deactivate", wait out the cooldown, then POST /withdraw to close the stake account. Or kind: "instant", which routes the active stake account through Sanctum's depositStake for SOL right away, subject to Sanctum's liquidity and pricing.
• raSOL: kind: "instant" swaps raSOL to SOL through Sanctum, or kind: "slow" turns raSOL back into a native stake account first.
• Use POST /quote before an unstake to preview the output.

---

Why no API key is safe here

People sometimes read "no API key" as "no protection." It's the opposite. The API doesn't need to know who you are, because it can't move anything you haven't signed.

• The chain checks ownership. If the signing wallet doesn't own the SOL, the transaction fails on chain. The HTTP layer adds nothing on top of that, and doesn't need to.
• /broadcast only relays Hubra-built transactions. The hubra_token is an HMAC over the exact message bytes Hubra built. If the bytes change, the token stops matching and /broadcast returns 403. That keeps it from turning into a free RPC for anything.
• The token is short-lived. About two minutes, roughly one blockhash window. An expired blockhash couldn't land anyway, so just rebuild.

One thing worth doing anyway: decode the transaction before you sign it and check the program IDs and amounts. That advice applies to every API that hands you bytes, including ours.

---

What makes Hubra different for agents

• The agent API is the app. It's a thin layer over the same server actions that run the human app at hubra.app. When an agent stakes 1 SOL, it's the same mechanism as a person clicking Stake. No separate agent product to drift out of sync.
• Native and liquid from one endpoint. Switch strategy from sol-native-stake to sol-liquid-stake and the rest of the flow stays the same. Most agent tools give you one or the other.
• The validator is ours. Native stake and raSOL both sit with Hubra's own validator, vote account 7K8DVxtNJGnMtUY1CQJT5jcs8sFGSZTDiG7kowvFpECh. 5% commission, 0% of MEV. You can read both on chain before your agent stakes a single lamport.
• Built to be read by agents. Docs are published with an llms.txt index at docs.hubra.app/llms.txt, a skill file at docs.hubra.app/skill.md, and a Postman collection with every endpoint.
• Partner attribution is built in. If you're integrating Hubra into a product, pass a referral_code on stake calls. Codes come from partner.hubra.app.

---

Before your agent stakes

1. Call GET /api/v1/health to check the service is up.
2. Make sure the wallet has the SOL to stake plus a little extra for rent and fees.
3. Store every stakeAccount the API returns. That's your agent's handle on its own stake.
4. Decode and check each transaction before signing.
5. Read commission and MEV commission on chain for the vote account above.

Staking still carries risk, on any validator and with any token. An API that never touches your key removes one class of it, the one that has nothing to do with staking at all.

Full reference: docs.hubra.app/developer/overview.