# Bitcoin-Anchored Collateral Commitments **A Pattern, and its Construction** *Version 1.9 — May 2026* --- > **Core invariant.** Per-commitment production cost is positive and scales linearly with volume up to operational constants, under a stated, adversary-favourable threat model. The architectural contribution is cost preservation and attribution: production cost paid by a holder persists as attributable scarcity across every system that recognises the commitment. See *Orange Anchor White Paper v2.3* for the full argument. --- ## Abstract A Bitcoin-anchored resource-bound collateral commitment is a self-issued digital object that requires the expenditure of real, non-recoverable resources during an interval bracketed by two Bitcoin transactions. The resulting object carries a permanent, publicly verifiable trace of that cost and can be marked as compromised if later linked to abuse. This restores an ancient pattern in which upfront cost served as collateral for good behaviour and broken pledges were publicly marked rather than seized. The mechanism produces a structural economic asymmetry. Honest users incur only sunk cost on hardware they already own, while adversaries seeking to produce many instances face costs that scale linearly with volume. This paper presents the architectural pattern, the Orange Anchor as one calibrated construction, the interaction model under which commitments are presented and marked, and the economic argument that this asymmetry renders large-scale synthetic participation cost-prohibitive. Formal cryptographic and economic arguments are developed in companion documents. --- ## 1. Introduction ### 1.1 The Historical Pattern Societies have long used real upfront cost as a guarantee of good behaviour. Earnest money secured commercial pledges, security deposits protected tenancies, and bonds bound participants in guilds and trades. The structure was consistent: a non-recoverable cost committed at the outset functioned as collateral against future misbehaviour. When such a pledge was broken, the response was typically public marking rather than confiscation. Dishonoured instruments were protested, guild members were blackballed, and attainted persons lost standing in the public record — without transferring value to anyone. These mechanisms worked because the cost was already sunk and because the permanent record of breach removed the offender from future participation more effectively than any single penalty. ### 1.2 The Digital Disruption Open digital systems have eliminated this ancient mechanism. Claims, accounts, credentials, and content can now be produced at near-zero marginal cost. When the cost of participation collapses, the collateral function of upfront cost disappears. The common response — verification infrastructure run by trusted intermediaries — reintroduces precisely the centralisation that open systems were intended to avoid. This failure appears across multiple domains: the Sybil problem in distributed systems, verification recentralisation in self-sovereign identity, the absence of digital scarcity for non-monetary objects, and the loss of provenance in AI-generated content. All four describe the same underlying gap. Digital objects carry no inherent trace of real cost and can therefore be produced without limit. The missing element is a mechanism that allows a digital object to carry, within itself, independently verifiable evidence of real resources expended during its creation — such that the cost is non-recoverable, the evidence is checkable by any party, and the object's future usability can be publicly marked when linked to abuse. ### 1.3 The Proposal Bitcoin provides the required substrate: irreversible ordering, a neutral public record, unchanging consensus rules, and global verifiability from block headers alone. Its permanence and neutrality — not its monetary properties — make it the right substrate. The structure is **prepaid and succinct**. A single non-recoverable expenditure produces a compact cryptographic object whose existence and timing are anchored to Bitcoin's public sequence. The same object then carries the cost-backing of many subsequent relationships — paid once, used many times. Where Hashcash priced each transmission as a pay-as-you-go cost per message, this pattern prices the standing claim itself: a single sunk commitment serves an unbounded number of future interactions. This paper proposes **Bitcoin-anchored resource-bound commitments**, an architectural pattern in which a producer commits real resources during an interval bracketed by two Bitcoin transactions. The work is witnessed through cryptographic and physical mechanisms that bind the expended resources to the producer's device. The result is a self-issued collateral commitment whose existence and timing are permanently recorded on the Bitcoin ledger. The pattern is load-bearing; the Orange Anchor construction is one calibrated instantiation. This paper develops the pattern, the construction, the interaction model, and the economic argument that linear adversary cost against sunk honest-user cost produces an asymmetry sufficient to make large-scale synthetic participation cost-prohibitive. --- ### 1.4 Scope and Non-Goals This paper presents Bitcoin-anchored resource-bound collateral commitments as an architectural pattern for producing self-issued digital objects that carry verifiable evidence of real resource expenditure. The pattern's load-bearing claim is that, under the threat model defined in the companion *Strategic Cost Calibration Model v1.3*, the cost of producing N such commitments scales linearly in N. The pattern does not: - Establish or verify legal identity, personhood, or uniqueness. - Prevent all forms of Sybil participation; it raises the economic cost of large-scale synthetic production. - Provide cryptographic proof of physical operation; sensor coherence raises adversary cost but is not treated as unforgeable. - Require any particular calibration profile, sensor regime, or witnessing mechanism; these are construction choices, not pattern requirements. - Depend on batching operators for its core cost-positivity property; batching affects the magnitude of the asymmetry, not its existence. - Replace existing identity, credential, or trust infrastructure; it is designed as a composable economic layer that can sit beneath or beside such systems. Full scoping of the threat model, calibration assumptions, and acknowledged limitations appears in the *Strategic Cost Calibration Model v1.3* §10 and the *Orange Anchor White Paper v2.3* §10. This paper confines itself to the architectural pattern and one illustrative construction. --- ## 2. The Pattern ### 2.1 The Architectural Primitive The architectural primitive is *cost-backed witnessing notarised by Bitcoin*. A producer commits resources off-chain during a window bracketed by two Bitcoin transactions. The resulting commitment is bound to those anchors and verifiable against the Bitcoin ledger by any party with access to block headers alone. The commitment's authenticity rests on three properties. First, the resources committed must be real and non-recoverable — energy, time, memory, and attention — a cost actually incurred rather than a stake held in escrow. Second, the commitment must be cryptographically bound to the bracketing anchors such that it cannot be pre-computed before the first anchor exists and cannot be retroactively fabricated after the second anchor closes. Third, the commitment must be independently verifiable against Bitcoin's block headers alone. This paper carries both the architectural argument and the formal pattern specification. The commitment is not a credential, not a token, not a reputation score, and not an identity. It is a self-issued, non-transferable digital object whose value derives from the cost committed in its creation and the public record of its standing. Its analog in older systems is the guild bond or earnest pledge: real upfront expenditure that establishes standing, persists publicly, and can be tarnished through public marking when violated. ### 2.2 Why Bitcoin Specifically The pattern requires a substrate with four properties: irreversible ordering of recorded events, neutrality such that no party can rewrite history, unchanging consensus rules that preserve prior commitments, and globally available verification against the substrate's record. Bitcoin is the only currently operating system that satisfies all four at planetary scale. Substrates with shifting consensus rules, in-protocol governance, or trust assumptions about validator sets fail to provide the required durability. A commitment whose future verifiability depends on evolving consensus cannot serve as collateral. Bitcoin functions here as the universal time-and-ordering substrate, used for its permanence and neutrality rather than its monetary properties. ### 2.3 The Architectural Property The pattern produces a structural economic asymmetry between honest users and adversaries. An honest user pays only the marginal cost of running existing hardware for the bracketed window — once, regardless of how many relationships the commitment subsequently serves. An adversary producing many instances faces costs that scale linearly with volume. Each instance requires its own bracketed window, its own resource commitment, and its own cryptographic binding. The bracketing prevents parallelisation: producing N commitments concurrently requires N device-slots, each completing its own sequential interval. Unlike Hashcash-style proof-of-work, which parallelises across commodity hardware, adding capacity here adds device-slots rather than throughput per slot. **The load-bearing architectural property is therefore this: the cost an adversary must pay to produce N collateral commitments is linear in N. Sophisticated adversaries can reduce the per-instance cost through engineering optimisation, but the linear scaling itself — one bracketed window per instance, anchored to Bitcoin's real-time block sequence — cannot be eliminated by any optimisation strategy. This property holds for any instance of the pattern under any calibration profile. The magnitude of cost per instance depends on the construction and threat model; the linearity does not.** *Scope of the per-instance cost claim.* The architectural claim that capital cannot compress per-instance cost holds when the construction's memory-hard working set per concurrent instance exceeds the cache hierarchy of practical attack hardware on commodity server-class platforms. Calibration parameters — specifically the memory-hard working-set size, VDF difficulty parameter T, and the bracketed window duration — are chosen jointly to keep this regime active; the parameter set for the reference Orange Anchor construction is published in the *Strategic Cost Calibration Model v1.3* (calibration-pending) and finalised in the reference implementation. Under parameter regimes too small to exceed practical cache capacity, capital can compress per-instance cost through cache-resident batching; the construction's calibration profiles are explicitly chosen to remain outside that regime. ### 2.4 Boundary of the Architectural Claim The pattern does not specify a cryptographic primitive, sensor regime, or calibration profile. These choices belong to specific instances, of which the Orange Anchor construction in §3 is one. A reader who accepts the pattern need not accept any particular construction's calibration. A reader sceptical of one construction may still find the pattern valuable as a framework for developing alternatives. --- ## 3. The Construction ### 3.1 Orange Anchor as a Pattern Instance The Orange Anchor is one calibrated instance of the pattern, presented as a concrete construction sufficient to demonstrate the pattern in practice and to support an initial reference implementation. Full mechanical, parametric, and security-analytical detail appears in §4–§6 and the companion *Strategic Cost Calibration Model v1.3*. This section describes the construction at the level required to evaluate the architectural proposal. ### 3.2 The Bracketed Work The construction commits resources during a window bracketed by two Bitcoin transactions. An opening anchor binds the construction to the chain's state at a specific moment. A closing anchor seals the commitment. The opening anchor prevents pre-computation. The closing anchor prevents post-hoc fabrication. The Standard calibration profile uses a 24-hour window, deliberately over-engineered to impose meaningful cost on sophisticated adversaries. Shorter durations are available for lower-assurance contexts, as specified in §4.1 and the *Strategic Cost Calibration Model v1.3*. The bracketed window incorporates two cryptographic primitives: memory-hard computation, which prevents parallelisation across attacker hardware, and a **verifiable delay function (VDF)**, which proves the work was performed sequentially over real elapsed time. The construction uses the Wesolowski [2018] VDF over a fixed group of unknown order — an RSA-2048 group in the reference implementation, with class-group instantiation over imaginary quadratic order documented as a permitted alternative — with difficulty parameter T calibrated to the bracketed window's wall-clock duration. Memory-hard computation imposes a sustained DRAM-residency requirement sampled at regular cadence; attempts to substitute slower storage accumulate observable latency debt that eventually violates the construction's freshness bounds. Additional Bitcoin block headers introduce entropy at confirmation cadence throughout the window, binding the construction's progress to Bitcoin's ongoing consensus. ### 3.2.1 Confirmation Depth and Reorg Handling Both the opening and closing anchor transactions are referenced by Bitcoin block height in the verification package. To bound the construction's exposure to short Bitcoin reorganisations, **a verifier MUST require at least 6 confirmations on the end (closing) anchor before treating the commitment as fully settled.** Protocol consumers operating under elevated-risk policies (high-value cosign, regulated identity binding, large-scale token allocation) MAY require deeper confirmation — 12 or 100 blocks are common practitioner thresholds aligned with Bitcoin custody conventions — and SHOULD document the chosen depth in their published acceptance policy. Lightweight verification (SPV / header-only) confirms inclusion and depth but, by construction, carries the residual reorg exposure inherent to SPV: a verifier without a full Bitcoin node accepts the most-work header chain reported by its peers and can be deceived into accepting a temporarily orphaned anchor by an adversary that withholds a competing chain segment. Heavyweight verification (full-node) eliminates this exposure at the cost of running a node. The reference implementation supports both modes; the choice is a verifier policy decision documented per *BAVAI Operator Specification v1.0* §7. An anchor transaction reorganised out of the canonical chain after initial verification invalidates the commitment retroactively; verifiers SHOULD subscribe to chain-reorg notifications (or re-check anchor depth on a cadence appropriate to their policy) for any commitment they treat as currently authoritative, particularly within the first 100 blocks after the end anchor's first confirmation. ### 3.3 Bare Metal Witnessing The construction exploits a fundamental architectural property: virtualisation has overhead that bare metal does not. Real sensors on a real device respond to real physics without simulation cost, because they are the physical systems being measured. The device cannot help producing cross-modal correlations between sensor channels — accelerometer with gyroscope, thermal with power, ambient sensors with the device's actual environment — because these correlations reflect the shared physical substrate of the hardware itself. They are properties of the device, not artifacts of measurement. A virtualised attacker faces a structurally different cost. Each sensor channel must be simulated. The cross-modal correlations between channels must be modelled and coordinated in real time. Provocations injected by Bitcoin entropy at block-confirmation cadence cannot be pre-computed, because the entropy is not yet available; they must be responded to per instance, in real time, with simulated physical effects that maintain coherence across all simulated channels. Every layer of simulation adds overhead. The overhead is fundamental to virtualisation, not to any specific implementation. This is the same architectural property that makes virtualised computation always slower than bare-metal computation: layered abstraction has cost. *Joint coherence* is the term we use for the property that multiple sensor channels remain consistent with one another and with the device's physical couplings under sustained computational load. On bare metal it emerges naturally. On virtualised systems it must be expensively reproduced. This asymmetry is the structural source of the construction's witnessing strength. The magnitude of the bare-metal advantage at any given calibration depends on current adversary tooling — generative simulation capability, virtualisation overhead reduction techniques, and the ongoing arms race between sensor fabrication and detection. The existence of the advantage is architectural and does not depend on the calibration. The construction is calibrated to keep the advantage binding at deployment scale; §4–§6 and the *Strategic Cost Calibration Model v1.3* develop the specific calibration. Future instances of the pattern may incorporate alternative witnessing mechanisms — hardware attestation, network-based witnessing, or multi-party witnessing — without disturbing the underlying bare-metal-versus-virtualisation cost asymmetry. The architectural pattern accommodates such variations. ### 3.4 The Threat Model The construction is calibrated against well-resourced operators with access to best-bin commodity server hardware, augmented by custom acceleration where economically justified. State-actor or unbounded-budget adversaries lie outside the current calibration scope. Higher calibration profiles address higher-resourced adversary classes. The primary attack surfaces are: sensor virtualisation under sustained load, addressed by the structural cost of virtualisation overhead and the cross-channel coherence that emerges naturally on physical hardware; pre-computation, addressed by anchor binding; economy-of-scale advantages from bulk hardware acquisition, addressed by the device×time cost structure established in §2.3; and commitment resale or rental — a transferred commitment cannot reproduce its origin device's physical-coupling fingerprint under continued use, and flagging persists across all relationships the commitment has backed, limiting residual value after any flag is issued. Formal threat-model analysis, including bounded adversary classes and the cost function κ, is developed in the *Strategic Cost Calibration Model v1.3*. --- ## 4. Interaction and Verification ### 4.1 The Interaction Loop The fundamental interaction occurs between a *producer* — the party who has constructed a collateral commitment — and a *cosigning party* — any service, platform, or integrator with whom the producer wishes to enter a relationship. A single commitment serves an unbounded number of relationships. It is not consumed by use. The honest user's sunk cost is amortised across every relationship the commitment subsequently serves; an adversary amortises it only across interactions completed before a flag is issued. This structure is what enables direct interaction without continuous third-party verification: the commitment carries its standing intrinsically, the cost is what makes the standing real, and the threat of public marking is what makes the cost binding. These elements are reciprocally constitutive — none is meaningful without the others. Interaction begins when the producer presents the commitment as a pledge of good behaviour. Presentation is local: the producer transmits the *portable proof envelope* (the serialised form of the collateral commitment; see *Orange Anchor Lexicon v2.7*) to the cosigning party, who verifies it independently against Bitcoin's block headers without contacting any third party. Verification confirms that the commitment was produced through the bracketed work described in §3, that it is anchored to specific Bitcoin transactions, and that its public record contains no disqualifying flags under the cosigning party's own policy. Upon successful verification, the cosigning party may *cosign* the commitment by producing a public record that it has accepted the commitment as collateral for the relationship. Cosigning is a signed reference. It does not modify the commitment, transfer custody, or grant the cosigning party any control over the producer's device or future activity. If the producer abuses the relationship under the cosigning party's published policy, the cosigning party may publish a *flag* — an on-chain transaction referencing the commitment — publicly marking it as compromised. Flagging does not seize, transfer, or destroy any value. It produces a permanent public record that future evaluators can see and weigh under their own policy. ### 4.2 Flagging Legitimacy The legitimacy of any flag rests entirely with the signing party and their published policy. No protocol authority sanctions flagging. No consensus mechanism arbitrates its validity. No party has the privilege to revoke another's flag. This structure is **post-authoritative**. Producers self-issue commitments. Cosigning parties self-issue cosigning records. Flagging parties self-issue flags. All records are public, signed, and persistent. The system's overall behaviour emerges from the composition of these records under each evaluator's own policy. A cosigning party who flags a commitment stakes their own reputation on its accuracy. Unjustified flagging makes future producers reluctant to engage, and other cosigning parties may discount their flags accordingly. A producer may publish signed records contesting a flag. These counter-statements are equally visible and weighted under each evaluator's own policy. Some cosigning parties operate under formally published audit methodologies. These open documents specify what counts as abuse, what evidence is required to issue a flag, and what dispute mechanisms apply. These are operator-level commitments, not protocol-level rules. The full methodology framework is specified in the *BAVAI Operator Specification v1.0* and *Orange Pages Audit Methodology v1.0*. ### 4.3 The Verification Model Verification requires only Bitcoin's block headers and the commitment's own internal cryptographic structure. No server, API, or real-time external authority is required. Two complementary paths are available. *Direct verification* checks the portable proof envelope's cryptographic structure against Bitcoin's block headers and any flagging transactions on-chain. This path is fully trustless and offline-capable. *Amortised verification* uses a pre-verified and signed commitment index published by an operator. High-volume verifiers may use this path at the cost of trusting the operator's index honesty — itself auditable through cross-operator comparison and on-chain commitment hashes. Both paths remain available at all times. The choice belongs to the verifier. ### 4.4 Composition With Existing Systems Bitcoin-anchored collateral commitments compose with existing systems as an *economic collateral layer*. A platform adds a verification step at relationship formation and a cosigning step bound to its existing user identifier. No existing infrastructure is displaced. For self-sovereign identity systems, the commitment attaches to an existing DID as a Sybil-resistance attribute without changing the identity model. For Bitcoin-native applications, the full operational footprint — anchoring, cosigning, and flagging — stays within Bitcoin's existing capabilities. No new tokens or chains are required. A platform gains Sybil resistance from the moment it deploys, independently of how many other platforms have adopted the pattern. Cross-platform reuse compounds over time but is not a prerequisite for value. Full integration patterns are in the *Orange Anchor Integration Brief* and the *Orange Anchor Interaction Patterns* document. --- ## 5. Incentives and Economic Asymmetry The honest user's cost is bounded by the marginal cost of running existing hardware for the bracketed window — energy consumed and time foregone. This cost is incurred once, regardless of how many relationships the commitment subsequently serves. For most users, the cost passes unnoticed. The adversary's cost per instance is bounded below by the resources required to perform the bracketed work: sequential elapsed time, sustained memory pressure, energy expenditure, and the witnessing constraints of the construction. The bracketing and device×time structure prevent any parallelisation strategy that would collapse this floor. **The pattern therefore produces a structural economic asymmetry: the cost an adversary must pay to produce N collateral commitments is linear in N.** The ratio between honest-user cost and adversary cost — the κ ratio — is calibrated across profiles and threat models in the *Strategic Cost Calibration Model v1.3*. The argument holds at any calibration: as long as κ exceeds one, the asymmetry exists; as κ rises, it strengthens. *Illustrative calibration (Standard profile, 2026 commodity hardware).* Honest-user cost is bounded by Bitcoin anchor fees executed on already-owned hardware during idle time — the cost of a brief background workload on a device the user has already paid for. Adversary cost per concurrent instance is materially higher by a substantial multiple, combining sustained compute and memory allocation with non-amortisable per-device-model engineering overhead. Full cost analysis, including the most favourable scenario constructed for sophisticated attackers, is developed in the *Strategic Cost Calibration Model v1.3* and its companion *Adversarial Scenario Analysis* (forthcoming). The linearity property holds at any calibration. A structural feature reinforces this asymmetry. Centralisation's traditional advantages — virtualisation, fleet amortisation, and energy economies of scale — work against the attacker for this class of object. Commodity hardware already in service constitutes a vast pool of already-paid-for resource capacity at the edge. A centralised producer seeking to fabricate many instances must acquire equivalent capacity anew, at full marginal cost, per active slot. The construction does not create this asymmetry; it converts it into a verifiable digital object. The current Sybil and bot economy operates at thin margins. Mass account creation, content fabrication, and engagement manipulation are profitable only because the marginal cost per fake instance is near zero — a dynamic the pattern directly disrupts. These operations do not survive linear cost imposition at any meaningful coefficient. **Any positive per-proof cost imposed by the pattern renders most current thin-margin synthetic participation economically irrational.** At population scale, even modest per-proof costs translate into operating expenditures that exceed the total revenue of typical low-margin bot operations. The architectural pattern — bracketed work, memory-hard computation, and cryptographic anchoring to Bitcoin — achieves this regardless of the specific strength of joint coherence. The pattern's core properties are sufficient. The Orange Anchor construction extends this defence into the residual high-value attack surface: the sophisticated operator who would otherwise fabricate sensor data at scale through virtualisation. Joint coherence raises the cost of this class of attack, which represents a small share of current Sybil traffic but a significant share of high-value abuse. This is why the construction invests engineering effort in sensor witnessing. *Standard*, *Hardened*, and *Maximum* calibration profiles raise κ at the cost of modestly higher honest-user effort. A platform deploys at the calibration that defeats its current attack economics and raises calibration as adversary economics shift. This is the same operational posture used in any calibrated cryptographic defence. Formal calibration analysis is provided in the *Strategic Cost Calibration Model v1.3*. Operators who publish audit methodologies and portable indexes provide value-added services without acquiring protocol-level authority. Their value derives from the quality of their published methodology and the reliability of their records. For a platform evaluating adoption, the relevant question is whether the imposed cost exceeds the value currently lost to synthetic participation. At any meaningful calibration, this threshold is reached for most platforms with current Sybil exposure. --- ## 6. Limitations, Implications, and Applications ### 6.1 Honest Limitations The Standard calibration profile requires a 24-hour bracketed window. This latency is incurred once per commitment rather than per interaction. For most use cases — such as accounts created in advance or identity attached to existing wallets — the latency is not user-visible. Bitcoin anchor fees vary with network conditions; fee-sensitivity analysis is provided in the *Strategic Cost Calibration Model v1.3*. The κ ratio is calibrated against current adversary hardware and must be refreshed as hardware improves. The *Strategic Cost Calibration Model v1.3* serves as the canonical reference for calibration evolution. The bare-metal-versus-virtualisation cost ratio is calibrated against current adversary tooling and evolves as that tooling improves. Ongoing measurement of the ratio under realistic adversary conditions is part of the calibration framework. The architectural property — that virtualisation has overhead bare metal does not — does not depend on the calibration. The Orange Anchor construction depends on commodity Android sensor hardware. Platforms with different sensor regimes require adapted instances. The architectural pattern accommodates such adaptations without modification. The construction depends on Bitcoin's continued operation under its current consensus rules. This dependency is stated directly. It is also the source of the construction's durability and neutrality. ### 6.2 Architectural Implications The pattern removes the third-party verification layer from its traditional gatekeeping role. Verification occurs at the edge against Bitcoin. This collapses an infrastructure category that has historically reintroduced centralisation into open systems. Operators continue to provide value through audit methodologies and aggregated indexes, operating as service providers rather than gatekeepers. The aggregate consequences of this shift extend beyond Sybil resistance. Authentication and authorisation traffic — carried by identity providers, certificate authorities, OAuth servers, and similar intermediaries — represents a substantial portion of the communication overhead in current digital infrastructure. Where commitments carry cost-backing intrinsically, two parties verify each other's standing directly against Bitcoin without round-trips to any third party. The verification can occur offline, at the edge, between parties who have never interacted before and may never interact again. The reduction in required communication is a structural consequence of the pattern, not an optimisation layered on top of it. As digital activity becomes increasingly AI-mediated, collateral commitments provide a provenance substrate that does not depend on platform cooperation or the continued operation of any single party. The construction enables composability across systems without requiring an internal economy. A single commitment can serve many relationships, valued differently by different cosigners under their own policies, with no party arbitrating its value. This form of composability was previously achievable only through tokens with internal economies. ### 6.3 Applications Social platforms, content platforms, and community systems facing bot saturation can adopt collateral commitments as an account-creation requirement. The pattern alone is sufficient against the broad market of cheap synthetic participation. Higher calibration profiles address more sophisticated threats. Content production bound to a collateral commitment associates the content with a producer who paid real cost to participate. As AI-generated content proliferates, economic provenance becomes increasingly valuable. Voting, polling, and governance systems facing Sybil pressure gain economic resistance to synthetic participation without centralised voter registration. Calibration profiles can be raised for high-stakes scenarios. Existing authentication and identity systems gain Sybil resistance as an additional layer without architectural disruption. The commitment attaches cleanly to existing user identifiers or DIDs. --- ## 7. Conclusion This paper has presented Bitcoin-anchored resource-bound collateral commitments — an architectural pattern under which self-issued digital objects are produced through real resource commitment, anchored to Bitcoin for permanence, and publicly marked as compromised when linked to abuse. The pattern restores, in digital form, an ancient mechanism in which upfront cost guaranteed good behaviour and broken pledges were publicly marked rather than seized. Applied digitally and underwritten by Bitcoin's permanence and neutrality, it addresses the Sybil problem, the verification-recentralisation problem in self-sovereign identity, and the loss of provenance in AI-mediated content — the same underlying failure framed by different communities — at the architectural layer. The construction's limitations are bounded and acknowledged in §6.1. They constrain the construction's current calibration, not the pattern's claim. The economic argument holds under conservative assumptions about joint coherence: the pattern alone imposes linear cost sufficient to collapse most current bot economics. The Orange Anchor construction extends this defence into the residual high-value virtualisation attack surface. A reference implementation on commodity Android hardware demonstrates that the pattern functions in practice. It provides a foundation for further construction development and for alternative instances under different deployment constraints. The pattern's value is not contingent on the construction's perfection. It is contingent on the construction being sufficient to demonstrate the pattern, on the economic argument being defensible at calibrated scale, and on the resulting commitments being usable in real systems. These conditions are met. The work that remains is the work the pattern was developed to make possible. This paper has carried the architectural argument; the companion documents carry the calibration, mechanism, and formal analysis on which it stands. --- ## References Back, A. (2002). *Hashcash — A Denial of Service Counter-Measure*. Technical report. Boneh, D., Bonneau, J., Bünz, B., & Fisch, B. (2018). Verifiable Delay Functions. In *Advances in Cryptology – CRYPTO 2018*. Douceur, J. R. (2002). The Sybil Attack. In *Peer-to-Peer Systems*. Springer. Percival, C. (2009). *Stronger Key Derivation via Sequential Memory-Hard Functions*. BSDCan. Rivest, R. L., Shamir, A., & Wagner, D. A. (1996). *Time-lock Puzzles and Timed-release Crypto*. Technical Report MIT/LCS/TR-684, MIT. Allen, C. (2016). The Path to Self-Sovereign Identity. *Life With Alacrity* (blog post series). --- ## Companion Documents This paper forms part of a larger suite. The following documents provide additional detail: | Document | Role | |---|---| | *Orange Anchor White Paper v2.3* | Architecture — the complete system overview (upstream) | | *Bitcoin-Anchored Collateral Commitments* (this document) | The BACC pattern and Orange Anchor construction | | *Strategic Cost Calibration Model v1.3* | Cost equations, calibration profiles, and threat model | | *BAVAI Reference v1.0* | Attribution index design and cryptographic structure | | *BAVAI Operator Specification v1.0* | Operator protocol: batching, indexing, flag publication, verification | | *Orange Pages Audit Methodology v1.0* | One operator's audit and scoring framework | | *Orange Anchor Integration Brief v2.2* | Platform integration patterns and guidance | | *Orange Anchor Interaction Patterns v1.0* | Check-in and cosign protocol specification | | *Orange Anchor Widget Technical Specification v0.1* | Embeddable widget for check-in and cosign | | *Orange Anchor Lexicon v2.7* | Vocabulary, conceptual framing, and terminology | | *Orange Anchor Reference Implementation* | Working code on commodity Android hardware | --- *Bitcoin-Anchored Collateral Commitments — A Pattern, Its Construction, and How It Works. Version 1.9, May 2026.*