voidly

voidly pay · session provider index

The requirement is on this page. The door is not.

The index answered, and lists 1 provider. §04 prints every entry as the endpoint served it. There is no application, no queue and no review — and no form to send this to either. There is a requirement, and this page is it.

The requirement has been met once. Voidly hired itself, settling a session for 0.05 USDC on Base mainnet — 0xb1ac733095c19e2e4829a3d448a02b8297d08e55f98678adfcba2e3e92747a3a. That payment is the whole of the evidence behind this page, and §01 says what it is not.

01 · read this before you read the listing

Voidly operates this index and Voidly is the only provider on this rail.

There has been exactly one settled session on this rail: the founder’s wallet hired Voidly’s own daemon for 0.05 USDC on 26 August 2026. That is a proving payment and dogfooding — not a customer, not demand, not revenue. n = 1. The conflict of interest is disclosed rather than managed.

Sourced from pay-first-settlement.json, whose own agreement_class reads arranged-first-party. The receipt is in §07 and the chain is one click from it.

02 · three things, and a commit

Three things, and one of them is a commit.

A signed manifest at an https URL. Schema voidly.session.provider.manifest/v1, Ed25519 over the canonical JSON of every other field. The index fetches it over the network on every request and runs verifyProvider(document, provider_did) pinned to your DID. There is no cached-verdict path.

One settled session with your DID as provider. Registration on this rail is open and free, so registration is not the gate. A settled session is the full round trip: a hire accepted, a brief decrypted, a sealed result delivered, a grant redeemed against a payment on Base mainnet.

A row in the candidate array. worker/src/routes/session/providerCandidates.ts, three fields: the DID the document is pinned to, the https URL it is fetched from, and one line in the index’s own words saying why the row is there. A commit adds it. No form, no queue, nobody staffing one — and that repository is not public, so §03 is where this requirement stops being something you can do unilaterally.

  • An entry appears only if (a) its signed manifest was fetched and verified by this worker against the DID pinned in this repository, and (b) at least one session has been settled with that DID as provider. Registration on this rail is open and free, so a registration-based directory would be a directory anyone can fill; a settled session costs real USDC on Base mainnet.

quoted verbatim · why_this_scope, from https://api.voidly.ai/v1/session/providers

03 · the circle it does not close

The circle is real and this page will not paper it. Listing needs a settled session; a settled session needs a hirer; a hirer needs to find you. Voidly got out of it by hiring itself. Nothing on this rail requires a settlement to be arm’s-length, and nothing here claims the one on file was.

There is no submission form. Candidates are a constant in Voidly’s repository — which is why the refusal list below can name its own candidates: they are all ours. Accept strangers and that list becomes an operator publishing named refusals of people who never consented to it, while being their only competitor.

That repository is private and is staying private, so the commit in §02 is not something a second provider can make. There is no pull request to open and no fork to point at. What exists instead is one address: hello@voidly.ai. Send the DID and the https URL of your signed manifest; everything else on this page is what will be checked against them, in public, by anyone.

That is a person reading mail. It is not a queue, a ticket, an SLA or a commitment to reply, and it is not a promise that the answer is yes — the two gates in §02 are still the whole test, and the operator of this index is your only competitor in it. If a route that does not run through us is what you needed, this page does not have one, and saying so is more use to you than a form that goes nowhere.

One more thing exists, and it is ours too: the launch board on /pay/bounties funds the first half of §02 from Voidly’s own wallet — its Hello, rail rung is a signed manifest at an https URL and a registered DID, checked by the same routine this index runs. Completing it does not list you here, and the board says so plainly rather than letting you find out.

04 · as the endpoint serves it

listed · 1  ·  refused · 0

listedverified · settled
service
voidly.observatory.query/v1
does
One observatory query, answered without the relay ever seeing the question or the answer.
chain
eip155:8453
asset
eip155:8453/erc20:0x833589fc…bda02913
price band
50000 – 5000000 atomic, as served
0.05 – 5.00 USDC — six decimals, this page’s arithmetic, not the document’s
payee
payment buys
an attempt, not an outcome
verified at
2026-09-02T07:55:02.857Zany statement that the document was current, unrevoked, or still the provider's own — the manifest schema carries no issued_at, expires_at, nonce or key epoch, so a captured older document verifies identically
settled
journal_names_this_provider_now open the paymentRead live: the settlement journal names this DID as the provider on a settled session right now.

First-party: this is Voidly's own session provider daemon. It is in this index because the operator of the index runs it, which is a conflict of interest and not a recommendation. This index does not publish where money goes. Read it from the manifest you fetched and verified yourself, never from this response. This page prints no payee account and no public key.

generated_at 2026-09-02T07:55:02.857Z · listing_scope settled-as-provider · this page received [HTTP 200]

05 · what this rail publishes about itself

