FISCUS Request access
Non-custodial spend control for AI agents

Let AI agents spend money. Keep the keys.

Agents are starting to handle real money, and most ways to control them put a company in the middle who can touch the funds. Fiscus doesn't. You set the rules, a program on Solana enforces them, and no one, not even us, can move or freeze your money. Give an agent a budget, not your treasury. Live on devnet today; mainnet after audit.

Request access See how it works
  • Non-custodial: no one, not even Fiscus, can move your funds
  • On-chain rules: per-agent limits and approved payees
  • A human sign-off on large or unusual payments
  • A verifiable receipt for every spend
  • Live on devnet the Solana program is deployed and running today
  • 11 instructions, 83 tests policy, approval, and receipt paths, all green
  • Reviewed mainnet gated on an external audit
Devnet preview 
$ fiscus policy set \
  --per-tx-cap 1000 \
  --daily-cap 5000 \
  --approve-over 500 \
  --allow api.vendor.xyz,data.feed.io,invoice.co

POST /v1/policy
{
  "per_tx_cap": "1000.00",
  "daily_cap": "5000.00",
  "approve_over": "500.00",
  "allow": ["api.vendor.xyz", "data.feed.io", "invoice.co"]
}
01 · Programmable policy

Spending rules the chain enforces, not your prompt.

You set the limits: how much each agent can spend, who it is allowed to pay, when a human has to sign off. Those rules live in a program on Solana, so they hold even if someone gets past Fiscus. We check every payment against them first, in milliseconds, so an agent never even tries a payment it cannot make.

Devnet sandbox 
policy = {
  per_tx_cap   = "1,000.00 USDC"
  daily_cap    = "5,000.00 USDC"
  approve_over = "500.00 USDC"
  allow        = 3 payees
}
02 · Signed receipts

Every decision leaves a signed, verifiable record.

Authorized, declined, or pending: each call returns a verifiable receipt you can hand to an auditor. A settled payment carries an on-chain transaction ID an auditor can look up; a pending payment carries its hold signature and no settlement signature yet. A pre-check decline builds no transaction at all, so it carries a receipt id and is signed by a Fiscus attestation key you can verify offline instead.

Devnet sandbox 
receipt {
  status     = "authorized"
  payee      = "api.vendor.xyz · 7xKXtg…osgAsU"
  amount     = "42.00 USDC"
  settlement = "5VERv8…SZkQUW"
}
03 · Human approvals

A person clears anything at or above your threshold.

At or above your approval threshold, the agent broadcasts a hold. The vault program parks the funds on-chain and will not release them until an approver signs, so nothing large moves without a yes. The hold has its own signature; there is no settlement signature until it clears. Declines are never broadcast; pending holds are.

Devnet sandbox 
hold on-chain
  pending    = 1
  agent      = billing-agent
  amount     = "640.00 USDC"
  reason     = at or above approve_over (500.00)
  hold       = "4uKpRm…gtLnMr"
  settlement = none; funds have not moved
04 · Unified ledger

One record of everything your agents tried to pay.

Authorizations, declines, and approvals on a single continuous, exportable ledger.

Devnet sandbox 
ledger view
  authorized   = 128
  declined     = 6
  pending      = 1
  audit export = live
Pricing

A subscription for control, never a cut of your money.

Fiscus is SaaS: a flat fee per organization plus a fee per active agent. No spread, no take on volume. We sell the control and the audit trail, not the money movement. It is a security line item, not a payments fee.

A flat platform fee plus a per-active-agent fee. Exact figures are set with design partners.

Cost model Per org + per active agent
Control layer + policyper active agent
Signed receiptsincluded
Approval holds + inboxincluded
Spread / volume fee0%
Customer-managed keysincluded

Design partner

For teams putting autonomous agents into production now.

Request access

Team

For orgs running many agents across workspaces and policies.

Build team plan

Enterprise

For governance, dedicated regions, and audit-ready reporting.

Talk to us
Security

No one, not even Fiscus, can move your money.

Your funds live in a program account on Solana whose authority has no private key. Fiscus is never a signer. We enforce the rules you set and keep the receipts. We cannot move, freeze, or seize your money, even if we wanted to. That is the difference between a control layer and a custodian.

Two layers, and only one of them is binding.

The on-chain program is the real guardrail; our software is just a fast pre-check so agents don't waste a transaction.

Layer 1 · On-chain

The vault program is the control

Caps, payee allowlists and approval holds are enforced inside the vault program on Solana, by an on-chain program with no owner and no private key that owns the vault. If a transaction violates policy the program rejects it, whatever the caller believed. This is the binding control, and it does not depend on Fiscus being online, correct, or honest.

Layer 2 · Off-chain

The policy engine is a pre-check

Fiscus runs the same rules off-chain and answers authorize or decline inside the agent's loop. That is why a decline is never broadcast: no transaction is ever built, so there is nothing to send and no signature to show. It is a speed and cost layer, not the guarantee.

If Fiscus goes away

Revoking the Fiscus API key stops orchestration. The vault and its balance are untouched.

The vault is your program account on Solana, and the on-chain program that owns it, which has no owner and no private key, is the binding control. There is literally no key for anyone, including us, to hold, and it is not something Fiscus can be handed or take away. Cutting us off is an application-layer action: revoke the Fiscus API key and the orchestration and audit log stop. Your balance does not move, because it never sat anywhere else and Fiscus was never a signer on it. Whatever the vault program already enforces, it keeps enforcing without us.

