Skip to main content

Motivation: Reimagining Validators as Service Providers

Traditional blockchains externalize real-world interaction into separate systems:
  • Oracles fetch prices and submit them on-chain
  • Bridges lock assets on one chain and mint on another
  • Payment processors handle fiat through custodial rails
  • API relayers call external services and hope you trust them
These components sit outside consensus. They operate on reputation, multisigs, and “trust us” security models. DracoBFT treats validators not just as block producers, but as financial access points. Validators can opt in as permissioned service providers, integrating with on/off-ramps, banking partners, FX platforms, and card programs. Using zkTLS and auxiliary proof loops, validators prove to the chain that a given user has a verified account, balances, and status at providers like Bridge, Avenia, Brale, and others without leaking private keys or raw API credentials. Side-loops also enable Hotstuff L1 to tap external CeFi + DeFi venues, enabling a wide range of use-cases via async flows. The consensus layer does not just finalize blocks; it finalizes onboarding and money movement for end users as well as provides access to deep off-chain stablecoin liquidity.

Auxiliary Verification Loops

DracoBFT processes external operations in parallel with consensus through a modular global event management system.

Bird’s eye view for Aux Side loops

  1. Proof Collection: Collect external action proofs - zkTLS or zk execution proofs
  2. Verification: Verify proofs using appropriate verifier, generate verification certificate.
  3. Consensus integration: verified side-loop ops are packaged as actions by validators and submitted to mempool.
  4. Finalization: On block finalization, apply state transition atomically.

Trustless Verification Architecture

Offchain actions via zkTLS proofs

For public or private API calls to external services, DracoBFT leverages zero-knowledge Transport Layer Security (zkTLS) proofs. These proofs provide cryptographic verification of HTTPS responses without requiring the external service to be aware of the blockchain. Validators can verify:
  • The response came from the claimed server (via TLS certificate chain).
  • The response content matches specific claims (via ZK proof).
  • The data was not tampered with (via server signature).
This enables trustless integration of traditional APIs including asset price feeds, identity verification services, and any HTTPS endpoint.

zk Execution Proofs for On-Chain State

For verification of state or events on other blockchains (for example, Ethereum):
  1. zkTLS-based RPC proofs: Efficient verification (under 100ms generation, under 10ms verification) with RPC provider trust.
  2. Zero-knowledge execution proofs: Full trustlessness via recursive block header and state verification.