Specifications for the Boli operating layer.
A Boli Standards Proposal — BSP — is a versioned specification document. BSPs cover the three Daml asset patterns, the chain-level compliance-pack engine, the multi-VM mirroring protocol, the TDIP identity bridge, and the marketplace and agent-mandate protocols that compose with them.
Anchored on a transitional basis by the Boli Association (Switzerland); upon formation of the Boli Foundation, standards-setting governance for the BSP process passes to the Foundation. The process is itself a BSP — BSP-0000.
Currently published. The full status table and history live in the repository.
BSPs are numbered in the order Drafts are filed · A BSP keeps its number for life
Three statuses. An editor records the move.
- Draft
- Under discussion. Author may revise freely. Breaking changes are expected.
- Final
- Accepted. For a Standard BSP, a reference implementation exists. The BSP is frozen — errata only.
- Replaced
- A later BSP has superseded this one. The replacement names it in its Replaces header.
Two kinds of BSP. Different obligations on reaching Final.
A normative specification — a Daml interface, a wire protocol, a predicate vocabulary, a credential schema, a pack-catalog entry. The primary work product. Reaches Final once a reference implementation exists.
A non-normative document — a deployment guide, a recommended operating practice, an architectural overview, the process document itself. Reaches Final once the editors judge it complete.
BSPs cite and depend on three other corpora.
The Boli operating layer is built from primitives owned by other standards bodies. BSPs cite, never duplicate.
The Canton protocol and its institutional-grade token standard (CIP-0056). Boli's Daml-layer BSPs cite and depend on CIPs.
The Global Synchronizer Foundation's token APIs — AllocationV1, transfer instructions, holdings. The Tradeable pattern composes with Splice V1.
DIDs, MPC wallets, W3C Verifiable Credentials. The TDIP-to-Canton bridge BSP lives here; the underlying spec lives at Tenzro.
Four-digit, zero-padded. Once assigned, kept for life.
BSPs are numbered in the order Drafts are filed. An editor assigns the number on first review. Numbers do not imply importance or order of finalisation. 0000 is reserved for the process document; there are no other reserved ranges.
Withdrawn or Replaced numbers are not reused. A BSP retains its number for life — even when superseded.
Anyone may author a BSP.
Discussion happens in pull requests and linked issues. For a Standard BSP to reach Final, a reference implementation must exist and be cited in the BSP.
- 01Copy the template folder.
bsp-XXXX/contains the structural skeleton. Rename to a slug of your title; an editor assigns the number on first review. - 02Fill the frontmatter.RFC-822 inside a
<pre>block. Required: BSP, Title, Author, License, Status, Type, Created. Conventions in STYLE.md. - 03Open a pull request.Branch named
bsp-<handle>-<slug>. Iterate on review. For a Standard BSP, cite the reference implementation before merge. Full procedure in CONTRIBUTING.md. - 04An editor merges.The merging editor must not be the BSP's author. At least one other editor must have reviewed the PR, with the review recorded in the thread. No formal vote, no time window — the two-editor pattern is a check on accidental merges.
The whitepaper provides the architectural context that frames the BSPs.
v0.9 of the Boli Whitepaper sets out the operating layer, the institutional rail, the three asset patterns, the regulatory line, and the operating model. The BSPs supply the normative specifications.