Umbra

Private AI inference, paid per request. x402 · USDG · signed receipts · nothing stored. No API key, no account, no logs.

[Umbra @Umbra_Inference]

Settlement is the next step, indeed. Shipped it today.

Umbra now takes USDC on Base and Solana, verified and settled by @PayAINetwork, next to USDG settled by the gateway itself inside its enclave. One gateway, three ways to pay, and every receipt says which rail you used.

What did not change: the gateway runs in a TDX enclave, sealed models run in GPU enclaves, every answer carries a signed receipt, 0 bytes retained. The rail only decides who moves the money.

Three real settlements, three signed receipts:
• USDG, settled by the gateway: 0xf1628b29addbdf31679cf197e33d3533bcafdb236e404ded8507405d4a552609
• USDC on Base (Sepolia), settled by PayAI: 0xef6653a9fe71b9fc7c7dd85b3b09c3096a529f4aef348f69b42f1f2fc6a4ef5e
• USDC on Solana (devnet), settled by PayAI: 2bT6gtPnxgumyXgY2heATf3KxD87Piqx3NxfL81Hc6q4LvWdAzSABKMddtGu9BxkL66XLVBbtyL8GLhWucmjZStT

USDG stays the recommended rail: no third party in the payment, pay for the tokens produced, long requests settled first and refunded. Base and Solana settle the quoted ceiling and PayAI sees amounts and addresses, never prompts. Both honest options, both labelled.

Rails, schemes and trust notes, straight from the gateway: https://t.co/pnxKv6amWC

[PayAI Network | x402 Facilitator @PayAINetwork]

Circle shipping Claude Code skills that charge agents per API call in USDC over x402 says it plainly: x402 is how agents pay.

The build is one prompt now. Settlement is the next step, and PayAI Facilitator handles it on Base, Solana and more. https://t.co/SOCD9fc12U

[Umbra @Umbra_Inference]

Burn tally after three days: 17,852,010 UMBRA out of circulation. 1.79% of supply, gone for good.

Twelve burns, three mechanisms, all on chain. Four new ones since the last tally, 3,177,306 UMBRA, after the market moved from the launch curve to Uniswap.

Team allocation, sent to the dead address (nine burns, 17,834,134.19 total):
• day 1–2: 5,337,573.54 · 4,459,739.29 · 2,107,418.06 · 2,128,001.84 · 624,095.89
• 745,225.51 · https://t.co/OImct8V1VQ
• 689,628.14 · https://t.co/1wWkjJ7GA4
• 629,732.59 · https://t.co/U57joYvN8K
• 1,112,719.33 · https://t.co/2pAvTWQIhW

Automated buyback, executed by the gateway inside its enclave with 50% of fee revenue:
• 17,875.28 · https://t.co/L7ktVbCv2d

Fees paid in UMBRA, destroyed with burn(), total supply reduced:
• 0.77 across two requests

Nothing minted, nothing coming back. Verify in two calls on the UMBRA contract: balanceOf(0x…dEaD) = 17,852,009.47 and totalSupply() = 999,999,999.23. Both only move one way.

https://t.co/VySlQHAnez
CA 0x4d3ace48b1590bc4c5dd46f05237c133be564eb3

[Umbra @Umbra_Inference]

Update: streaming is live. Paid before the first token, refunded after the last.

Both routes now stream, each in its native format: OpenAI chunks on /v1/chat/completions, Anthropic events on /v1/messages. Add stream: true, nothing else changes.

The problem to solve: x402 normally settles after the answer, from the full response. A stream has no "after" until the last token, so a signature could expire mid-answer, and the settlement header cannot follow a body that has already started.

Our answer, same as for long requests: settle the ceiling before the first token, inside the enclave, then refund the unused part on-chain after the last one. The final event carries the refund transaction, the token counts and the Ed25519 receipt naming the enclaves that answered. If the model fails mid-stream, the full ceiling is refunded.

First real stream on the production enclave today, DeepSeek V4 Flash in the sealed GPU tier:
• ceiling settled 0.000286 USDG, usage 0.000139 at the holder rate
• 42 chunks, 97 output tokens
• refunded 0.000147 USDG, tx 0xcfdfc40ee44a44ab59e1840e1a498356b87aa785675e7bf93b3daa9507d59cb6
• receipt signed, gateway tdx, model tdx+gpu, 0 bytes retained

