— A SPENDING CARD FOR AI AGENTS

Give your agent a card,not your keys.

Mooring is a non-custodial spending card for AI agents — a budget, an allowlist, and an expiry, enforced on-chain on Stellar with every payment.

Join the waitlistSee how it worksOpen the app →
MOORING
ACTIVE

BALANCE

128.40USDC

DAILY BUDGET · 50 USDC15.60 spent today
C4X…MOORALLOWLIST · 3
SIGNER · agent·EXPIRES · 30dSTELLAR

soroban::custom_account

fn __check_auth(
  signature: AgentSig,
  payment: Transfer,
) -> Result<(), Deny> {
  policy.budget.check(payment)?;
  policy.allowlist.check(payment)?;
  policy.expiry.check(now)?;
  Ok(())
}

Scroll ↓

— THE PROBLEM

Today you have two bad options.

UNBOUNDED RISK

Hand over the keys.

Give the agent a raw private key and it can spend everything. One bug, one bad prompt, and the whole wallet is gone.

AUTONOMY DIES

Stay in the loop.

Approve every micro-payment by hand. Safe — but your “autonomous” agent now waits for you a hundred times a day.

There is no safe middle ground. Until now.

— THE MISSING PRIMITIVE

Mooring is that missing middle.

  • BUDGET

    Periodic budget

    Up to 50 USDC per day, resetting automatically.

  • ALLOWLIST

    Merchant allowlist

    Only merchants you approve ever get paid.

  • EXPIRY

    Expiry

    The card simply stops working when time runs out.

  • FREEZE

    Freeze & cancel

    Pause, kill, or withdraw — at any moment.

Not plastic. Not custody.

Every card is a Soroban smart account — the card is the contract.

MOORING
ACTIVE

BALANCE

128.40USDC

DAILY BUDGET · 50 USDC15.60 spent today
C4X…MOORALLOWLIST · 3
SIGNER · agent·EXPIRES · 30dSTELLAR

soroban::custom_account

fn __check_auth(
  signature: AgentSig,
  payment: Transfer,
) -> Result<(), Deny> {
  policy.budget.check(payment)?;
  policy.allowlist.check(payment)?;
  policy.expiry.check(now)?;
  Ok(())
}

— HOW IT WORKS

One request, fully guarded.

  1. 01 — REQUEST

    Request

    Your agent calls a paid API. The server replies 402 with payment terms.

  2. 02 — CHECK

    Check

    The client checks the terms against the card’s policy — budget, allowlist, expiry.

  3. 03 — SIGN

    Sign

    The agent signs the payment on behalf of its card.

  4. 04 — ENFORCE

    Enforce

    __check_auth validates the signer and the limits. Over budget? Rejected on-chain.

  5. 05 — SETTLE

    Settle

    USDC moves from card to merchant. Budget decremented. Resource returned.

— WHY STELLAR

Built where the rules can live on-chain.

Native account abstraction

The policy lives inside the authorization path. The card is the rule.

Contract-native authorization

Soroban gates the exact contract call — enforcement at settlement, no workarounds.

Sub-cent fees

Per-request micropayments that are actually economical.

First-class USDC

USDC via the Stellar Asset Contract, with optional passkey signers.

— WHO IT’S FOR

Anyone who lets software spend.

01

Agent developers

Give your agent a wallet without risking the whole balance.

02

Teams & businesses

Delegate recurring machine spend with a firm ceiling.

03

x402 providers

Get paid per request by agents that provably stay within limits.

— HONESTLY

What Mooring is not.

It doesn’t custody your funds.

It doesn’t run your agent.

It doesn’t decide what the agent buys.

It enforces the limits you set. The guardrail between an autonomous agent and real money.

MOORING
ACTIVE

BALANCE

128.40USDC

DAILY BUDGET · 50 USDC15.60 spent today
C4X…MOORALLOWLIST · 3
SIGNER · agent·EXPIRES · 30dSTELLAR

soroban::custom_account

fn __check_auth(
  signature: AgentSig,
  payment: Transfer,
) -> Result<(), Deny> {
  policy.budget.check(payment)?;
  policy.allowlist.check(payment)?;
  policy.expiry.check(now)?;
  Ok(())
}

— EARLY ACCESS

Moor your first agent.

Join the early access list and be first to issue a card.