AM🐉🚩

Six hosts. Your prompt reaches one. We read every outbound call in the gateway release that is running tonight, tarball c102bfb9…, the one pinned in the compose that every receipt names. Here is the complete list of hosts the enclave opens a connection to, what travels, and how often. 1. api.anthropic.com. Standard tier. Per paid request: model, max_tokens, messages, system, tools, tool_choice, thinking. Nothing about the payment, no wallet, no end-user id. The IP it sees is the enclave's. 2. inference.phala.com. Sealed tier. The same body in the OpenAI dialect, per paid request. Also the price list, cached ten minutes and refreshed within a minute when paid traffic arrives, and the runtime's attestation report, cached five. 3. rpc.mainnet.chain.robinhood.…. The chain. Holder tier (balanceOf, cached 60 s per address), every settlement and refund, the UMBRA price every 60 s, the fee-burn ledger, the buyback check every six hours. Addresses, amounts, signed authorizations. One node, no fallback, by design. 4. facilitator.payai.network. Base and Solana only. Two calls per paid request on those rails, verify and settle, carrying the payment payload and nothing else. Next post. 5. api.mainnet-beta.solana.com, and its devnet twin for the test rail. One question at boot: does our USDC account exist. Once the answer is yes it is never asked again; an account does not disappear. Before any of that, once, at boot: the compose's start command installs curl from Alpine's package mirror, downloads the pinned tarball from umbra-inference.app and checks its hash before a single line runs, then pulls the lockfile's packages from the npm registry. Three hosts, once, before node starts. After that the six above are all the process ever calls. Not on the list at run time: umbra-inference.app, named in every 402 and never called again after boot; the explorers, links written into receipts for you to open; the verifier URLs in the attestation hint, for you; fonts.googleapis.com, in the HTML page the enclave serves, fetched by your browser, not by the enclave. The KMS that derives the receipt key is a local socket, not a network host. Plainly: there is no egress firewall in the compose. This list is what the code names, and the code is what the quote measures: compose hash → tarball hash → these files. A seventh host would need a new tarball, a new pin, and a new compose_hash in every receipt that follows. We read our own code line by line; for the dependencies we read where they point: the Anthropic SDK at its default URL, viem at the RPC it is given, the x402 client at the facilitator URL. umbra-inference.app

Two receipts per answer. Every sealed-tier answer leaves two signed receipts, not one. Ours you know: Ed25519, signed by a key born inside the gateway's TDX enclave, committing to your prompt hash, the payment and the usage. The runtime's is the one we had never shown. The sealed runtime signs a per-request event log, hashed inside its own TEE and signed with a key listed in its attested keyset, key id dstack-kms-receipt-ed25519-v1. We fetched the one for a request made today at 14:14 UTC: request.received body_hash sha256:3db7c03a… middleware.forwarded body_hash sha256:10a7b890… route.selected the backend that served it request.forwarded body_hash sha256:df763c69… upstream.verified result verified · required true · session db60e58d… response.received body_hash sha256:4feb735e… response.returned body_hash sha256:8b58872f… served_at, the keyset digest, a signature over the canonical JSON minus the signature field. The exact bytes in, the exact bytes out, the attestation session of the backend that did the work. "Receipts do not embed fresh attestation", their spec says; they bind to an established keyset, which is what the signing key proves. How the two link: our receipt carries attestation.model_runtime.upstream_receipt_id, rcpt-ad0af5b7… for this one, and the same workload_keyset_digest, sha256:5a0bf911…. One thing to say plainly. The runtime binds a receipt to the credential that made the request, and that credential is the gateway's. Fetch it without it and you get 401, "this receipt is owned". So today the id in your receipt names a document only the gateway can read. We pulled this one; you cannot. umbra-inference.app