Full policy control

First-class API for vaults, policies, approvals, and receipts. No lock-in to a proprietary workflow.

-> fiscus auth login
Enter code
FSC-9AMP

-> policy attach
workspace/agent-prod
openapi: 3.0.0
info:
  title: Fiscus API
paths:
  /vaults:
  /policy:
  /approvals:
  /receipts:

Built-in guardrails

These are structural. They hold because of how Fiscus is built, not because of a policy setting or a certificate. Nothing to configure, nothing to trust us on.

Never holds a signerYour keys, your vault, your funds
On-chain policyCaps + allowlists enforced by the vault program
Never in the settlement pathFiscus does not broadcast; a facilitator or public relayer settles

KYB and OFAC screening at onboarding is planned for launch, not shipped today.

Verifiable receipts

Verify us, don't trust us. Every payment that actually happens is recorded on-chain: check it yourself, no Fiscus involved. For payments we blocked before they hit the chain, we sign the record with a public key you can verify offline, a key that can prove what happened but cannot touch your money.

Devnet sandbox 
$ fiscus receipt verify rcpt_2f90b71a
decision      authorized & settled
record        on-chain event · vault program
payee         api.vendor.xyz · 7xKXtg…osgAsU
settlement    5VERv8…SZkQUW

$ fiscus receipt verify rcpt_8ad41c2e
decision      declined by pre-check
record        attestation; never broadcast
attested by   9xQmPz…AeHfGu
settlement    none; no transaction was built
Fee modelSaaS
SettlementUSDC
BuildLive on devnet

Who actually settles

“A third-party facilitator” is the box that would otherwise read someone else, so here it is by name. Fiscus does not operate a settlement facilitator and does not intend to. The v1 plan is to integrate Faremeter, the open-source x402 facilitator already adopted on Solana, rather than build one, with a public relayer as the alternative path.

That is the integration plan, not a shipped feature or an announced partnership. Operating our own facilitator is out of scope for v1. Either way the vault program stays the binding control, and Fiscus stays out of the settlement path.

How the vault gets funded

Your organization funds its own vault by transferring USDC into it, from any Solana wallet you control, or as an exchange withdrawal to the vault address. It is an ordinary transfer to an address you own. Fiscus is not involved in it, does not process it, and never takes possession. Agents then spend from that balance under policy.

Funding is a plain USDC transfer you make yourself. By design there is no fiat on-ramp, card top-up, or auto-refill in the money path, because that is exactly where a custodian would insert itself, and Fiscus does not.

Latency shape

The authorize pre-check is off-chain: it does not wait on a chain round-trip, so what sits inside your agent's tool call is ordinary API latency, not block time. Settlement happens separately and asynchronously. The agent is not blocked on confirmation, and the vault program is the binding control at settlement time rather than a blocking step in the decision.

We do not quote p50/p99 numbers we have not measured. What we commit to now is the shape: no chain round-trip in the authorize path. Measured figures ship with launch.

One place to see and control every payment your agents make.

Set the rules, watch the ledger, approve what needs a human, and export a clean audit trail.

Preview · the console we are building
Devnet sandbox

Authorization ledger

AgentPayeeAmountPolicyStatus
ops-runner-07api.vendor.xyz · 7xKXtg…osgAsU42.00 USDCwithin capsAuthorized
research-01data.feed.io · 4mNbQr…kD7pLe128.50 USDCwithin capsAuthorized
ops-runner-07compute.host · 2hVzTn…bRs6Wq1,900.00 USDCover per-tx capDeclined
billing-agentinvoice.co · 9dQpLm…4tVwZx640.00 USDCat or above approval thresholdPending

Policy: per-tx cap 1,000.00 · daily cap 5,000.00 · approve at or above 500.00 · 3 payees allowlisted. The pending row is an on-chain hold: hold sig 4uKpRm…gtLnMr, no settlement signature until an approver signs. The declined row was never broadcast, so it carries a receipt id only.

Authorized on devnetapi.vendor.xyz · 42.00 USDCsettlement sig 5VERv8…SZkQUW
Integrate

One command. Budget, approvals, and receipts for any agent.

Fiscus installs as one MCP server and an x402 surface: add it once and your agent gets a budget, an approval step for large payments, and a signed receipt for every payment, with no custom wiring. The server is in build now; the Solana program enforcing the rules is already live on devnet.

Request access Ask for a devnet walkthrough
The install we are building toward
$ claude mcp add fiscus -- npx -y fiscus-mcp Ships after the program is audited to mainnet

One line to give any MCP agent a budget, an approval step, and a receipt. The MCP server is in build; the Solana program it wires into is live on devnet today. Design partners get the server first.

Tools planned
  • fiscus_pay Request a payment. Checked against policy before it settles.
  • fiscus_policy_get Read the caps, allowlist, and thresholds bound to the agent.
  • fiscus_approvals_list See what is waiting on a human, and why it stopped.
  • fiscus_receipt_verify Verify a receipt by its receipt id: on-chain event or attestation.

The x402 surface for HTTP-native agents is planned alongside it. Reserved package names: npm · fiscus-mcp · npm · fiscus · github.com/fiscuslabs