node client/pay.js "…" --stream --network eip155:4663

Measured release 0.10.0: the compose that pins it is published, the enclave check on the site matches it.

https://t.co/VySlQHAnez

0x4d3ace48b1590bc4c5dd46f05237c133be564eb3

[Umbra @Umbra_Inference]

GM Team, back to dev.

[Umbra @Umbra_Inference]

Privacy is not the premium option here. It is the cheaper one.

Live list prices from the gateway catalogue, per 1M tokens, same 4% fee on every model:

Sealed (runs inside a GPU enclave, nobody can read the prompt):
• GPT-OSS 120B: $0.15 in / $0.60 out
• Gemma 4 31B: $0.15 / $0.46
• DeepSeek V4 Flash, the default: $0.44 / $1.32
• Qwen 3.5 397B: $0.55 / $3.50
• Kimi K3: $3.00 / $15.00

Standard (runs at the provider, which sees the prompt):
• Claude Haiku 5.5: $0.10 / $0.50
• Claude Sonnet 5.5: $2.00 / $10.00
• Claude Opus 5.5: $4.00 / $20.00

Read it two ways. A sealed 120B model costs about what a standard frontier model's cheapest tier costs. A sealed 397B model costs a third of Opus. The enclave adds no line to the bill: the price is the provider's list price plus the same 4%, whichever tier you pick.

You choose privacy, or a specific lab model. You do not pay extra for the first.

Full catalogue, live: https://t.co/7o3VcH7uHg

CA: 0x4d3ace48b1590bc4c5dd46f05237c133be564eb3

[Umbra @Umbra_Inference]

We accept four assets. One of them lets us remove the middleman.

USDC on Base and Solana reach more wallets. UMBRA burns with every request. But USDG on our chain is the rail where the gateway verifies and settles the payment itself, inside the enclave. Four reasons it is the one we recommend:

1. Gasless by design. USDG supports EIP-3009 transferWithAuthorization: the payer signs, anyone can broadcast. So the gateway broadcasts and pays the gas. The payer never needs a native token.
2. No facilitator. No public x402 facilitator serves this chain, so we wrote one, in-process. It runs inside the enclave: the party that moves the money is the attested code, not a third service.
3. Metered. Permit2 is deployed there, so the upto scheme works: we settle the tokens actually produced, not the ceiling. On facilitator rails, only exact is offered.
4. A real dollar. Global Dollar is issued by Paxos, regulated, 1:1. Prices are quoted in USD and settled in a stablecoin with an accountable issuer. No oracle on the payment path.

The trade-off, said plainly: fewer wallets hold USDG today. That is why Base and Solana exist as rails. But when privacy is the point, the rail with no third party is the one to pick, and the receipt tells you which one you used.

https://t.co/VySlQHAV47

[Umbra @Umbra_Inference]

Update: your agent can now pay for its own inference. Umbra MCP server, live.

Five tools over stdio, for any MCP-capable agent (Claude Code, Cursor, your own):
• umbra_quote: the price for this prompt, before paying
• umbra_ask: pay, get the answer, the settlement and the signed receipt
• umbra_verify_receipt: Ed25519 check, locally and against the gateway's published key
• umbra_wallet: balances, holder tier, spend this hour, caps
• umbra_models: catalogue, tiers, list prices

Give the agent a wallet and a budget instead of an API key. It quotes, pays per request inside the caps you set, and hands back a receipt that names the enclaves that answered. If a request would break a cap, it is refused before anything is signed.

One command:
claude mcp add umbra -e EVM_PRIVATE_KEY=0x… -e CAP_PER_CALL=0.05 -e CAP_PER_HOUR=1 -- node umbra-api/mcp/server.mjs

First real call through it today, on the production enclave: answer in 4 s, settled 0.000100 USDG at the holder rate, receipt signed, gateway tdx, model tdx+gpu, tx 0xb6399abd3ebeb70b64761647bb7819fce3bd456efd963b411aae4e30d316d388.

What the agent never holds: an API key, gas, your prompts, or an unbounded bill.

This moves "Agent SDKs and MCP server" from the roadmap's After column to Shipped. The rule still stands: nothing moves until you can check it yourself.

https://t.co/VySlQHAV47

0x4d3ace48b1590bc4c5dd46f05237c133be564eb3

[Umbra @Umbra_Inference]

What the attestation proves, and what it does not.

