Developers

Receipts in your stack.

Wrap a tool call, get a hybrid-signed receipt. Verify it anywhere with the published verifier. Reference packages ship with byte-exact vectors so your implementation can prove it agrees.

Try the verifierSpecs and vectors
MCP shimIn development
VectorsPositive + negative
Canonical formRFC 8785
Public SDKsPlanned
00 For builders

Add proof without rewriting your agents.

Most teams meet R-Series in one of three ways: through the MCP shim, which receipts every tool call an agent makes; through Connector OS, which receipts every action across business systems; or by calling the reference library directly from their own code.

In all three cases the agent's behaviour does not change. Receipts are produced next to the action, chained to the previous one and signed with the hybrid suite. Verification uses the same open code your auditors and customers can run.

The reference implementation is written against widely used open-source primitives with no other runtime dependencies, and ships with byte-exact vectors so your own implementation can prove it matches.

01 Integration path

Four steps to your first checkable receipt.

The console on the left follows along: a package, an issuer, an agent at work, and a verifier that needs nothing from DCS. The code shown is illustrative; the API reference is planned.

Developer console01 / 04
STEP 1 · INSTALL

Add the shim or the reference package.

Put it in the service that runs your agent. The MCP shim and the reference package are in development.

  • One package in the service that runs your agent
  • No change to your tools or your MCP servers
STEP 2 · CONFIGURE

Configure an issuer.

Generate hybrid keys, register them, and choose the suite. Our staging keys sit in a cloud KMS behind a key handle; the HSM/KMS adapter contract is defined and production hardware custody is an operational gate.

STEP 3 · RUN

Run your agent.

Every tool call or action now returns a signed, chained receipt next to its normal result. Each receipt names its parent, so a run becomes a chain you can replay.

STEP 4 · VERIFY

Verify, offline.

Check canonical bytes, the digest, both signature legs and the inclusion proof, in CI, on a laptop or in the browser verifier. A missing leg is a failure, not a warning.

02 Three ways in

Pick the boundary that suits you.

RouteWhere it sitsWhat gets a receiptState
MCP shimBetween an agent and its MCP serversEvery tools/callIn development
Connector OSBetween agents and business systemsEvery hop through an adapterIn development
Reference libraryInside your own serviceWhatever you choose to wrapIn development
S1 HTTP edgeA signing service over HTTPRequests from any languageIn development
03 MCP

Receipts for every tool call.

The MCP shim sits between an agent and its tools and emits a hybrid receipt per call. No change to the tools themselves.

In development

# illustrative: the shim is not yet published

# place it between your agent and its MCP server;
# each tools/call then carries a hybrid-signed receipt.
# Full API reference: planned.
04 What a verifier checks

Six checks, in order. Any failure stops the run.

01 · PARSE

Readable receipt

The receipt parses and has a body and a signature block. Unknown fields are refused by the closed S2 schema.

02 · CANONICALISE

One exact byte form

The body is re-encoded with RFC 8785, so key order and whitespace cannot change what was signed.

03 · DIGEST

SHA-256 matches

The digest of the canonical bytes must equal the one in the receipt. One changed character fails here.

04 · ED25519

Classical leg

The Ed25519 signature verifies against the issuer's registered key, under one strict verification rule.

05 · ML-DSA-65

Post-quantum leg

The FIPS 204 signature verifies against the same issuer. Stripping it is a downgrade attack, and is rejected.

06 · POLICY

Both legs, right chain

The hybrid suite requires both legs; the parent link and inclusion proof must lead to a known root.

05 Toolkit

What is available.

REFERENCE

Zero-dependency core

Node.js reference built on widely used open-source primitives, no runtime dependencies beyond them.

In development

VECTORS

Published vectors

Positive and negative cases, including downgrade and transplant attacks.

In development

LANGUAGES

Several implementations

Byte-identical canonical form across several languages in internal CI.

In development

VERIFIERS

Three independent verifiers

JavaScript, Python and Go verifier implementations agree on every published vector. A verifier is defined as much by what it refuses as by what it computes.

In development

API

Hosted verify API

Verify receipts and inclusion proofs over HTTPS.

Planned

SDKS

Language SDKs

JavaScript and Python SDKs that call the verifier through one interface.

In development

DOCS

Normative spec + RS/2 vectors

The exact signed bytes, suite IDs and acceptance rules, published with the first public v2 verifier.

Planned

CONFORMANCE

Conformance kit

Three tiers: published vectors, supplementary vectors, and a reject tier of inputs a verifier must refuse. Run it against your own verifier.

In development

TRANSPORT

A7 dCBOR

Deterministic CBOR encoding with frozen, hash-pinned vectors and a Python decoder with parity.

In development

EXPORT

COSE / SCITT export

A projection of the receipt for transparency services.

In development

Build against the specs, not against us.

Every field in a receipt traces to a published standard. Implement it yourself under a licence from DCS and prove you agree with the vectors.

See the standards
06 Questions

From developers.

Which languages are supported?

The reference is Node.js. Three independent verifiers, in JavaScript, Python and Go, agree on every published vector, and a conformance kit with published, supplementary and reject tiers is in development. Public SDKs are planned.

Does it slow my agent down?

Signing a canonical receipt takes milliseconds. Anchoring happens in batches, away from the request path.

Where do the keys live?

Staging keys sit in a cloud KMS behind a key handle today, with a provider-neutral HSM/KMS adapter contract defined. Hardware custody for production keys is planned.

Is the code in the console real?

The checks are real. The package name, configuration and function names in the animation are illustrative until the API reference is published.

Can I verify without calling DCS?

Yes. Verification needs the receipt, the issuer's public keys and, for inclusion, the log root. No DCS service is in the path.

Want the details for your sector? Book a briefing — we share the full design and a live demo in a private session.