BRC-115v1.0

Identity-Linked Deterministic Token Verification Framework

When a token carries compliance rules, two wallets checking it must reach the same answer or transfers will be accepted by one and refused by the other. This pins the check down step by step so the outcome is never in doubt.

About Access gating, deciding who gets through, and on what condition.

AlsoIdentity Rulebooks

Filed under Tokens, though most standards about access gating sit in Applications.

Jake Jones9 Mar 2026changed 20 Oct 20264 min read

Reference for an AI

Everything an assistant needs to answer questions about BRC-115 accurately, including what it depends on.

Why: Token standards already cover how tokens are encoded and how identity metadata attaches to them, but nothing specifies how a wallet checks, by itself and without a trusted intermediary, that an identity-restricted token transfer is actually valid.
What: BRC-115 is a verification framework that lets a wallet confirm, using only deterministic key derivation, commitments, and SPV proofs, that an identity-linked token transfer satisfies its compliance rules.
How: A wallet checks token encoding, commitment integrity, SPV proof, identity certificate presence, derivation match, and compliance profile rules in a fixed order, rejecting the transfer if any step fails.

What this lets you do

Detect whether a token output is identity-linked
Derive signing keys deterministically from a certificate root
Reveal only the certificate fields a rule actually requires
Reject transfers that fail certificate, derivation, or compliance checks
Verify compliance offline using an SPV proof bundle

Written by claude-sonnet-5 from the specification text. Where the two differ, the original is correct.

The specification

Read the original

Abstract

BRC-115 defines a deterministic, SPV-verifiable framework for identity-linked token transfers on Bitcoin SV. It specifies how wallets verify compliance requirements using BRC-0042 key derivation, BRC-0107 commitments, and BRC-0108 identity bindings — without relying on overlay networks or external validators.

This standard ensures identity-restricted token transfers remain interoperable, decentralized, portable, and enforceable while enabling selective privacy, regulatory compliance, and recovery options within the original peer-to-peer Bitcoin model.

Motivation

Existing BSV token standards provide token encoding (BRC-0092), verifiable state transitions (BRC-0107), and identity metadata (BRC-0108). However, none define:

How identity-based constraints are enforced
How signatures bind identities to transaction lineage
How [object Object] wallets validate compliance without a trusted intermediary
How field-level revelation is performed and verified consistently

BRC-115 introduces a unifying rule set that makes identity-restricted token usage deterministic, verifiable, and portable between software implementations.

Architecture Overview

flowchart TB

    Wallet["Wallet / Client Logic"]
    Core["Protocol Enforcement Layer"]
    Ledger["SPV Proof / Bitcoin Ledger"]

    Wallet -->|Enforces BRC-115| Core
    Core --> Ledger

    subgraph Stack["Verification Stack"]
        D["BRC-0092:<br/>Base Token Encoding"]
        C["BRC-0107:<br/>Commitment Verification"]
        B["BRC-0042:<br/>Deterministic Key Derivation"]
        A["BRC-0108:<br/>Identity Certificate Link"]
    end

    Core --- Stack

Terminology

Term	Definition
Identity-Linked Token (ILT)	A token output containing a valid BRC-0108 certificate hash.
Compliance Profile	A structured set of rules defining identity requirements for token usage.
Derivation Scope	The deterministic key domain created using BRC-0042.
Selective Revelation Bundle	A minimally sufficient encrypted proof package revealing only required certificate fields.
SPV Proof Package	A format containing transaction data plus Merkle proof (optionally BRC-0067-formatted).

Normative Rules

1. Identity Binding

A token SHALL be treated as identity-linked if:

The token output contains a BRC-0108 certificate hash, AND
The spending signature is produced using a key derived per BRC-0042 from the certificate root.

If either condition is not met, BRC-115 SHALL NOT apply.

2. Deterministic Key Derivation

All operational keys MUST be derived using:

BRC-0042(master_certificate_entropy, assetId, purposeId)

Use of BIP-32, SLIP-10, hardened derivation paths, or external hierarchical schemes is NOT permitted.

3. Signature Requirements

Identity-linked token transfers MUST be signed using:

SIGHASH_SINGLE | SIGHASH_ANYONECANPAY

Exceptions are permitted ONLY in:

Custodial batch aggregation
Minting
Time-locked recovery workflows

Such exceptions MUST be explicitly signaled using BRC metadata.

4. Protocol Signaling

BRC-115 shall activate under a hybrid signaling model:

Implicit activation: Any transaction using identity metadata (BRC-0108) and BRC-0042-derived signatures SHALL be treated as BRC-115-compliant.
Explicit activation (optional): A protocol identifier MAY appear in metadata (e.g., 0115, 0115.1) for version governance.

Explicit signaling supersedes implicit interpretation.

5. Mandatory Verification Flow

A compliant verifying wallet MUST validate in the following order:

Token encoding validity (BRC-0092)
Commitment integrity (BRC-0107)
SPV validity (Merkle proof)
Identity certificate presence & authenticity (BRC-0108)
Deterministic derivation match (BRC-0042)
Compliance profile evaluation (rules + selective revelation)

Failure at any stage MUST reject the transfer.

Compliance Profiles

Profile	Required Identity Level	Typical Use
Open	None	Standard fungible tokens
Identity-Present	Certificate exists	Membership, access tokens
Restricted	Field-level selective revelation	Age verification, region gating
Regulated	Certificate type + rules	Securities and compliance tokens
Recovery-Capable	Secondary derivation	Lost-key account recovery

Verification Process

flowchart TD
  A[Parse Token] --> B[Commitment Check]
  B --> C[SPV Check]

  C --> D{Identity Linked?}

  D -->|No| H[ACCEPT]

  D -->|Yes| E[Certificate + Key Binding Check]
  E --> F[Compliance Profile Enforcement]
  F --> G{Accept?}
  G -->|Yes| H2[ACCEPT]
  G -->|No| I[REJECT]

Reference Implementation Guidance (Non-Normative)

Developers SHOULD:

Cache certificates to avoid repeated revelation requests
Use temporary encryption keys for field-level exchanges
Display meaningful compliance failure messages to improve UX
Support offline verification when proof bundles are present

Test Vectors

Vector 1 — Valid Identity-Linked Transfer

Expected Result: Accept

Vector 2 — Invalid Key Derivation

Expected Result: Reject

Vector 3 — Identity Valid, Compliance Failed (e.g., age restriction)