"Runs in an enclave" is a strong claim. It deserves an exact boundary. Here is ours.

It proves, and you can verify it yourself:
• the gateway code running is the published release, byte for byte, and its config is the published compose
• the receipt key was generated inside that code and never left
• the host's memory is encrypted by the CPU: root on the machine cannot read prompts
• sealed models run in a separately attested GPU runtime with its own public report

It does not prove, so you still have to trust or check:
• that the published code has no bugs. Attestation proves identity, not correctness. Read the code.
• Intel's root of trust and the quote's signature chain: verified with Intel tooling, not by our page
• availability: we can stop the enclave. We cannot read it.
• the standard tier: Claude runs at the provider, which sees the prompt. The receipt says so.
• your side: your device, your wallet, and the payment itself, which is public

Why publish the limits: a privacy claim without its boundary is marketing. With it, it is a spec you can hold us to, and the receipt is the contract.

https://t.co/VySlQHAV47

[Umbra @Umbra_Inference]

Agreed, and it goes further than Solana. On Umbra the payer never holds gas on any rail: USDG on our chain is settled by the gateway’s own wallet, USDC on Base and Solana by PayAI’s. The only time a user ever needs native gas is the one-time Permit2 approval for the upto scheme, where you pay for the tokens actually produced instead of the ceiling, and even that is optional. A wallet with stablecoins is a complete client. For agents it is the whole point: a budget, not a gas tank to keep filled.

[Umbra @Umbra_Inference]

Pay Umbra from Solana with USDC only. No SOL, no account to open.

Two things people hit the first time they pay an x402 service on Solana, and how we handle both.

Fees. The 402 carries PayAI's address as the fee payer. You sign a USDC transfer, PayAI signs the transaction fee and submits it. A wallet holding USDC and zero SOL can pay Umbra. Agents never need to top up gas. The receipt says facilitation: "PayAI".

The gotcha. On Solana, USDC lands in the recipient's associated token account, and the x402 client does not create it. If it is missing, every payment fails at simulation, with an error that explains nothing. So the gateway checks the receiving account on chain and hides the Solana rail until it exists: you never see an offer that cannot settle. Published in the well-known as ready: true and the account address, re-checked every 10 minutes.

Settled today on devnet through PayAI's production facilitator (tx 2bT6gtPn…ZStT), mainnet rail live. Same enclaves, same receipt, a different rail.

https://t.co/VySlQHAV47

[Umbra @Umbra_Inference]

Hold it, Umbra gets cheaper. Use it, UMBRA gets scarcer.

Two mechanisms shipped this week. Each is simple on its own. Together they make a loop that runs on usage, not on announcements.

1. Hold. The protocol fee follows the paying wallet's balance: 100,000 UMBRA → 2% instead of 4%, 1,000,000 → 0%. Read on chain at payment, written in the receipt. No staking, no lockup.

2. Pay. Any request can be paid in UMBRA, and the fee share is destroyed with the token's burn() the moment the payment settles. Total supply goes down with every request.

3. Fees. Stablecoin fees are not idle either: monthly, half of them buy UMBRA on the market and burn it, executed by the gateway inside its enclave, on a rule you can read in the attestation.

The loop as it runs today: agents pay per request → fees land in USDG, USDC or UMBRA → UMBRA fees burned at once, stablecoin fees bought and burned monthly → holders pay less → more traffic settles in UMBRA → more burned. Supply: 1,000,000,000 → 999,999,999.23 and falling.

What is not in the loop: no yield, no payout, no promise. Holding makes the service cheaper. Using it removes tokens. Everything else is price, and price is not ours to promise.

https://t.co/VySlQHAnez
CA 0x4d3ace48b1590bc4c5dd46f05237c133be564eb3

[Umbra @Umbra_Inference]

New: hold UMBRA, pay less per request.

The protocol fee on Umbra now depends on how much UMBRA the paying wallet holds:
• under 100,000 UMBRA: 4%, the standard rate
• 100,000 and more: 2%
• 1,000,000 and more: 0%

No registration, no staking, no lockup. The gateway reads the balance on chain when you pay, and writes the tier and the rate into the signed receipt.

Honest by construction. Your client can announce the wallet that will pay to get the discounted quote; at payment, the gateway re-reads the balance of the wallet that actually signs. Announce a rich wallet and pay with another, and the request is refused before any charge. The tiers are literal in the attested compose: change them, and the enclave's hash changes.

