The reference is always regenerated​

The reference is generated by docusaurus-plugin-openapi-docs. That plugin only writes a page if no file of that name exists yet. So far the build ran it over the pages it had written before. An edit to openapi.yaml would have kept the old pages, and nothing would have failed. The build now empties the reference folder first.

A new test also decodes the operation embedded in every generated page and compares it with openapi.yaml:

• there is one page per operation and webhook, and no page for an operation the document no longer has;
• each page has the operation's method, path, summary, description, tags, parameters and response codes;
• each schema has a page, and the reference names the version of the document it was built from.

Operation pages by screen width​

The description and the samples of an operation page used to share the 760 px column meant for prose. That column is now the limit for each panel on its own:

The request samples come in curl, JavaScript (fetch), Python (Requests) and Rust (reqwest): curl, plus the three languages the SDK guides cover.

A rail on very wide screens​

At 2560 px and wider, a guide page keeps its 760 px article. Beside it is a rail that stays in place as you scroll, with two parts:

• On this page: the page's headings.
• Related errors: each error code the page links to, with its HTTP status.

The error list is built from the page's own links, so it always matches the text. Narrower screens do not show the rail.

Status page brought up to date​

Status and SLOs lists what is built but not proven. Three of its lines were out of date:

• The allocator that gives each API host its share of an account's cap is now written.
• Inclusion tracking now has all three of its sources wired.
• Pay-as-you-go settlement now runs end to end in a test.

Each line now says what the backend's tests prove and what they do not. All three are tested only against stand-ins for the database and the chain. Their tests against a real database have not yet been seen passing.

Found while checking​

• Two layout rules for phones and ultrawide screens matched no element, so neither had any effect. They are fixed. The ultrawide rules also started at 2200 px instead of the 2560 px where that layout class begins.
• Some operation descriptions in the API document mention internal specification sections, such as "relay-intent.md section 10.6". The reference shows the document as it is. The wording has to be changed in the API document itself, not in the reference.

Samples cut from tested files​

There are thirteen files in docosaurus/examples/: a wallet wrapper, a gateway reader, relayer verification, send-and-relay, the re-sign path, preflight, tier choice, buying a plan (through the API and over x402), following an intent (by polling and over SSE), retries, the Relay Unit formula and a complete agent quickstart. A code fence on a page names its source, and the build syncs the fence from that file:

```ts snippet="examples/send-token.ts#relay"
```

The tests run each example against a local fixture of the API and the gateway. The fixture verifies presence proofs and accepts each one only once. It hands out re-sign assignments, walks the x402 flow and streams intent events. It refuses any host other than its own .invalid addresses. So no test contacts a network, and none depends on one being up.

One signature, checked​

Every example that signs goes through the same guard, which throws on a second call:

Error: relayOnce: the signer was called twice.

A test checks that the message the pages quote is the one the guard throws. When the API answers RESIGN_REQUIRED, the example signs the transaction for the relayer the API pinned in that answer. It does not sign a new variant for each candidate. See Handle a re-sign.

New pages​

• Verify a relayer: check the relayer the API assigned against the on-chain registry before you sign for it.
• Relay Units: moved from the pricing section, because it defines the unit and prices nothing. Twelve worked examples are recomputed by the test suite.
• Intent lifecycle: every state an intent passes through, as a diagram.
• Sponsoring senders, Usage proofs and Telemetry.

What is not there yet, said plainly​

• The MCP server: 4 of its 20 tools run end to end, and its resources and prompts cannot be read yet. The tool list marks which tools work.

• The JavaScript SDK:

  • its one-call relay cannot yet take the relayer pinned by a re-sign answer;
  • it has no helper for relayer verification, x402, Relay Units or event streams.

  The guides show the plain code for each of these instead.

• Operations: the usage-proof path, the quota slice allocator, inclusion tracking and settlement batches are listed as gaps on Status and SLOs.

Checked in a browser​

The built site now runs in Chromium with its production headers, including the generated Content-Security-Policy. Each kind of page is checked for accessibility (axe, WCAG 2.2 AA) in both themes, for console errors and for requests to another origin. The layout is checked at nine widths, from a folded phone's 344 px cover screen to a 2560 px ultrawide.

What is generated rather than written​

Roughly two thirds of the pages on this site are not written by hand, and that is deliberate — a reference page that a person maintains is a reference page that drifts.

A check mode regenerates everything into memory and fails on the first difference, so a stale reference page breaks the build instead of shipping.

The strongest of these is the error catalogue: an error code that exists in the API without a page here fails this build. Since every problem document's type member is the address of its page, that turns a machine-readable promise into something that cannot quietly rot.

For machine readers​

• /llms.txt — the index
• /llms-full.txt — every page in full, with the API reference appended
• /llms-agents.txt — only the agent, MCP, x402, API and error pages
• any page, as Markdown — append .md to its URL
• /openapi.yaml, /errors.json, /abi/corelayer.abi.json

