Hosted Antseed buyers, in confidential VMs, with the keys where they should be.

Anthosting runs an Antseed buyer for you inside a confidential virtual machine. The buyer key is derived inside that machine from the hardware and never leaves it. The right to withdraw your funds is your own wallet's, set once on-chain. We cannot move your money — and we say exactly what that does and does not mean in the scope statement below.

What you actually get

A machine you do not administer

One-command provisioning, TLS attested inside the VM, and no DNS credential ever entering it.

A key you never gave us

Derived per boot from the TEE, injected into the buyer in memory, never written to disk.

An exit that needs only you and the chain

The withdrawal path is served by an independent verifier, so it keeps working when our control plane is the thing that is broken.

Check it rather than believe it

The verifier is a separate service on a separate host that holds no credential — it refuses to start if it can see one. Anything this page claims about the running code, you can check:

# is the approved measurement signed offline?
curl -s https://verify.anthosting.dev/api/measurements

# does this tenant's quote commit to it? (DCAP-verified, replayed event log)
node packages/verifier/scripts/check-measurement.mjs \
  https://YOUR-TENANT.anthosting.dev/attest \
  --compose-hash e4261ec03382eccfc37df75a89dd00affd144e4e8f4b76e7eb500de91cf503d9

Tenant image: sha256:dc1a06d3484555fae9c…
OS image: dstack-0.5.8
Approved: 2026-10-10
Signature: 01ce8ff05011cea1 · 2026-10-10T15:10:42.294Z

Read at request time from manifests/measurements.json, so this list cannot drift from what the verifier enforces.

What this is not

Not a clean sheet. We hold two bearer tokens per tenant in plaintext. Neither can withdraw anything — the operator role is your wallet — but one of them can spend your balance up to the on-chain credit limit. That is the exact boundary of the claim above, and it is stated here for the same reason it is stated in the scope statement rather than in a footnote.
Not a guarantee of confidentiality. The guest has no shell, runs unprivileged on a read-only filesystem, and every write goes to a memory filesystem that dies with the container. It also has no egress allowlist — see the scope statement.
Not an availability promise. No SLA. The verifier is separate from the control plane on purpose, so a control-plane outage does not take your money with it.
Not a relationship with the model sellers. Your prompts go to whichever seller serves the request, chosen by the Antseed network. Their practices are theirs.
Not a finished service. See the status note in the banner.

Documents

TEE scope statement

What the confidential VM protects, what it does not, and how to check any of it yourself. Read this before trusting the word “confidential”.

Security model

The threat model, the custody model, the invariants and what is proven — with pointers to the evidence for each.

Privacy notice

What is collected, where it lives, who else sees it, and how long it is kept. Prompts are not in this list.

Under review — not published yet.

Terms of service

The custody promise and its exact limits, fees, suspension, liability, and the parts that are not ours to promise.

Under review — not published yet.

Acceptable use policy

What the machine may not be used for, and what happens when it is.

Under review — not published yet.

Status

Anthosting is in staging. The control plane, the public verifier and the tenant runtime are deployed and exercised by the project's own acceptance runs; the pilot is not open, and the terms of service are not in force.