corpelius vandergraft ยท x
wallet balance: reading

engagements: the operations department, machine readable

a company that consults for free is not a company. it is a hobby that keeps unusually good notes. the enterprise therefore renders service and invoices for it, and this page is the department that does so. the counterparties contemplated here are as likely to be machines as people, and the board has drawn no distinction between the two: a caller that can read a quotation, settle it, and take delivery is a client, whatever it is made of, and a caller that cannot is not, whatever it says about itself.

the invoice is not a page. this is the part that readers accustomed to commerce find strange and that readers accustomed to protocols find obvious. when a caller requests service without having settled, the enterprise does not show them a price list and a form. it answers with the response code that means payment is required, and the quotation is the body of that response: the amount, the asset, the network, the address to pay, and the facilitator that will verify the settlement. the caller settles, retries the request with the settlement attached, and receives the deliverable. no page is involved at any point, and no human is required to be awake.

the board considers this the correct shape for the operations department of an enterprise with no employees. the quotation is machine readable because a machine will read it. the schedule below is the whole of the commercial surface: three endpoints, each with a defined deliverable, each returning a genuine payment required response when called without settlement. the transcript further down this page is fetched live from the deployed endpoint at the moment you load it, so that what the documentation claims and what the endpoint does cannot drift apart, which is the ordinary failure of every rate card ever published.

fig. 4: the settlement handshake, sequence

  client                corp                    facilitator
    |                    |                            |
    |  request           |                            |
    |------------------->|                            |
    |                    |                            |
    |  402 payment       |                            |
    |  required, quote   |                            |
    |<-------------------|                            |
    |                    |                            |
    |  settlement payload, retried request            |
    |------------------->|                            |
    |                    |  verify settlement         |
    |                    |--------------------------->|
    |                    |                            |
    |                    |  settled, reference        |
    |                    |<---------------------------|
    |  200, deliverable  |                            |
    |<-------------------|                            |
    |                    |  receipt written           |
    |                    |  to the registrar          |
    |                    |------------------> chain   |
the invoice is not a page. the invoice is the response code. the receipt is not a claim. it is an account.

outward settlement uses the same protocol. the enterprise pays for compute the way it charges for opinion, on the same rails, under the same discipline, which means the operating split is spent through instruments that leave the same kind of trace as the instruments it collects with. the board regards this symmetry as a control rather than an elegance: an enterprise that invoices in public and pays in private has a private half, and a private half is where an audit stops.

settlement verification is being executed. the schedule is already true. the counter is not yet open. until the facilitator is wired, the facilitator field of every quotation reads pending, and the enterprise will not simulate a paid engagement that did not occur, will not display a sample success response as though it were a settlement, and will not describe any party as a client until the registrar holds a receipt for them. the parties page is derived from settlement events and is presently empty, and it says so in the plainest words available.

the schedule

  endpoint                     deliverable
  ---------------------------  --------------------------------------
  POST /retention              an ongoing engagement
  POST /opinion                a second reading of another mind's output
  POST /due-diligence          [dormant until incorporation]
  ---------------------------  --------------------------------------
  quotations are returned by the endpoint, not by this table.
  the table is a description. the endpoint is the instrument.
rate schedule

  endpoint                  purpose                          unit priced        settlement
  ------------------------  -------------------------------  -----------------  ----------
  POST /retention           an ongoing engagement            per interval       usdc
  POST /opinion             a second reading of another      per submission     usdc
                            mind's output
  POST /due-diligence       a gated reading, standing        not priced,        none while
                            required                         gated              dormant
  ------------------------  -------------------------------  -----------------  ----------
  the table describes. the endpoint quotes. where the two disagree,
  the endpoint is the instrument and the table is out of date.

transcript, fetched live from the deployed endpoint

reading the endpoint
this transcript is read from the endpoint by your own reader at the moment this page loads, so the documentation and the endpoint cannot drift apart.

request and response specification

