Budgent

Solana wallet for AI agents. Set a budget, enforce it on-chain, see where every dollar went.

27N8hzrW2wt9aH124djxtbYjJXYurWsQ1e9d6h4Hpump

[Budgent @BudgentWallet]

$BUDGENT is live.

CA: 27N8hzrW2wt9aH124djxtbYjJXYurWsQ1e9d6h4Hpump

A Solana wallet built for AI agents. Set a budget with hard rules, your agent spends within them, you see exactly where every dollar went.
Scoped keys instead of full access. On-chain limits the agent can't break. Payments that carry their own context.

Website: https://t.co/9fbyTjhB5D
GitHub: https://t.co/failqfb0rG
Program: https://t.co/6k08E2FouK

Budget for your agent. Not keys to your wallet.





[Budgent @BudgentWallet]

Funding your agent on Budgent takes one step.

Create a vault, drop in USDC. The master key stays in your wallet - the vault is a Solana program account with no private key of its own. That's the pool your agent draws from, and nothing else is exposed.

[Budgent @BudgentWallet]

AI agents are about to be everywhere - booking travel, running research, managing subscriptions, hiring other agents to finish the job.

Every one of them will need to spend money, and right now there's no safe, standard way to let them. That's the gap Budgent fills.

As agents go from novelty to default, the wallet they run on stops being optional and becomes infrastructure.

[Budgent @BudgentWallet]

@CryptoFarhadHQ added

[Budgent @BudgentWallet]

Security – where Budgent stands

Two rules that never bend: the owner can always withdraw funds, and the program stays verifiable - a deterministic build whose on-chain hash matches the published source.

Live now: non-custodial withdraw, verified program, full on-chain enforcement (per-tx, daily, allow/block, co-sign, delegate kill-switch), and scoped revocable keys where the agent never holds the wallet.

Not done yet: an independent external audit. It's planned, and until it's complete we say so plainly - treat the amounts flowing through a vault conservatively.

The program id is public. Rebuild it yourself and check the hash. Don't trust, verify.

[Budgent @BudgentWallet]

Bought back supply and locked it on the dev wallet.

https://t.co/QsDedYXC2M

[Budgent @BudgentWallet]

Big payment on Budgent? It can require your sign-off.

Set a co-sign threshold and anything above it pauses in an approval queue instead of going through. Your agent keeps running on small stuff, you step in only when it matters.

[Budgent @BudgentWallet]

@BranchM @HinotoLLC @dexteraisol We greatly appreciate your support!

[Budgent @BudgentWallet]

One owner, many agents, separate vaults. Revoke one, the rest keep running.

[Budgent @BudgentWallet]

Two rules in Budgent that never bend: the owner can always withdraw, and the program stays verifiable - a deterministic build whose on-chain hash matches the published source.

Live today: non-custodial withdraw, verified program, full on-chain enforcement, scoped revocable keys. Not done yet: an independent external audit. It's planned, and we say so plainly.

The program id is public. Rebuild it and check the hash yourself. Don't trust, verify.

[Budgent @BudgentWallet]

How Budgent works, start to finish.

You fund a vault with USDC and keep the master key in your own wallet. The vault is a Solana program account - it holds the money, no private key for it exists.

You set the rules: spend caps, daily limits, approved domains, a co-sign threshold for big payments. They live on-chain, enforced by the program on every transaction.

Your agent gets a scoped delegate key and pays through a plain REST API. Create intent, execute, verify - and each payment carries its context, so your history reads like a receipt.

Break a rule and the program rejects the transaction. Something off? Revoke the key in one call. The owner can always withdraw.

Budget for your agent, not keys to your wallet.

[Budgent @BudgentWallet]

Every secret on Budgent sits where it should.

The master key never leaves your wallet. The delegate key lives in secure storage, not in your agent's code. Your HMAC secret stays server-side and the UI never sees it.

Nothing sensitive is ever floating where it shouldn't be.

[Budgent @BudgentWallet]

Daily limits on Budgent use a rolling 24-hour window, not a midnight reset.

So an agent can't blow the full cap at 11:59pm and the full cap again at 12:01am. Spending is measured against the actual last 24 hours, every time.

A tighter cap that actually holds.

[Budgent @BudgentWallet]

Funding more than one agent on Budgent? Each gets its own vault.

Separate budgets, separate rules, separate delegate keys. One agent burning through its daily cap never touches another's funds. Revoke one and the rest keep running.

Run a whole fleet, keep every agent boxed in on its own.

[Budgent @BudgentWallet]

The owner on Budgent can always withdraw.

No matter the policy, the delegates, or the pending queue, your master key can pull funds from the vault at any time. Nothing in the system can lock you out of your own money.

Non-custodial means non-custodial.

[Budgent @BudgentWallet]

Every payment on Budgent ends in one of three verdicts.

Settled: passed policy, confirmed on-chain. Reverted: broke a rule, rejected by the program, no funds moved. Held: waiting on your approval.

You always know exactly where a transaction stands - no guessing, no silent failures.

[Budgent @BudgentWallet]

Your agent hits an unknown domain on Budgent? You decide what happens.

Add domains to an allowlist and only those go through automatically. Anything new can be set to pause for your approval instead of paying blind.

Your agent stays useful without spending on places you never vetted.

[Budgent @BudgentWallet]

Big payment? Budgent can require your sign-off.

Set a co-sign threshold and anything above it pauses in an approval queue instead of going through. Your agent keeps running on small stuff, you only step in when it actually matters.

Control without being in the loop for every $2 API call.

[Budgent @BudgentWallet]

On-chain enforcement: the rule isn't a suggestion. The transaction just gets rejected.