# Identity-Linked Deterministic Token Verification Framework

**Author:**\
Jake Jones (<jake.jones@bsvassociation.org>)

**Status:** Draft\
**Version:** 1.0

**Required Dependencies:**

* BRC-0042 (Deterministic Key Derivation)
* BRC-0092 (Mandala Token Protocol)
* BRC-0107 (Commitment-Based Token Integrity)
* BRC-0108 (Identity-Linked Token Metadata)

**Optional Dependencies:**

* BRC-0043 (Purpose Identifiers)
* BRC-0067 (SPV Packaging Format)

***

## 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 SPV 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

```mermaid
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:

1. The token output contains a BRC-0108 certificate hash, AND
2. 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:

1. Token encoding validity (BRC-0092)
2. Commitment integrity (BRC-0107)
3. SPV validity (Merkle proof)
4. Identity certificate presence & authenticity (BRC-0108)
5. Deterministic derivation match (BRC-0042)
6. 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

```mermaid
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)

**Expected Result:** Reject

Additional machine-readable vectors SHALL accompany the reference implementation.

***

## Backward Compatibility

| Case                                                       | Result                     |
| ---------------------------------------------------------- | -------------------------- |
| Non-identity tokens                                        | Unaffected                 |
| Legacy wallets                                             | MAY ignore identity fields |
| Identity-linked tokens spent without proper key derivation | MUST reject                |

***

## Security Considerations

* Commitment chaining prevents replay attacks
* SPV trust model maintained; no overlay dependency
* Selective revelation prevents unnecessary personal data exposure
* Recovery derivation prevents permanent loss without custodianship
* Prohibition of non-BRC-0042 HD schemes prevents fragmentation

***

## References

* BRC-0042: Deterministic Key Derivation
* BRC-0092: Mandala Token Protocol
* BRC-0107: Commitment-Based Token Integrity
* BRC-0108: Identity-Linked Token Metadata
* BRC-0067: (Optional) SPV Packaging Format