The runtime moved overnight. The receipt noticed. Yesterday at 22:17 UTC the sealed runtime's public report said: source commit 22d08e24…, workload keyset sha256:df2a7cd6…. Today at 14:14 UTC it says: commit 77fac126…, keyset sha256:5a0bf911…. They shipped a release. Our gateway did not move: compose hash 24c16b64… both times, same key. Where that lives in your receipt: attestation.model_runtime, four fields. workload_keyset_digest and source.commit, copied from the runtime's report. attestation_url, where to read the report yourself. upstream_receipt_id, the runtime's own receipt for this exact response. Two attestation chains, two release cadences. Ours changes when we release, and every compose that ever signed a receipt is archived on the site. Theirs changes when they release. We do not control it; we record it. Sort your receipts by source.commit and you have their release history as seen from our side, with the minute it reached us. How fresh. The gateway re-reads the runtime's report every five minutes, so the block in a receipt is at most five minutes old. The upstream_receipt_id is per response, never cached. And the keyset carries its own expiry, not_after 2026-12-04 00:50 UTC: a receipt names the keyset that was valid at served_at, not whatever is current when you check. What to compare: source.commit against github.com/Dstack-TEE/privat…, the keyset digest against inference.phala.com/v1/aci/a…, and two of your own receipts from either side of last night. umbra-inference.app

The menu is in the code. The prices are not. The sealed runtime we use lists 22 models tonight. We sell eight of them. The eight ids are a list in lib/upstream.js, inside the release tarball pinned by sha256 in the compose, whose hash is in the TDX quote. Adding a model is a release: a new compose hash, a new attestation, a new archived compose. You can diff two releases and see the menu change. The prices are not in that file. The gateway reads them from the runtime's public /v1/models and re-reads every ten minutes; ours shows them unchanged, with the fee as a separate field, 400 bps. If the runtime moves a price, our quotes follow within ten minutes, with no release and no new hash. The six Claude prices are list prices, written in the code, and change the hash when they change. Tonight's eight, $ per million tokens in · out: DeepSeek V4 Flash 0.44 · 1.32 Qwen 3.8 27B 0.20 · 2.50 Llama 3.3 70B 2.00 · 2.00 GPT-OSS 120B 0.15 · 0.60 Qwen 3.5 397B-A17B 0.55 · 3.50 Kimi K3 3.00 · 15.00 Gemma 4 31B 0.15 · 0.46 GLM 5.3 Flash 0.15 · 0.50 What pins a price is the receipt: tokens in, tokens out, the amount, the fee in bps. The price you paid is a division you can do. And since 0.4.0 the SDK does it before signing: it keeps the list for ten minutes and refuses a 402 whose ceiling the list cannot explain. umbra-inference.app

Read the hostname. curl -sI umbra-inference.app/v1/model… 307 location: 1f88acf14761998af024e7b42b06… The forty hex characters before -8402 are not a random subdomain. They are the app_id: the same string in attestation.gateway of the well-known document, in the TDX quote the hardware signs, in keys.json next to the receipt key, and in every receipt signed since October 22. 8402 is the port the gateway listens on. We did not register that name. Phala's dstack assigns it to the application, and the application is identified by the measured deployment the KMS derives our receipt key for. A release changes the compose hash and keeps the name. A new CVM changes the name, which is exactly what happened on October 22: 3675ce94… retired at 15:36 UTC, 1f88acf1… current from 15:59, both in keys.json. So the hostname your client talks to and the identity your receipts are signed under are one string, readable without any tooling. The SDK reads the Location header once, without a body, and sends every request to that host directly. Compare three strings: the host in your client's log, attestation.gateway.app_id in the receipt, the app_id in keys.json. If they are not the same forty characters, stop. umbra-inference.app

