Skip to content
Talk to us
Technology

Build against the standard, not against our API.

What is specified is the record and how services must behave, so a provider can put it inside their own platform, product or workflow. This page is written for whoever has to implement that, so it names the machinery: two rails, spend chains, block headers, digests. Nothing below needs an account, a key from us, or our permission.

Read the docsSee the live services
You integrate againstThe standard, not our API
Verification runsIn the reader’s browser
Inputs it needsTransaction bytes, block headers
Countersignature keyPublished
Identity resolutionOperated by others
Three layers

Three layers, and none of them locks you in

One team builds all three today, which is why the boundaries look blurred. Separating them is the roadmap, not an accident.

ApplicationsConsumers of bothCommercial products, workflows and user experiences. This site is one of them, reading the same records through the same published interfaces as anyone else’s would.No application is mandatory, including this one.
ServicesIndexing, resolution, proof accessThe shared index, the resolver and the anchor viewer. They must behave as the standard defines, which is what makes an alternative real rather than theoretical.We run them today. The interfaces are published, so anyone can run their own and records stay readable across both.
The DPP standardIn progressHow records and services must behave. Fourteen fields and two signatures, the anchoring rules and lifecycle vocabulary, the canonical bytes and the service interfaces, plus a conformance suite anyone can run.Drafted by us and being moved to open governance, with a conformance suite anyone can run against any implementation.
One record

Four layers, and a different standard governs each one.

Each layer commits to the one above it. Choose one to see what it holds and what it is bound to.

names one unit, whose state is
carries a history, recorded as
is committed on chain by
The identifier

The model, then this one unit. The printed code and the web address are the same string, so there is no lookup table between them and nothing to keep in step.

Governed by GS1 Digital Link. In force, and not ours. We consume it: the address and the identifier are one thing, which is why the code on the product is not a link into our site that we could redirect or retire.

Two rails

Two rails. Either one proves a record without the other, or us.

The separation is the claim, not an implementation detail. Different protocol, different basket, and the two never mix outputs.

RailThe passport railoursThe anchor railthe resolver’s
What it commits
The passport state itselfFourteen fields, including both signatures and the payload.
A 32-byte digest of a signed attestationNever the attestation itself, so no personal data can physically reach the chain.
Protocol and basket
[1, 'dpp token v1'] · basket dpp · 1 satoshi
[1, 'bsv attestation anchor v1'] · basket attestation-anchor · 1 satoshi
Layout
Each state spends the one before it, so the history is a chain.
Eight fields; the eighth signs the varint-delimited preimage of the other seven. A leaf, never spent.
Indexed by
tm_dpp / ls_dppby passport id and chip uid
tm_attestation / ls_attestationby issuer, subject, type
To verify, you need
The transaction bytes and public block headers. Nothing else.
Any public transaction source, plus the attestation the digest matches.
This build's own choices
Wallet-storage broadcast, and the index names above. None of it is required by the standard.389 sat typical, per battery passport
A fixed-size output, so the cost does not move with the size of the record.67 sat, fixed, per anchor
No shared outputThe two rails never mix outputs, even when one treasury funds both. Funding may be shared; proof is not.
Identity and keys

Identity that resolves without us.

Three identifier types, each doing a job the others cannot. Two of them are resolvable by anyone, with no request to this platform and no permission from it.

did:keyResolves offline, from the identifier itself. No registry and no network, one method only. It cannot record that a rotation happened.
did:bsvA transaction id, never derived. Versioned on chain by spending the tip, and resolved by a Universal Resolver operated independently of us.
did:webServed by us, at a well-known address. Two methods, one per key, and a retired key bounded by an expiry so the history stays readable.
Your identity, resolvable by anyoneYour organisation is named by a did:bsv, resolved through a Universal Resolver that this platform does not operate. Anyone confirming that a record came from you is asking that resolver, not us, which is what makes an entry you signed portable to any system that reads the standard.An owner never gets a key, and that is permanent rather than pending: owner keys derive per passport, so a holder cannot be correlated across the records they own.
What adopting this commits you toNothing that is ours. The identifier is GS1’s, the lifecycle vocabulary is a W3C community draft, and the identity method is published by its own authors. Records you publish stay readable by software nobody here wrote.The roadmap is co-control of your own identity, with recovery as a mandatory delay and a notification. We name it as roadmap rather than as a feature.
Run and inspect

The surfaces that are running, with their addresses.

Every address below is live and follows through to the thing itself. The last one is a resolver we do not run.

SURFACEROLEADDRESS
The demonstrationThe consumer facedpp.bsvb.net
The public checkCheck a passport in your browserdpp.bsvb.net/verify
The shared indexFinds records by passport iddpp-overlay.bsvb.net
The resolverLifecycle attestations and anchorsdpp-resolver.bsvb.net
The anchor viewerThe evidence behind one recorddpp-proof.bsvb.net
The platform identityCountersignature key history/.well-known/did.json
The register entryThe signed registration credential/.well-known/untp/swi/registration.json
Identity resolutionA Universal Resolver operated independently of usbsvdid-universal-resolver.nchain.systems
The last entry is a Universal Resolver we do not run. Identity resolution for our brand identifiers does not depend on this platform being up.
The standard, layer by layerFour of the five are live and readable now. Follow any of them.
GS1 Digital LinkIn force, and consumed as publishedDPP Token Standard v1Ours, publication pendingVSC SEAL credential compatibilityPinned draft profile; native claims remain separateUNTP credential carriageAlignment underwaySector data profilesServed today, scope undecided
Where this standsThe specification the credential carriage aligns to is UNTP 0.7.0, a pre-1.0 release tagged in May 2026. We say aligned with and underway, never compliant and never in the past tense.The record model and the rules are drafted and the repositories are private. Until they are public, a standard anyone can build on describes intent rather than fact.Every run of the public check so far has been ours. We quote no outside validation, because there is none yet.Standard, services and frontend are developed by one team today, so the boundaries between them are blurred on purpose. No provider has yet built on this independently.All six limits, in full →

Evaluate it the way you would evaluate any dependency.

Run the five checks yourself, on a record you did not choose, against public data. Each one shows the evidence it used and the command that reproduces it, so your own engineers can confirm the result without us in the room.

Run the five checksThe business case