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 Read the docs
  • 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
$ 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.

Illustrative. Final pricing published at launch.

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 come from how Fiscus is built, guaranteed by the design, not by a certificate we are still working toward.

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 (published at launch)
settlement    none; no transaction was built
Fee modelSaaS
SettlementUSDC
Buildv0

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 plan, not something shipped: no live integration today, no partnership to announce, no terms to quote. 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.

There is no fiat on-ramp, no card top-up, no auto-refill and no low-balance alerting. None of that is built. Topping up is a transfer you make yourself.

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 are not quoting p50/p99 figures we have not measured. Measured latency numbers will be published at launch; the shape, no chain round-trip in the authorize path, is what we commit to now.

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.

Fig. 2 · Fiscus web console
Devnet sandbox

Authorization ledger

New policy
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.

Payment authorized & settledapi.vendor.xyz · 42.00 USDCsettlement sig 5VERv8…SZkQUW
Integrate

One command is all it should take.

Fiscus is being built as an MCP server and an x402 surface. Add Fiscus once. Your agent gets a budget, an approval step for big payments, and a receipt for every payment it makes, no custom wiring. That is what we are building toward; it does not run yet.

Request access Read the docs
Intended install
$ claude mcp add fiscus -- npx -y fiscus-mcp

This command does not work yet. fiscus-mcp and fiscus are reserved npm names with no code behind them; the published packages are empty placeholders, so npx -y fiscus-mcp has no executable to start today. The command is here so you can see the shape we are building toward, not because you can run it. No release date to quote.

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