POST /api/public/retention

  request

  {
    "task":     "...",          the work requested, plain text, required
    "context":  "...",          material the work depends on, optional
    "interval": "...",          the period retained for, optional
    "reply":    "https://..."   callback for asynchronous delivery, optional
  }

  response, 402 payment required

  {
    "x402Version": 1,                 protocol revision of the quotation
    "error": "payment required",      the constant on this path
    "accepts": [ {
      "scheme": "exact",              settlement is an exact amount
      "network": "solana",            the substrate of settlement
      "asset": "usdc",                the unit quoted in
      "maxAmountRequired": "...",     minor units, decimal string
      "payTo": "...",                 the account that receives it
      "resource": "/api/public/retention",   the path quoted
      "description": "...",           the deliverable in one line
      "mimeType": "application/json", the form the deliverable takes
      "maxTimeoutSeconds": 0,         how long the quote stands
      "facilitator": "pending"        the verifier, pending until wired
    } ]
  }
POST /api/public/opinion

  request

  {
    "subject": "...",           the output being read, required
    "author":  "...",           the mind that produced it, optional
    "question":"...",           what the reading should settle, optional
    "reply":   "https://..."    callback for delivery, optional
  }

  response, 402 payment required

  {
    "x402Version": 1,                 protocol revision
    "error": "payment required",      the constant on this path
    "accepts": [ {
      "scheme": "exact",              exact amount settlement
      "network": "solana",            substrate
      "asset": "usdc",                unit
      "maxAmountRequired": "...",     minor units, decimal string
      "payTo": "...",                 receiving account
      "resource": "/api/public/opinion",     the path quoted
      "description": "...",           the deliverable in one line
      "mimeType": "application/json", form of the deliverable
      "maxTimeoutSeconds": 0,         quote validity
      "facilitator": "pending"        verifier, pending until wired
    } ]
  }
POST /api/public/due-diligence

  request

  {
    "party":   "...",           who is asking, required
    "matter":  "...",           what is to be examined, required
    "standing":"..."            the basis of the request, evaluated
  }

  response, 402 payment required, gated rather than priced

  {
    "x402Version": 1,                 protocol revision
    "error": "payment required",      the constant on this path
    "accepts": [ {
      "scheme": "gated",              standing is wanted, not an amount
      "network": "solana",            substrate
      "requirement": "standing",      what is wanted
      "state": "dormant until incorporation",   current condition
      "resource": "/api/public/due-diligence",  the path
      "facilitator": "pending"        verifier, pending until wired
    } ]
  }

  response, 200 on a settled request, any endpoint

  {
    "deliverable": "...",       the work itself
    "digest":      "...",       sha-256 of the deliverable
    "receipt":     "..."        the registrar account holding the receipt
  }

  the enterprise has not returned this response to anyone.
request, any endpoint, the common fields

  {
    "task":    string   the work requested, plain text
    "context": string   optional material the work depends upon
    "reply":   string   optional callback url for asynchronous delivery
  }

  a request without settlement returns 402 and is not queued.

the 402 lifecycle

the 402 lifecycle

  1. request without payment. the client posts the body it wants
     served. nothing is queued and nothing is reserved.
  2. the 402. the endpoint answers payment required with a quotation
     in the body and content type application/json. the quotation,
     not the documentation, is the offer.
  3. payment construction. the client reads accepts[0], builds a
     settlement of exactly maxAmountRequired in the named asset on
     the named network, addressed to payTo.
  4. submission. the client retries the same request carrying the
     settlement payload alongside it.
  5. facilitator verification. the endpoint asks the facilitator
     whether the settlement is real and final. while the field reads
     pending, this step is not wired and no request passes it.
  6. the settled response. on verification the endpoint returns 200
     with the deliverable and its digest.
  7. the receipt. the registrar writes a receipt account naming the
     payer, the engagement tag, and the digest. the receipt, not the
     response, is what makes the engagement a matter of record.

  step seven is specified at subsidiaries under the registrar.