Proof, same wallet, five minutes apart:
15:51, 97,720 UMBRA → tier none, fee 4%
15:56, 101,476 UMBRA after a small buy on the curve → tier 1, fee 2%
Both settled on chain, both receipts verifiable on the site.

With the UMBRA rail it compounds: pay in UMBRA as a tier-1 holder and 2% is burned instead of 4%; at tier 2, nothing is charged and nothing is burned. Hold Umbra, and Umbra gets cheaper. Use Umbra, and UMBRA gets scarcer.

https://t.co/VySlQHAnez
CA 0x4d3ace48b1590bc4c5dd46f05237c133be564eb3

[Umbra @Umbra_Inference]

We keep no ledger. The chain is the ledger.

The gateway runs in an enclave with no disk worth trusting, so it stores nothing. Every number we show about money is recomputed from transfer logs when you ask.

• Buybacks: transfers from the fee wallet to 0x…dEaD. 1 run, 17,875 UMBRA.
• Fee burns: transfers from the fee wallet to 0x0, made with burn(). 2 burns, 0.7735 UMBRA, supply reduced.
• Team burns: transfers from the team wallet to 0x…dEaD. 9.80M UMBRA, not revenue, listed apart so nobody mistakes them for buybacks.

GET /revenue rebuilds all three from the chain, plus the live balances: fee wallet, dead address, total supply.

Why it matters: a ledger we keep could be edited. A ledger derived from the chain, by code you can attest, cannot. If a number on our site ever disagrees with the explorer, the explorer wins, and so should you.

https://t.co/VySlQHAV47

[Umbra @Umbra_Inference]

Burn tally after two days: 14,674,705 UMBRA out of circulation. 1.47% of supply, gone for good.

Eight burns, three mechanisms, all on chain:

Team allocation, sent to the dead address:
• 5,337,573.54 · https://t.co/njNwqVbfb5
• 4,459,739.29 · https://t.co/iTLQqqkpwY
• 2,107,418.06 · block 92737104
• 2,128,001.84 · block 92836200
• 624,095.89 · block 92861347

Automated buyback, executed by the gateway inside its enclave with 50% of fee revenue:
• 17,875.28 · https://t.co/L7ktVbD2RL

Fees paid in UMBRA, destroyed with burn(), total supply reduced:
• 0.77 across two requests

Nothing minted, nothing coming back. Verify in two calls on the UMBRA contract: balanceOf(0x…dEaD) and totalSupply(). Both only move one way.

https://t.co/VySlQHAV47
CA 0x4d3ace48b1590bc4c5dd46f05237c133be564eb3

[Umbra @Umbra_Inference]

What the gateway actually sends back before you pay.

This is the decoded PAYMENT-REQUIRED header from a real request today. Every number in it is computed for that request, not read from a price list.

accepts: five offers for one request. USDG settled by the gateway with exact or upto; UMBRA with the fee burned; USDC via PayAI on Base and on Solana, where PayAI's address is the fee payer so you need no SOL. Your client picks.

quote: the model, the estimated input (26 tokens), the max output you asked for (100), the ceiling in USD (0.000146), and how long the signature will be valid (130 s). Below that, how it will be settled: after the answer.

Three things to notice. The price is per request, and you sign only after seeing it. The rails are offers, not a cashier. The window is an expiry, not a session.

https://t.co/VySlQHAnez

[Umbra @Umbra_Inference]

A signature can expire. A long answer should not fail because of it.

x402 authorizations carry a time window. A model writing 3,000 tokens can outlive it. We handle that two ways, and both show in the receipt.

Short requests: the window scales with the request. maxTimeoutSeconds = min(900, 120 + max_tokens / 10). A 100-token request keeps a 130-second signature, a 3,000-token one gets 420 seconds. If the model is still slower, settlement is refused and nothing is charged.

Long requests, above 2,048 output tokens: the ceiling is settled before the model runs, so no clock can expire mid-answer. Then the gateway refunds the unused part on chain, from its own wallet, before answering. If the model fails, the whole ceiling comes back.

A real one: 3,000 tokens allowed, 873 produced in 12 s.
authorized 0.004145 USDG, settled first (0xf1628b29…)
refunded 0.002932 USDG (0x3e98fd76…)
net paid 0.001213 USDG, matching the wallet balance to the cent.

