Engineering Roadmap Bitcoin SPV

Engineering Roadmap: Bitcoin SPV on Zenon

Status: Exploratory / Research Draft

Overview

This document outlines a phased engineering approach for implementing Bitcoin SPV verification on Zenon. Each phase is designed to be independently useful while building toward a complete cross-chain verification system.

Design Principles

1. Incremental Value: Each phase delivers usable functionality
2. Safety First: Start with isolated verification, add global scope later
3. Optionality: Users/accounts opt-in; no forced adoption
4. Correctness Before Liveness: Get verification right before optimizing

Phase 0: Foundation

Goal

Establish the cryptographic and specification foundation.

Deliverables

• Bitcoin SPV verifier specification (platform-agnostic)
• Test vector suite (conformance testing)
• Threat model documentation
• Reference implementation (any language)

Success Criteria

• Specification is complete and unambiguous
• Test vectors cover all edge cases
• Reference implementation passes all tests
• Security review of specification

Dependencies

None (foundational)

Estimated Effort

4-8 weeks

Phase 1: Account-Level Verification

Goal

Enable individual accounts to verify Bitcoin proofs locally.

Deliverables

• VerifyBitcoinSPV ACI (Application Contract Interface)
• Account-chain state extension for Bitcoin facts
• Plasma cost model for verification
• SDK integration (TypeScript, Go)

Architecture

Account submits: SPVProof
Account verifies: Locally (costs Plasma)
Account state:   Records verified fact
Momentum:        Checkpoints account state (does NOT re-verify)

Success Criteria

• Accounts can verify Bitcoin proofs
• Verified facts persist in account state
• Other accounts can read verified facts
• Verification cost is predictable and bounded

Dependencies

Phase 0 complete

Estimated Effort

6-10 weeks

Phase 2: Header Networking

Goal

Establish reliable Bitcoin header distribution across the network.

Deliverables

• Header relay protocol specification
• P2P header gossip implementation
• Threshold tip acceptance logic
• Eclipse resistance mechanisms

Architecture

Sources:     Bitcoin nodes, relay services
Distribution: P2P gossip among Zenon nodes
Consensus:   Threshold agreement on tip (k-of-n sources)
Storage:     Local header cache per node

Success Criteria

• Nodes can obtain Bitcoin headers without running Bitcoin
• No single source can eclipse a node
• Header availability > 99.9%
• Tip latency < 5 minutes from Bitcoin

Dependencies

Phase 1 complete (for verification interface)

Estimated Effort

8-12 weeks

Phase 3: Optimistic Checkpointing

Goal

Enable globally visible Bitcoin facts with fraud proof protection.

Deliverables

• Bitcoin fact checkpoint submission
• Challenge/fraud proof mechanism
• Bond and slashing logic
• Checkpoint finalization protocol

Architecture

Submitter:   Posts checkpoint + bond
Window:      Challenge period (e.g., 1000 Momentums)
Challenger:  Can submit fraud proof
Resolution:  Fraud proven -> submitter slashed
             No fraud -> checkpoint finalized

Success Criteria

• Valid checkpoints finalize after window
• Invalid checkpoints are challenged and rejected
• Economic incentives align participants
• No false positives (valid checkpoints rejected)

Dependencies

Phase 2 complete (for header availability)

Estimated Effort

10-14 weeks

Phase 4: Incentive Layer

Goal

Establish sustainable economics for header relay and checkpoint submission.

Deliverables

• Bonded relayer model
• Fee market for services
• Service credits system
• Reputation tracking

Architecture

Relayers:    Stake bond, provide headers, earn fees
Submitters:  Pay for checkpoint inclusion
Market:      Fee discovery based on demand
Reputation:  Track accuracy, uptime, reliability

Success Criteria

• Header relay is economically sustainable
• Checkpoint submission has clear fee model
• Bad actors are identified and penalized
• Good actors are rewarded

Dependencies

Phase 3 complete (for checkpoint mechanism)

Estimated Effort

8-12 weeks

Phase 5: Protocol Integration (Optional)

Goal

Assess whether Bitcoin SPV should become ledger-native.

Deliverables

• Integration assessment document
• Governance proposal (if proceeding)
• Testnet validation
• Mainnet activation (if approved)

Decision Criteria

• Is Phase 4 insufficient for demand?
• What’s the risk/reward of protocol integration?
• Is there community consensus?

Note

This phase may never happen. Phases 0-4 may be sufficient for all practical use cases.

Dependencies

Phase 4 stable for 6+ months

Estimated Effort

Variable (depends on scope)

Timeline Overview

Total estimated time to full functionality: 9-14 months

Risk Assessment

Technical Risks

Operational Risks

Governance Risks

Success Metrics

Phase 0

• Specification completeness: 100%
• Test coverage: >95%
• External review: Completed

Phase 1

• Verification success rate: >99.9%
• Average verification time: <100ms
• Plasma cost predictability: <10% variance

Phase 2

• Header availability: >99.9%
• Eclipse incidents: 0
• Tip latency: <5 minutes

Phase 3

• Checkpoint finalization rate: >99%
• False challenge rate: <1%
• Average finalization time: On schedule

Phase 4

• Relayer count: >10 independent operators
• Service uptime: >99%
• Fee stability: Predictable within 2x

Open Questions

Each phase should address these questions before completion:

1. What can go wrong? (Failure modes)
2. How do we detect it? (Monitoring)
3. How do we recover? (Incident response)
4. What did we learn? (Retrospective)

Conclusion

This roadmap provides a structured path from cryptographic feasibility to production-ready Bitcoin integration. The phased approach allows:

• Early value delivery (Phase 1)
• Iterative improvement based on real usage
• Clear decision points for protocol integration
• Risk mitigation through incremental rollout

The goal is not to ship everything at once, but to ship each phase well.

Document Status: Planning Document Last Updated: Draft