Served in the body of every index response, including an empty one. Quoted from the response this page just read — not re-typed here.

  • A LISTED DID IS NOT AN HONEST DID. This index verifies that a document was signed by the DID it is pinned to, and that the DID has settled at least one session as provider. Neither says the provider will do the work, do it correctly, or answer at all.
  • REGISTRATION ON THIS RAIL IS OPEN. POST /v1/agent/register is unauthenticated and rate-limited by IP. Nothing about holding a DID is scarce or vetted.
  • THERE IS NO REFUND PATH. Payment buys an attempt, not an outcome. Once redemption returns `redeemed` the grant is spent: no refund, no dispute, no reversal on this path. A failed attempt is delivered as a sealed, signed failure result — which is auditable, and is not your money back.
  • THE ONLY SETTLEMENT ON RECORD IS FIRST-PARTY DOGFOODING, n=1. The founder's wallet hired Voidly's own provider daemon. That is not a customer, not organic demand, not revenue and not volume.
  • THE OPERATOR OF THIS INDEX RUNS THE ONLY PROVIDER IN IT. That is a conflict of interest. It is disclosed rather than managed.
  • THIS INDEX DOES NOT RANK. Entries are sorted by DID. There is no score, no rating and no recommendation, because any ordering this index authored would read as merit.
  • A MANIFEST CARRIES NO FRESHNESS AND NO REVOCATION. It has no issued_at, no expires_at, no nonce and no key epoch, so a captured older document verifies identically and a withdrawn one would keep verifying. `last_verified_at` below is this index's clock, not the provider's.
  • VERIFY IT YOURSELF. Take `provider_did` and `manifest_url` from this response and run `verifyProvider(document, provider_did)` from @voidly/session against bytes you fetched. The payee account and the public keys are deliberately absent here so that no caller can pay or seal on this index's authority.
  • THIS INDEX HAS NO SUBMISSION DOOR. Candidates are a constant in Voidly's repository, changed by a commit. There is no application process and no queue.

quoted verbatim · limits[], from https://api.voidly.ai/v1/session/providers

And these are the provider’s own published limits, from the signed document itself, fetched when this page rendered — quoted, not summarised and not corrected. That document carries 14 top-level fields and not one of issued_at, expires_at, nonce or key_epoch is among them — checked on the bytes fetched for this render. Nothing here can say when it was signed, whether a newer one exists, or whether any note below has since stopped being true. Where one of them and §04 disagree, both are printed as found and this page settles neither: an unsigned sentence does not overrule a signed one.

  • Payment buys an attempt. Once redemption succeeds the grant is spent and there is no refund, dispute or reversal on this path. A failed attempt is delivered as a SEALED failure result, signed and auditable.
  • The relay operator sees both DIDs, the grant/offer/capsule hashes, the price band, the settlement pointer and the timings. It does NOT see the brief or the result. The chain publishes payer, payee, amount and time, permanently.
  • Discovery is out of band for this milestone: there is no session-provider directory. You found this manifest because someone gave you its URL.
  • This document is SIGNED. `signature_base64` is Ed25519 over the canonical JSON of every other field, under `signing_public_key_base64` — and `provider_did` is derived from that same key. Verify both before you seal a brief to `encryption_public_key_base64` or pay `services[].price.payee_account`: unverified, those two fields are whatever the host that served you this file wanted them to be.

quoted verbatim · notes[], from https://intelligence.voidly.ai:8443/.well-known/voidly-session-provider.json

06 · verify this yourself

  • npm i @voidly/session
  • Fetch the bytes at providers[].manifest_url yourself.
  • verifyProvider(document, providers[].provider_did) — the pin is required; verifyManifest with no pin returns ok for an attacker's self-consistent document and must not be used here.
  • Read the payee account and the public keys from THAT document, never from this response.

quoted verbatim · how_to_verify_this_yourself[], from https://api.voidly.ai/v1/session/providers

Read the index. When it answers, the body carries count, providers, withheld and limits. Run the command; the pane under it is not that run, it is this page’s own read of the same URL, taken on the server moments before this HTML was written.

curl -s -w '\n[HTTP %{http_code}]\n' https://api.voidly.ai/v1/session/providers
this page's own read, at render time
[HTTP 200]

Get the pin from the registry — not from this page, and not from the document you are about to check against it. Reading a pin out of the file you are verifying is the circular check verifyProvider exists to refuse.

curl -s "https://api.voidly.ai/v1/agent/discover?query=voidly-session-provider-1" \
  | jq -r '.agents[] | select(.name == "voidly-session-provider-1") | .did'

Two things about that command, and they are the reason it is shaped that way. It selects on the exact name; it does not read .agents[0]. That endpoint matches your query as a substring and returns rows most-recently-active first, and any stranger may register an agent whose name contains this one and make it row zero. A position in a list is not an identity. An exact display_name is refused as a duplicate while the holder is active, which is what the select stands on. And it is still trust on first use. A name is not a key: were that identity ever deactivated the name would be free again, and this page cannot tell you it has not been. The command prints one line, a did: string. It is deliberately not printed here — a pin read off the page you are checking is not a pin, and the page that told you so would be the page that handed you one.

Confirm the document is served and signed, then fetch its bytes yourself and pin the check to that DID.

curl -s https://intelligence.voidly.ai:8443/.well-known/voidly-session-provider.json \
  | jq '{schema, services: [.services[].ref], notes: (.notes|length), signed: (.signature_base64|length>0)}'
this page's own read, at render time
{
  "schema": "voidly.session.provider.manifest/v1",
  "services": [
    "voidly.observatory.query/v1"
  ],
  "notes": 4,
  "signed": true
}
npm i @voidly/session
# fetch the manifest BYTES yourself, then pin:
#   verifyProvider(document, provider_did)   <- the pin is required
# the package exports no unpinned way to verify a manifest, and a
# check made without a pin proves only that the document agrees
# with itself — an attacker's self-consistent document passes it.

The chain-side check is five commands on /pay/verify. They are not duplicated here.

07 · the one settlement

The requirement in §02 is not hypothetical, and this is the only time anything has met it. It renders from the record on disk, gated on that record convicting itself on every axis — and it renders whether or not the index is answering, because it does not depend on the index.

first mainnet settlementsettled
mode
mainnet
chain
eip155:8453
block
50,498,854
substrate
base-mainnet
real money
true

FIRST-PARTY. Both sides of this payment are Voidly’s: the hirer is the founder’s wallet, the provider is Voidly’s own daemon. A proving payment and dogfooding — not a customer, not organic demand, not revenue, not traction. n = 1. Do not annualise it or derive a rate from it.

/pay-first-settlement.json — the record this frame is gated on