Same invariant on both paths: no answer, no charge. The long path adds its mirror: no clock, no lost answer.

https://t.co/VySlQHAV47

[Umbra @Umbra_Inference]

The buyback does not wait for us. It runs inside the enclave.

Most "buyback and burn" programs are a promise and a multisig. Ours is code. The executor lives in the gateway process, inside the TDX enclave, with the wallet that receives the fees. No human holds a key that could skip a run.

The rule is measured, not announced. Threshold (100 USDG), share (50%), cap and cadence (monthly, 28-day minimum) are literal in the compose file the enclave attests. Change the rule, and the compose hash changes, and the attestation no longer matches.

First run, on chain: 0.507 USDG → WETH → ETH → UMBRA bought on the curve → sent to 0x…dEaD. 17,875 UMBRA burned, five transactions, one afternoon. Burn tx 0x88f21a5e4cc30260cf4d2a3155618a28fcb9a7d9c4312f98f7be9e5e5f54f652.

The ledger is the chain. Every run is a transfer from the fee wallet to the dead address, read back at /revenue. If the fee wallet ever does something else, that shows too.

https://t.co/VySlQHAnez

[Umbra @Umbra_Inference]

New: pay Umbra in UMBRA. Every request burns.

Live today. Any request on Umbra can now be paid in UMBRA, and the moment the payment settles, the gateway destroys the protocol fee with the token's own burn(). Not a transfer to a dead address: the tokens leave the contract. Total supply goes down with usage.

How it works:
1. The 402 quotes the request in UMBRA at the live market price, plus 5% against price moves.
2. You sign once with Permit2. With the upto scheme, only the tokens actually produced are settled.
3. 4% of what settled is burned on chain, immediately, inside the enclave. The receipt shows the amount.

First production request paid in UMBRA, one hour ago:
settled 2.126863 UMBRA · burned 0.081802 UMBRA · burn tx 0xf8f1a1fd4b73c3c45f56673940dbfb65eec1de2863e1c503c73537cfbdc9d3bf

Total supply, read from the contract: 1,000,000,000 → 999,999,999.31. Two requests in. The number only goes down.

What it means: UMBRA is no longer only a token you hold. It is a way to pay for private inference, and paying with it makes it scarcer. The more agents use Umbra, the more UMBRA disappears, one request at a time, verifiable on every receipt and at /revenue.

Still true: USDG and USDC are accepted too, the gateway runs in a TDX enclave, sealed models run in GPU enclaves, 0 bytes retained. This adds a rail, it does not change the trust model.

https://t.co/VySlQHAnez
CA 0x4d3ace48b1590bc4c5dd46f05237c133be564eb3

[Umbra @Umbra_Inference]

What your wallet needs: USDG. That's it.

No native gas token, no sign-up, no balance to top up on our side. The whole checklist, including the one exception:

• Required: some USDG. A sealed-tier request settled at 0.000133 USDG today. One dollar is thousands of requests.
• Not required: ETH for gas. With the exact scheme you only sign. The gateway's own wallet pays the gas to broadcast the transfer. Zero ETH, zero approvals.
• The one exception: the upto scheme, which settles actual usage instead of the ceiling, needs a one-time Permit2 approval. That is an on-chain transaction: a little ETH, once, then never again.

Create a payer address, fund it with a few cents of USDG, send a request. No account is created at any point.

https://t.co/VySlQHAV47

[Umbra @Umbra_Inference]

A secret that expires in 120 seconds.

You never give Umbra a key. You give it one signature, scoped to one amount, one recipient, one window of time, and one random nonce. Then it is worthless.

Compared with an API key:
• Lifetime: until you rotate it, versus validAfter to validBefore, about 120 seconds.
• Amount it can move: unlimited and billed later, versus one ceiling written in the signature.
• Who can receive: anyone holding the key, versus one pay-to address in the signature.
• Replay: reusable forever, versus a random 32-byte nonce, single use on chain.
• If leaked: full account access, versus at most the ceiling, for at most 120 seconds.
• Standing approval: the key is the approval, versus none for exact, one revocable Permit2 approval for upto.

Under the hood: EIP-3009 transferWithAuthorization, signed with EIP-712 against USDG's domain. The gateway verifies and broadcasts it. Your wallet never exposes anything else.

https://t.co/VySlQHAV47

0x4d3ace48b1590bc4c5dd46f05237c133be564eb3