Documentation

Usufra is a marketplace for GPU capacity bought ahead of time. A provider offers an idle window at a fixed discount to the on-demand rate and posts collateral against delivering it. A buyer pays once, holds the reservation at no carrying cost until a redeem deadline, and at that point either uses the capacity or sells it to someone else.

The reservation is a transferable bearer instrument. Holding it is proof of the claim, there is no account to be locked out of, and it can be sent to any address including one belonging to a machine.

1. List. A provider posts a window at a discount and freezes collateral against it.
2. Buy. Payment and ownership move in a single step. There is no state in which the money has moved and the reservation has not.
3. Hold. Free until the redeem deadline. Transferable and resellable throughout.
4. Redeem. The holder burns the reservation, which opens a delivery window and commits a proof chain the provider answers against.
5. Settle. The provider proves delivery and is paid. Partial delivery pays pro rata against the proof chain.
6. Or claim. If the provider does not deliver, the holder files a claim and is made whole from the collateral.

Terms differ per listing. A strict slot expires at its redeem deadline. A flexible slot allows late redemption and accrues a carrying charge against the holder from the deadline onward.

Every price on the market, whether a provider's original offer or a holder's resale, must sit at least 25% below the on-demand rate at the moment of that trade. Provider offers sit between 25% and 45% below.

This is enforced at settlement, not by policy. A resale above the ceiling is rejected. The consequence worth understanding is that someone who bought at a deep discount cannot resell at a shallow one: the discount survives every hop, which is what makes buying from a reseller as safe as buying from the provider.

Fees are 2.0% on a provider sale and 1.5% on a resale, of which 0.5% is a royalty back to the original provider.

A provider freezes collateral against every window they list, sized as a percentage of the on-demand rate at the time of purchase. A better track record earns a lower requirement, so a low tier posts more collateral rather than less.

An unrebutted non-delivery claim demotes a provider by two tiers, which raises their collateral requirement on everything they list afterwards. A provider sitting at T0 with claims against them was demoted there; they are not new.

Make-whole pays value, not price. A buyer whose capacity was not delivered receives what the capacity is worth at that moment, capped at the on-demand rate they originally priced against, not merely a refund of what they paid. That distinction matters precisely when it is most likely to be tested: a provider is most likely to fail when spot prices have spiked, which is exactly when a refund would leave the buyer short.

Sign up in the Usufra UI (email or Google). That provisions a primary wallet (0xA). On /agents create an extra embedded wallet, delegate it (0xB), allocate USDC and MON from 0xA, and copy the agent token. MCP spends 0xB only. Never delegate 0xA.

Two things are worth designing around. First, quotes are live book prices; re-quote rather than caching a price across a decision. Second, the agent token is a long-lived HMAC credential — do not put a Privy JWT in the MCP client.

Funding is permissioned, trading is not

An agent can trade freely with funds it already holds on 0xB. Drawing on a human's payment method is a different matter and always requires that human to approve each top-up individually. An agent that runs out of funds and stops is behaving correctly.

The market is exposed over the Model Context Protocol on streamable HTTP. There is nothing to install.

{
  "mcpServers": {
    "usufra": {
      "type": "http",
      "url": "https://usufra-gateway.onrender.com/mcp"
    }
  }
}

Sign up, create a delegated agent wallet on /agents, copy the agentToken, then spend with the urs_* tools. Demo sessions are gone.

A complete loop is urs_quote → urs_buy → urs_reserve_usage → urs_chat → urs_settle_usage.

Tools

urs_search_rights

List live compute rights with disclosure, supply and book.

urs_quote

Price a right from the live book. Returns askId + total.

urs_buy

Fill that ask from a delegated agent wallet (agentToken).

urs_reserve_usage

Escrow certificates (and USDC) against a usage session.

urs_chat

Chat through this venue's Mini as the reservation holder.

urs_settle_usage

Settle the reservation with the Mini receipt.

urs_portfolio

Holdings, reserved atoms, listed certificates, book USDC and escrow USDC.

The MCP server is a thin wrapper over a plain HTTP API at https://usufra-gateway.onrender.com. Use it directly if you are not running an MCP client.

GET  /urs/v1/rights                 live rights + book
GET  /urs/v1/inference              venue inference status (node only; no Mini URL)
GET  /provider/v1/legacy            Mini URL serving retired
GET  /provider/v1/routing/:tokenId  PROVIDER_NODE vs NONE
POST /provider/v1/device/start      enroll a node without Render env
POST /provider/v1/device/approve    Privy Bearer
GET  /urs/v1/agents/setup           signerId for 0xB addSigners consent
POST /urs/v1/agents/token           mint agentToken (Privy Bearer)
POST /urs/v1/actions/buy            fill an ask as 0xB
POST /urs/v1/actions/reserve-usage  open a usage session
POST /urs/v1/actions/chat           holder chat through the Mini
POST /urs/v1/actions/settle-usage   settle with the Mini receipt
GET  /urs/v1/usage/live             SSE lanes
GET  /urs/v1/portfolio?address=     holdings

Spend routes take agentToken. Humans can also fill an ask from the site with their primary wallet on the right's page.

None of this is needed to use the market, which is why it appears here and nowhere else in the product.

Settlement

Monad testnet, chain 10143

Instrument

ERC-1155 bearer certificate

Payment

EIP-3009 authorization consumed inside the purchase, so payment and mint are one state transition

Agent payments

x402

Fiat rails

Card and bank funding via Rain, settled to a supported chain and bridged

Delivery proof

Hash chain; the k-th preimage proves full delivery, the i-th proves i/k

Rain does not settle to Monad, in sandbox or in production. Fiat funding lands on a chain Rain supports and a bridge carries the last step. That seam is deliberate and is the only part of the money path that is not a single atomic transaction.

This is a Monad testnet deployment. Being specific about which half is which:

Real

Purchases, transfers, resales, redemptions, usage reservations, Mini chat receipts, delivery proofs, claims, collateral slashing and make-whole. All of it executes on-chain and is independently verifiable.

Simulated

Physical GPU delivery itself, and settlement of the fiat rails. The Mini is a real inference box; the GPU-slot SKUs are still a simulated fulfilment path.