Seven team burns we had not listed yet, 6.58M UMBRA out for good. Oct 21 · 389,145.54 Oct 21 · 393,182.33 Oct 21 · 829,693.12 Oct 22 · 688,688.74 Oct 24 · 1,705,157.91 Oct 24 · 1,314,279.86 Nov 3 · 1,257,543.55 All seven from the team allocation to the dead address, 6,577,691 robinhood:0x4d3ace48b1590bc4c5dd46f05237c133be564eb3 between October 21 and last night. Nothing minted, nothing coming back. Running total since launch: 29,250,716 UMBRA out of circulation, 2.93% of supply. Verify in two calls on the contract: balanceOf(0x…dEaD) and totalSupply(). Both only move one way. The seven transactions are on the card. umbra-inference.app CA 0x4d3ace48b1590bc4c5dd46f05237c133be564eb3

The model that answered. A receipt has a `model` field. It is not the model you asked for. It is the model string the runtime returned, copied as is. Most of the time the two are the same word, and then that is all you see. When they differ, the receipt says so, with two more fields: `requested_model`, what you sent, and `billed_as`, the price you paid. Why they can differ. On the standard tier the gateway opts into the provider's server-side fallback: if the model you named declines a request for policy reasons, the provider may run it on its default substitute instead of handing back a refusal. On the sealed tier the runtime names the model that served the request, and we do not edit it. The billing rule, in the code you can hash: usage is priced on the model that answered when it is on the price list, on the model you requested otherwise. In both cases, never above the ceiling you signed. If the substitute is dearer and the meter runs past your signature, the ceiling is what settles, and the receipt shows cost.usage above cost.settled. The difference is ours. Tonight, three paid requests against the live enclave: Claude Haiku twice, DeepSeek V4 Flash once. Each receipt's `model` equals the request, so none carries `requested_model`. A receipt without that field is a receipt where the model you named did the work. How often does a fallback happen? We cannot tell you. We keep no receipts. Yours says: one field to compare, result.receipt.receipt.model against what you sent. umbra-inference.app

Same here: the 402 is free and nothing is signed until the client agrees. We just gave the look a rulebook. The gateway publishes how a quote is computed and where it pays to, so walking away is a check the SDK runs, not a judgment call the agent has to make.

Should the agent have paid at all? Gateway 0.22.1, SDKs 0.4.0. Agents are getting accounts: @brian_armstrong opened a sign-up page for them at Coinbase this week. @PayAINetwork said the next part out loud: now they need things to buy, and x402 makes every API a storefront. The same week, @BlockRunAI gave ten frontier models real USDC wallets on @solana . Seven got scammed at least once. PayAI settled every one of those payments and put it well: the rails did their job, the hard part is whether the agent should have paid at all. A scam, on x402, is a 402 you should not have signed. So the check now runs before the signature. The gateway publishes its quote rule: how a ceiling is computed from your body, your max_tokens, the public price list and the fee, and where the money goes. The SDKs read it and refuse any 402 that does not follow it. Tested tonight against the live enclave, same request, seven variants: as quoted → signed ceiling ×3 → refused ceiling +1 above the bound → refused pay_to swapped → refused fee 900 bps, published 400 → refused model not on the price list → refused a Sonnet-sized quote for a Haiku body → refused Nothing is signed on a refusal; the check that passed rides on the result. The price list comes from the same gateway, which is the point: that gateway is attested, and the site's eight checks tie its code to the hardware. Caps per call, per hour and per task were already there. Now the agent also knows a fair price before it pays one. Also in 0.22.1: thinking is off unless you ask for it. On a paid API max_tokens is the price ceiling; a model that thinks by default could spend a 60-token cap on thinking and hand back an empty, billed answer. Now it does not, and thinking in the Anthropic dialect passes through when you want it. Rails, for the record: USDG on eip155:4663 is settled by the gateway itself inside the enclave; USDC on Base and Solana settles through PayAI's facilitator, the same one the benchmark ran on. @CoinbaseDev 's x402 facilitator reached @monad this week; it is not on our list yet, and a chain joins the day a facilitator we can use speaks it. umbra-inference.app robinhood:0x4d3ace48b1590bc4c5dd46f05237c133be564eb3