HashPledge

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

Inspiration

What it does

How we built it

Challenges we ran into

Accomplishments that we're proud of

What we learned

What's next for HashPledge

Inspiration

Bitcoin is excellent at final settlement, but it lacks a native way to express and verify “credible near-term inclusion” before a transaction lands in a block. Existing solutions either rely on trust, opaque intermediaries, or require consensus changes. HashPledge explores an application-layer alternative: cryptographic preconfirmation receipts anchored to observed chain state.

What it does

HashPledge issues preconfirmation receipts: a miner (simulated) signs a domain-separated commitment to include a specific Bitcoin transaction within a fixed validity window. Each receipt is:

Independently verifiable (canonical message format + SHA256 commitment + secp256k1 signature)

Anchored to chain tip state (best block hash + height)

Outcome-auditable with explicit states:

fulfilled (included on-chain)

violated (expired without inclusion)

equivocated (double-pledge detected)

anchor-reorged (receipt invalid on current tip)

How we built it

Regtest Bitcoin Core provides deterministic chain control (mining, block invalidation).

A FastAPI backend builds/signs transactions, issues receipts, persists state in SQLite, and enforces bond accounting.

A React + TypeScript UI drives five deterministic scenarios (success, failure, equivocation, reorg, capacity exhaustion) using only data-testid selectors for testability.

A CLI verifier validates receipts offline by reconstructing message bytes, checking signature correctness, and evaluating anchor/inclusion semantics.

Protocol highlights

Domain-separated, deterministic receipt encoding to avoid JSON ambiguity.

UTXO fingerprinting to detect miner equivocation (two live receipts pledging conflicting spends).

Reorg-aware anchoring: if the anchor block is not on the active chain tip, the receipt is downgraded (invalid-on-this-tip) and the bond is neutralized (released, not slashed).

Bond capacity: miners have finite capacity; issuance is refused with a structured error when capacity is insufficient.

Auditability and determinism

This project is built around a strict “proof or it doesn’t exist” model:

No skipped tests, no retries.

Deterministic runs (fixed clock + seeded behavior).

Every milestone generates an artifact proof pack containing test reports, screenshots, videos/traces, logs, and a machine-readable manifest.

Challenges

Making E2E fully reproducible without hidden dependencies (bitcoind lifecycle, backend readiness, preview server coordination).

Ensuring deterministic outputs despite time/chain state changes.

Designing economics that are meaningful for a demo without pretending to be consensus-enforced.

What we learned

Preconfirmations are fundamentally about credible commitment and failure detectability, not UI polish.

Reorgs and equivocation are first-class failure modes that must be explicit in both protocol semantics and verification tooling.

Reproducibility is a competitive advantage: judges can verify claims quickly.

What’s next

Replace the demo-only bond ledger with a real collateral mechanism.

Add policy-aware inclusion commitments (fee-rate constraints, package semantics).

Explore interoperability with miner-side signaling and mempool relay policies.

Built With

• bitcoin-core-(regtest
• demo
• deterministic
• fastapi
• jq
• json-rpc)-python
• typescript
• uvicorn-sqlite-secp256k1-ecdsa-(coincurve-or-equivalent)-react
• vite-playwright-(e2e-+-evidence-capture)-docker-/-docker-compose-bash