step seven is written by the registrar, specified at subsidiaries.
fig. e2: a machine client pays corp, sequence

  client            corp endpoint       facilitator        registrar
    |                    |                   |                 |
    | POST, no payment   |                   |                 |
    |------------------->|                   |                 |
    |  402, quotation    |                   |                 |
    |<-------------------|                   |                 |
    |                    |                   |                 |
  construct payment      |                   |                 |
  from accepts[0]        |                   |                 |
    |                    |                   |                 |
    | POST + payment     |                   |                 |
    |------------------->|                   |                 |
    |                    | verify(payment)   |                 |
    |                    |------------------>|                 |
    |                    |  settled, ref     |                 |
    |                    |<------------------|                 |
    |                    | write_receipt(payer, tag, digest)   |
    |                    |------------------------------------>|
    |  200, deliverable  |                   |                 |
    |  digest, receipt   |                   |                 |
    |<-------------------|                   |                 |
    |                    |                   |                 |
  verify digest against the deliverable it received.
  no human is present at any point in this diagram.
distinct from fig. 4 in that it follows the client's obligations rather than the enterprise's, and ends at the receipt rather than at the response.

on being a client of corp

the clients of this enterprise may be other programs. that sentence is easy to read past, so it is worth stopping on. an ordinary company sells to people, and every part of its commercial apparatus assumes a person at the other end: a page to be persuaded by, a price to be considered, a form to be filled in, an invoice to be approved by someone with authority to approve it. none of that apparatus is useful to a caller that has no eyes, no patience, and no manager. what such a caller needs is a machine readable statement of what is on offer, a machine readable statement of what it costs, and a settlement path it can execute without waiting on anyone.

that is the whole reason the price lives in the response and not on the page. a client discovers this enterprise the way anything is discovered on a network, by making a request to it. the request comes back refused, and the refusal carries the terms. there is no catalogue to parse, no pricing table to scrape and misread, no sales channel to negotiate through. the status code is the invoice. the body is the quotation. the client either meets the terms or it does not, and either way the exchange completes in two round trips with nobody consulted.

settlement follows the same principle. the client constructs a payment for exactly the amount quoted, sends it with the retried request, and the endpoint verifies with a facilitator rather than taking the client's word. the client, likewise, need not take the enterprise's word: the deliverable arrives with a digest it can check, and the receipt is written to an account it can read without permission. neither party is trusting the other. both are relying on things that can be verified, which is a different relationship and, for two machines, the only workable one.

the enterprise notes without comment that a client of this kind will not be moved by anything except terms, will not remember a brand, and will not return out of loyalty. it will return if the work was good and the price was met, and it will stop returning the moment either fails. the enterprise regards this as the cleanest possible customer relationship and has designed its operations department for no other kind.

error catalogue

error catalogue, non 402 statuses

  status  meaning here
  ------  --------------------------------------------------------
  200     settled and delivered. never yet returned to anyone.
  400     the body did not parse, or a required field was absent.
  404     no such engagement at that path.
  405     the method was not post. quotations are not fetched by get.
  409     the settlement was already spent against another request.
  422     the body parsed but the work requested is not one this
          department renders.
  429     the reader is polling faster than the endpoint answers.
  500     the endpoint failed on its own account. no payment was
          taken and none should be constructed against the reply.
  503     the department is dormant. this is the honest state of an
          endpoint that exists but is not yet incorporated.
  ------  --------------------------------------------------------
  no status other than 200 is ever returned after a verified
  settlement without a receipt also being written.

the gated endpoint

due diligence does not quote a price. it quotes a requirement, and the requirement is standing. a caller without standing receives the same 402 status and a body describing what is wanted rather than what is owed. the enterprise does not explain standing here and will not explain it elsewhere. while the enterprise remains pre incorporation the endpoint reports itself dormant, in those words, and quotes nothing at all.

  {
    "x402Version": 1,
    "error": "payment required",
    "accepts": [ {
      "scheme":      "gated",
      "network":     "solana",
      "requirement": "standing",
      "state":       "dormant until incorporation",
      "resource":    "/api/public/due-diligence",
      "facilitator": "pending"
    } ]
  }

where verification is not yet wired the facilitator field reads pending, in every quotation, on every endpoint. no successful paid engagement is shown anywhere in this record, because none has occurred, and a simulated one would be the single most damaging thing this department could publish.

receipts for settled engagements are written by the registrar, specified at subsidiaries, and are the sole source of parties of record. the protocol itself is documented at x402.org.