robots.txt allows everything and blocks no crawler, including AI crawlers. Documentation is for reading.

The build refuses to ship a broken link​

After the site is built, a script walks every page of the output and resolves every internal link and every fragment against the files that were actually produced. External links are held to an allow-list of hosts this project means to link to. It is offline on purpose: a build that reaches out over the network is not reproducible.

It also checks the agent-facing output for leaked JSX, template placeholders and unresolved snippet imports — the specific ways Markdown generated from MDX turns into noise.

What this site will not tell you​

No uptime percentage, no latency target, no benchmark. CoRelayer has never run in production, so there is nothing measured to publish, and a number that is not measured is not a number. Where a page has to describe an intention it says "designed for"; where it would be guessing, it says nothing. (Status and SLOs)

@corelayer/tokens​

Design tokens authored in the DTCG format and compiled two ways: a Tailwind v4 @theme block and a typed TypeScript module. Dark and light are both first-class, and a contrast gate runs in the build — a token pair that fails its contrast requirement fails the build rather than shipping.

This documentation site uses the same file. src/css/tokens.css here is a verbatim copy of @corelayer/tokens/themes.css, written on every build, and every Infima variable points at one of its tokens. One edit re-skins all three sites.

@corelayer/ui​

The component library: a theme provider that applies the stored theme before first paint, so there is no flash of the wrong one; self-hosted Geist and Geist Mono; and the component inventory the front-end specification calls for. Charts, icons and illustrations are separate entry points so a page pays only for what it imports.

The fonts on this site come from that package, rewritten to versioned paths under /fonts so that the preload and the @font-face rule name the same URL and nobody downloads a font twice.

@corelayer/sdk​

The typed client. Four parts:

1. Generated types. Every request and response shape comes from openapi.yaml. A check mode fails if the checked-in types have drifted from the document.
2. A transport with direct-host failover: when the edge does not answer in time, the identical bytes are resubmitted to a regional host.
3. Typed errors matching the RFC 9457 catalogue, including the open-enum rule — an unknown code keeps its status and retryable instead of being guessed at.
4. relayOnce, which assigns a relayer and submits exactly one signed transaction. It wraps the caller's signer so that a second invocation throws.

Nothing in the package contacts a chain. Every call goes to the CoRelayer API, which is why the test suite needs no network: point baseUrl at a fixture server and the whole client is exercised.

SDK documentation · TypeScript guide

Not published​

None of the three is on a public registry yet. They are workspace packages in this repository.

The marketing site​

Twelve routes: the product, pricing, the network, the agent story, the developer entry point, the Finance Computer argument, the brand page, security, and the legal pages. It prerenders, so every page is static HTML with its own metadata, and it serves a Markdown twin of every page at <path>.md plus /llms.txt and /llms-full.txt for machine readers.

Two things on it are calculators rather than claims:

• the plan calculator, which takes a volume and shows what each tier would cost, including where pay-as-you-go becomes more expensive than the next tier up;
• the Relay Unit estimator, which applies the published formula to a transaction's gas limit, gas price, data size and guarded flag — the same arithmetic the API does, in the browser.

Both are driven by the launch pricing snapshot, which is also the source this documentation's tier table is checked against.

The dashboard​

Wallet login, then the account: plan and checkout, billing and deposits, usage and transactions, latency, relayers, senders, API keys, notifications and incidents.

The relay flow is the part worth naming. It is built around a single signature: the assignment names the relayer, the transaction is signed once, and the only case that asks for a second signature is an explicit dialog that says the first attempt sent nothing and never will. (One signature)

What they talk to​

Nothing, for now. Both run against the mocked API in development and against fixtures in their tests; no build of either contacts a chain. That is a property, not a workaround — the front ends never speak to a node directly even in production, only to the CoRelayer API.

What was fixed​

Decisions worth naming​

• One price lever. A single integer on chain — micro-USDC per Relay Unit, initially 10,000 — from which every price is derived. No second value carries a USDC price anywhere in the system. (The tariff)
• One signature per action. No multi-variant signing exists anywhere in the product. The SDK enforces it structurally rather than by convention. (One signature)
• Errors are addresses. Every error is an RFC 9457 problem document whose type is a page on this site. A code that exists in the API without a page fails the documentation build. (Error catalogue)
• Milliseconds, and no keeper. Every time value is milliseconds of block time, and every schedule activates lazily when somebody next touches the state. Nothing depends on a job running at the right moment. (Timestamps)
• Measured numbers only. No SLA percentages and no service credits at launch, because there is nothing measured to base them on. (Status and SLOs)

What this means for an integrator​

The API document is the contract: /openapi.yaml. Client types are generated from it, this reference is generated from it, and the plain-Markdown summary agents read is generated from it. Nothing hand-writes a response shape, in any of the three.