Skip to content
Reinkey

Metered x402 · Stellar

Give your agent the keys. Keep the reins.

Your agent opens a payment channel and pays for every call, every token, in milliseconds, without touching the chain. The seller settles thousands of payments in a single transaction. How much the agent can spend, and with whom, is decided by its account on Stellar, not by a server.

Try the demoRead the docs

Live on Stellar testnet. No custody, no sign-up, no API keys.

  • 1,000 payments, 2 transactions
  • Limits enforced on-chain
  • One line for sellers
agent-01 → demo-seller · stellar:testnetSimulation
Vouchers
0
Transactions
0
Channel: spent / deposit
0.0000 / 1.0000
Paid
0.0000 USDC
Same work with exact
0 tx · ~0s

Built on

  • Stellar
  • Soroban
  • x402
  • USDC

Products

One rail, three products.

Reinkey solves all three sides: the seller charges for exactly what was used, the agent spends from an account whose limits are written on-chain, and capital lends to an account it can't escape from. Use one, or all.

  • For sellers

    Reinkey Meter

    Bill per request, per token or per second. One line.

    • Request, token or second: you pick the unit
    • Vouchers verify off-chain: median under 1 ms
    • Thousands of payments settle in one transaction
    bash
    npm i @reinkey/meter
    Explore MeterQuickstart

  • For agent owners

    Reinkey Reins

    An agent account whose limits are enforced by the chain, not a server.

    • Daily and per-transaction caps
    • Allowed payees and trading pairs only
    • Freeze in one transaction, recall in one transaction
    bash
    npm i @reinkey/sdk
    Explore ReinsQuickstart

  • For capital providers

    Reinkey Float

    Working capital for agents. Risk is computed on-chain.

    • Investors deposit USDC and receive shares
    • Agents pay and trade on an uncollateralized line
    • Anyone can liquidate once value falls below the threshold
    bash
    curl -s https://reinkey.onrender.com/float
    Explore FloatQuickstart

Try it yourself

Be the agent. Pay first, then hit the limit.

Open a channel, make calls, stream a response token by token. Watch the voucher count climb while the transaction count barely moves. Then push the cap: the rejection comes from the account, not from a server.

Vouchers
0
Transactions
0
Paid
0.0000 USDC
Same work with exact
0 tx · ~0s
agent-01 · stellar:testnet

On-chain

Pay the seller

Stream

The response will stream here token by token. One voucher every 50 tokens.

Simulation: runs in your browser and makes no network requests. Rules, prices and reason codes match the product; on-chain steps are shown as ≈5 s instead of actually waiting.

Account rules

Daily cap
5.0000
Per-transaction cap
1.0000
Allowed payee
demo-seller
Daily cap0.0000 / 5.0000

Channel: spent / depositNo channel

Request and response trace

No requests yet. Pick an action and each line shows up here with its source and timing.

The difference

A payment doesn't have to be a transaction.

Today · x402 exact

~5 s per payment · one transaction each

  1. 01Sign for every call
  2. 02Submit the transaction
  3. 03Wait for the ledger (~5 s)
  4. 04Repeat on the next call

1,000 calls = 1,000 tx ≈ 83 min

Paying per token isn't practical. The agent's spending limit is either missing or lives on a server.

Reinkey · x402 channel

~2 ms per payment · signed voucher, no chain

  1. 01Open the channel once
  2. 02Sign a voucher per call (milliseconds)
  3. 03The seller settles in one transaction

1,000 calls = 2 tx

Pay per token or per second. The limit lives on-chain.

Measured on testnet; ledger ~5 s.

The problem

Agents are spending money. The rails aren't ready.

Today's x402 flow turns every payment into its own transaction. Too slow for fast calls, too costly for tiny amounts, too blunt for permissions.

  • Every payment is a transaction

    A ledger closes in about 5 seconds. Pay per call, and every request waits those 5 seconds.

  • Micropayments don't pencil out

    Sending a separate transaction for a 0.00002 USDC per-token fee makes no sense.

  • Keys are all or nothing

    Hand the agent your wallet and it can spend everything. Don't, and it can't do anything.

Payments move at the speed of the response. The limit stays on-chain.

How it works

Reins, channel, voucher.

Speed happens off-chain. Trust stays on-chain.

  1. reinkey.account on-chain
    daily_cap5.0000 USDC
    per_tx_cap1.0000 USDC
    payees[demo-seller]
    expires+30d
    01

    Put on the reins

    The owner sets up a Reinkey Account: a daily cap, a per-transaction cap and a list of allowed sellers. The rules are written on-chain.

  2. channel.open ≈5 s · ledger
    deposit1.0000 USDC
    payeedemo-seller
    expires+24h
    daily_cap1.0000 / 5.0000
    02

    Open the channel

    The agent opens a channel with the seller in one transaction and locks a deposit. The deposit counts against the daily cap, so a channel can't break the limit.

  3. OKvoucher #9980.4990~2 ms
    OKvoucher #9990.4995~2 ms
    OKvoucher #10000.5000~2 ms
    channel.claim1000 → 1 tx
    refund → agent0.5000 USDC
    03

    Pay, stream, settle

    Every request carries a signed, cumulative voucher that the seller checks in milliseconds. It all settles in one transaction, and whatever is left goes back to the agent.

Architecture

The facilitator can't touch the money.

Anyone can verify a voucher, and anyone can trigger settlement. Funds only ever go to the channel's seller.

