Proof-first, not record-first
Documented architectureAn integrator's primary artefact is the proof object, not a row in someone's database. Holding the proof is what lets you verify later without asking us.
Builders
Developers, API & SDK
Planned
What integrating with ByteShares is intended to look like. There is no endpoint to call, no package to install, no key to obtain and no sandbox to register for. Everything below is a model you can review and argue with, not something you can run.
Not live
The developer platform is not operating. Nothing on this page reports real activity, and no operational figures are shown, because no verified operational data source exists yet.
No base URL, hostname, package name or credential appears anywhere on this page. Any that you encounter elsewhere claiming to be ByteShares did not come from us.
- Source / verification
- Interface drafts; no implementation to verify against
- Document version
- API contract: not yet assigned
- Last reviewed
- 19 September 2026
Questions about the documentation
Ask about documented architecture and readiness; answers cite the pages they draw from and do not verify a running platform.
Ask the documentation →Developer overview
The intended integration surface is narrow on purpose. A client presents identity and authority, submits an intent, and receives a proof object describing what the protocol did and under which rule version. Reads return accepted state and the evidence needed to check it independently.
Interfaces hold no authority
Documented architectureAn API is a convenience over accepted state. If it disagrees with the protocol record, the protocol record is correct.
Conceptual quick-start
01
Establish identity
Obtain a verified identity and the mandate that scopes what you may do. Mechanism not yet specified.
02
Describe the intent
Express the action, its inputs and the authority under which it is taken.
03
Submit
Present the intent with its proofs to an admission surface for rule evaluation.
04
Receive a proof object
Success or refusal both produce a verifiable record of what was evaluated.
05
Retain and verify
Store the proof; verify inclusion against a later epoch snapshot without trusting any interface.
No step above can be performed today. The sequence is published so it can be reviewed before it is implemented.
Authentication and identity model
| Concept | Intended behaviour | State |
|---|---|---|
| Client identity | Bound to a verified subject, not to an anonymous API key. | To be specified |
| Mandate | Explicit scope, issuer and validity period for what a client may do. | Documented concept |
| Delegation | An agent may act within a narrower scope than its principal, never wider. | Documented concept |
| Session | Short-lived and non-authoritative; authority always re-checked at evaluation. | To be specified |
| Revocation | Immediate effect on subsequent evaluation, with prior proofs remaining valid for their time. | To be specified |
Proof-object interaction model
Every interaction is expected to resolve to a proof object. Its fields conceptually cover the subject, the authority, the rule version, the inputs committed to, the outcome and the anchoring reference. The exact serialization, schema and hash construction are to be specified and are deliberately not invented here.
- Schema
- To be specified
- Serialization
- To be specified
- Hash construction
- To be specified
- Signature scheme
- To be specified
Conceptual API and explorer surfaces
| Surface | Intended purpose | Status |
|---|---|---|
| Submission | Present an intent with proofs for rule evaluation. | Planned; not built |
| Proof retrieval | Fetch a proof object by its reference. | Planned; not built |
| Inclusion verification | Check a record against an epoch snapshot root. | Planned; not built |
| Governance read | Read authorized decisions and rule versions. | Planned; not built |
| Public evidence lookup | Explorer-style queries over disclosable records. | Planned; not built |
Surface names describe function. They are not paths, and no path structure is published.
SDK structure
Intended responsibilities
PlannedProof construction and verification, authority presentation, snapshot inclusion checks, and typed models of protocol objects.
Deliberately out of scope
PlannedKey custody, wallet UI and membership or payment flows. The last of those belongs to ByteShares.dk, not here.
Languages
PlannedNot decided. No package name, registry entry or version is reserved or claimed.
Offline verification
PlannedA stated goal: verification of a retained proof should not require a call to any ByteShares service.
Examples
Conceptual only — no executable example exists.
Worked examples will be published when there is code behind them. A sample that cannot be run teaches the wrong shape and invites people to depend on a contract that has not been decided, so none is shown.
Integration lifecycle
01
Review
Read the documented model and raise gaps while it is still cheap to change.
02
Eligibility
Integration requires an authorized mandate, granted through governance rather than self-service.
03
Conformance
An integration demonstrates that it constructs and verifies proofs correctly.
04
Operation
Integrations run against a published contract version with a stated support window.
05
Change
Contract changes follow the versioning policy below, with notice before removal.
Error and status conventions
A refusal is expected to be as verifiable as an acceptance: it should state the rule version applied and why the evaluation failed, without disclosing unrelated data. Concrete codes, categories and payload shapes are to be specified.
Versioning and deprecation policy
| Element | Intended policy | State |
|---|---|---|
| Contract versioning | Explicit version on every interface and proof object. | Framework agreed; scheme not assigned |
| Breaking change | New version rather than mutation of an existing one. | Framework agreed |
| Deprecation notice | Announced period before removal, published in advance. | Period not set |
| Rule-version reference | Every proof names the rule version under which it was evaluated. | Documented concept |
| Historic verification | Old proofs remain verifiable after the contract moves on. | Requirement; unimplemented |
Source code
Awaiting GitHub connection. No repository is linked, named or implied, and the VPLedger source provenance audit is still open.
Publication follows a twelve-gate readiness process covering source inventory, integrity hashes, provenance classification, exclusion of sensitive material, licensing review, canonical repository mapping, build baseline, version baseline, documentation baseline, owner approval, import verification and the domain-release gate. A developer-docs repository is proposed for this material, and an sdk repository only if a distinct verified SDK codebase is found. Both remain proposals with no source accepted.
Evidence register
Each statement on this page is tracked against a source. A claim without a verified source is never presented as fact.
| Claim | Source type | Verification | Note |
|---|---|---|---|
| Interaction model, surfaces and lifecycle | Interface drafts | Source claimed, not yet verified | Drafted from the documented protocol model; no implementation to check against. |
| Proof-object schema, error codes and SDK contents | Specification | No source on file | Marked to be specified rather than invented. |
| Endpoints, packages, keys or sandboxes | Running service | No source on file | None exist; none are published. |