BAN is designed as a post-quantum operating layer anchored to Bitcoin. The system is meant to support replayable receipts, verifiable credentials, secure coordination, and verified work on infrastructure operators can run themselves.
This brief focuses on policy alignment and pilot framing rather than consensus internals. For the deeper protocol discussion, use the technical whitepaper.
Important notice. This partner brief is informational only and is intended for discussion, evaluation, and planning. It is not legal, financial, tax, or investment advice, and it is not an offer, solicitation, procurement commitment, or deposit invitation. Public deposits remain disabled, and any rollout, pilot, or product availability is subject to legal, technical, operational, and policy readiness.
The Bitcoin Attestation NetworkTM is a Bitcoin-anchored, post-quantum infrastructure stack designed for durable evidence. In practice, that means signed receipts, verifiable credentials, replayable audit trails, secure local-first tooling, and user-run infrastructure that can be inspected instead of merely trusted.
This partner brief focuses on the public-policy and deployment side of the system: why state-level legal clarity matters, how BAN maps onto Utah's current framework, and what a bounded pilot could look like for identity, records, or secure coordination.
State-level legal clarity has become one of the strongest predictors of real infrastructure adoption. When node operation, self-custody, software development, and digital identity have a clearer legal lane, builders can spend more time on working systems and less time interpreting ambiguity.
Utah has become one of the clearest examples of that approach. Its current posture combines blockchain protections, digital identity legislation, and AI disclosure expectations in a way that lines up with BAN's architecture more naturally than a generic crypto framework would.
BAN is designed to turn important events into signed, replayable records instead of relying on screenshots, private dashboards, or mutable platform logs.
The stack is designed around ML-DSA-65 signatures and device-controlled identity, which fits credential and verifier workflows that need long-horizon trust.
Wallet, AI, mesh, and operator tooling are intended to run on user-controlled infrastructure, reducing dependence on opaque third-party service accounts.
| Utah Law | Enacted | Effective | BAN Alignment |
|---|---|---|---|
| HB 230 - Blockchain and Digital Innovation | 2025 | May 7, 2025 | Protects node operation, mining, self-custody, and software development. BAN's Proof of Knowledge mining is designed for broad hardware participation, which turns legal permission into practical access. |
| SB 260 - State-Endorsed Digital Identity (SEDI) | 2025 | May 7, 2025 | Supports device-based credentials, selective disclosure, and anti-surveillance principles. BAN's attestation and wallet model is designed around those primitives. |
| SB 275 - SEDI Implementation | 2026 | May 6, 2026 | Sets operational rules for identity proofing, wallet providers, verifiers, and presentation modes. BAN's wallet, attestations, and post-quantum identity stack map closely to those workflows. |
| SB 149 - AI Policy Act (AIPA) | 2024 | May 1, 2024 | Establishes AI disclosure and transparency expectations. ElliottTM is designed to identify itself as AI, run locally, and rely on auditable sources. |
BAN is designed around attestations rather than opaque database assertions. That matters for credentials, records, and machine-generated outputs because it creates a cleaner evidence trail. A party can issue a claim, sign it, anchor it, and later prove what was said without relying on a centralized intermediary to remain available.
That design is especially relevant when a workflow needs selective disclosure, auditability, offline recovery, or a durable chain of evidence. The system is not framed as a speculative asset product here; it is framed as infrastructure for verifiable records and operator-controlled tools.
| Step | Who Acts | What Happens |
|---|---|---|
| 1. Issuance | State agency, employer, or university | Creates an AttestoTM containing credential claims and signs it with ML-DSA-65. |
| 2. Consensus | Network attestors | The attestation is validated by nodes and included in a Memory BlockTM. |
| 3. Bitcoin anchor | Automated | The Memory Block hash is anchored to Bitcoin for an additional public settlement reference. |
| 4. Storage | Credential holder | The credential remains in the holder's wallet on their own device. |
| 5. Presentation | Credential holder | The holder presents only the claim needed, supporting selective disclosure. |
| 6. Verification | Verifier | The verifier checks the signature and proof path against BAN records without needing live issuer contact. |
When states or institutions ask how to pilot post-quantum digital identity, replayable receipts, or local-first operator infrastructure, the most useful answer is not a slide deck. It is a working reference implementation with bounded scope, clear operator controls, and auditable outputs.
Pilot issuance and verification flows for workforce credentials, institutional records, or membership proofs with selective disclosure.
Record important workflow events as signed receipts so the review process can replay what happened instead of relying on mutable back-office logs.
Use local-first wallet, mesh, and operator tools to test how a team can coordinate with durable evidence and less dependence on centralized service layers.
| Phase | Timing | What Happens |
|---|---|---|
| Discovery | Weeks 1-2 | Choose a bounded use case such as workforce credentialing, secure records, digital identity, or auditable coordination. |
| Technical setup | Weeks 3-6 | Deploy pilot nodes, configure wallet and operator flows, and test issuance and verification end to end. |
| Validation | Weeks 7-10 | Exercise selective disclosure, operator controls, audit trails, and handoff workflows under realistic conditions. |
| Report | Weeks 11-12 | Document findings, policy fit, operational lessons, and recommended next steps. |
Want the protocol details? Read the Technical Whitepaper for consensus, cryptography, transport, and architecture.
Want the broader product context? Start with the Overview Paper, review the Utah background, or contact info@bitcoinattestationnetwork.org.
Contact: info@bitcoinattestationnetwork.org
Legal: This partner brief may be updated without notice. It is provided for discussion purposes only and does not create contractual rights. Public deposits remain disabled until legal and technical readiness requirements are complete.