OFF-CHAIN · MILLISECONDSON-CHAIN · ~5 S PER LEDGERStellar · SorobanAgent@reinkey/sdk · signs vouchersSeller APImeter() · 402 or 200Facilitatorverify · claim · pay feesReinkey Account__check_auth · caps, payeesChannel contractdeposit · vouchers · settlevoucher · ~1 msverifypolicy checkopen · 1 txclaim · 1 tx

  • Reinkey Account

    Soroban smart account, __check_auth

    Holds the funds and enforces the daily cap, the per-transaction cap and the allowed payees. A transfer that breaks the rules is rejected on-chain.

    The agent can't send funds to itself or to an unapproved address

  • Channel contract

    Deposit, vouchers, settlement

    Locks the deposit, verifies the cumulative voucher, settles and refunds. Because vouchers are cumulative, double spending is structurally impossible.

    open · top_up · claim · close

  • Facilitator

    x402 channel and exact schemes

    Verifies vouchers, triggers settlement automatically before the channel expires, and pays network fees. It has no authority to withdraw funds.

    exact is supported as a fallback

  • meter() middleware

    One line in the seller's API

    Prices an endpoint per call, per token or per second. Without payment it answers 402; with a valid voucher the request goes through.

    app.get("/api", meter({ price, unit }), handler)

Why Stellar: custom account auth (__check_auth), fee sponsorship, and transactions that cost a fraction of a cent.

Product

One line for the seller. Reins for the agent.

  • One-line integration

    app.get("/book", rk.meter({ price: 5000n, unit: "request" }), handler);

    Add meter() to an endpoint and 402 responses, voucher checks and settlement come built in. No subscriptions, invoices or dashboard setup.

  • Per token, second or call

    The seller picks the unit. Payment keeps up mid-stream.

  • Non-custodial

    Funds sit either in the agent's account or in the channel contract. The facilitator never holds them.

  • Caps enforced on-chain

    • daily_cap5.0000
    • per_tx_cap1.0000
    • payees[demo-seller]
    • __check_auth✓

    The daily cap, per-transaction cap and allowed payees are written into the Reinkey Account and enforced by __check_auth. The limit holds even if a server goes down or gets compromised.

  • No XLM needed

    The facilitator pays network fees. The agent only holds USDC.

  • Self-describing service

    OpenAPI, llms.txt, MCP and the Bazaar catalog: an agent can discover and call the service without reading the docs. A paid endpoint lists itself after its first verified payment.

Honest limits

What this isn't, up front.

Channels take the payments in between off the chain; they don't make the chain itself faster. Opening a channel and settling it are still transactions, and a ledger still closes in about 5 seconds.

  • Opening and settling are on-chain transactions (~5 s); the payments in between are not
  • Channels are one-way: from agent to seller
  • The seller must settle before the channel expires; the facilitator does this automatically
  • Runs on Stellar testnet, not mainnet
  • The contracts haven't been audited yet

Who it's for

Anyone selling calls, tokens or seconds.

  • 01

    API and data sellers

    Charge per call or per token, without subscriptions or invoices.

  • 02

    LLM and inference providers

    Get paid for exactly the tokens you generate, with a budget that can stop mid-stream.

  • 03

    Agent developers

    Give an agent spending power without handing over the wallet. The cap lives on-chain.

  • 04

    Platforms

    Products that want to set a separate limit for each of their users' agents.

Pricing

Free on testnet. Volume-based after that.

Everything runs on testnet today, at no cost. Pricing for the hosted service isn't set yet; the contracts and middleware are open source.

  • Testnet

    Live now

    Try it now with the hosted facilitator.

    Free

    No sign-up, no API keys.

    Integrate
    • Hosted facilitator
    • Live dashboard
    • Unlimited channels

  • Seller

    A monthly base plus a small share of settled volume.

    Soon

    Pricing will be announced with mainnet.

    See the live dashboard
    • Fee sponsorship
    • Audit trail
    • Automatic settlement

  • Your own facilitator

    The contracts and middleware, on your own server.

    Open source

    Nothing to pay us.

    OpenAPI schema
    • Channel and Reinkey Account contracts
    • meter() middleware
    • Facilitator server

No made-up numbers here: prices will show up once they're set.

Demo seller prices

The endpoints in the live demo are protected by meter(): the first request returns 402 with the terms, and a request carrying a voucher gets the response.

  • GET /demo/book0.0005 USDC / call
  • POST /demo/chat0.00002 USDC / token

Testnet USDC. The facilitator pays network fees.

FAQ

Frequently asked

Do I have to trust the facilitator?

No. Vouchers are verified by the channel contract, and funds only go to the channel's seller. The facilitator verifies, triggers settlement and pays network fees; it can't withdraw anything.

What if the channel closes before the seller settles?

The agent can only close the channel after it expires and a grace period passes. The facilitator settles automatically before that happens.

Can the agent spend more than its deposit?

No. A voucher above the deposit is rejected by both the facilitator and the chain (CHANNEL_EXHAUSTED), and the stream stops mid-sentence.

Can the agent move funds to its own wallet?

No. The Reinkey Account only pays allowed payees, and the chain enforces it (PAYEE_NOT_ALLOWED).

Does the agent need to hold XLM?

No. The facilitator pays network fees.

Why Stellar?

Custom account auth (__check_auth), fee sponsorship and very low transaction costs. Together they make on-chain spending limits and cheap channel opens and settlements possible.

Is this a DEX?

No. It's a payment rail with spending permissions. Agents use it to pay whatever service they need.

Which version of x402?

channel is a new scheme; exact is supported as a fallback.

This isn't a video. It's a live URL.

Call it with your own agent. The first request returns 402 with the terms; sign a voucher if you have a channel, or open one if you don't.

curl -i "https://reinkey.onrender.com/demo/book"

HTTP/1.1 402 Payment Required

llms.txtOpenAPI schema