PricingDemo
Log InGet API Key

Blockchain Compatibility Matrix

Document: H33-COMPAT-CHAIN-001
Version: 1.0
Date: 2026-05-22
Status: Current
Editor: Eric Beans, H33.ai, Inc.

1. Scope

This document defines the compatibility status of public blockchain networks for H33 attestation operations. Four operation classes are evaluated per chain: commitment anchoring, proof verification, privacy proofs, and settlement.

Anchoring is the primary chain interaction. The 32-byte SHA3-256 commitment from an H33-74 attestation primitive is published to a target chain, producing an immutable timestamp and public ordering guarantee. The chain itself does not evaluate the commitment; it serves as a timestamping and publication layer.

The security of the attestation does not depend on chain-level signature security. Bitcoin, Ethereum, and Solana use classical ECDSA or EdDSA for transaction signing. Even if these classical signatures are broken by a quantum adversary, the 32-byte commitment and the three post-quantum signatures over the full receipt remain valid.

2. Operation Classes

Anchoring
Publishing the 32-byte commitment to the target chain. The commitment is embedded in a chain-specific data field (OP_RETURN, calldata, memo, etc.). Once confirmed, the commitment inherits the chain's finality guarantees.
Proof Verification
On-chain or off-chain verification of STARK or PLONK proofs generated by the H33 ZKP subsystem. Where the chain supports a verification precompile or programmable verification, proofs can be verified without external dependencies.
Privacy Proofs
Publishing or verifying zero-knowledge proofs that attest to properties of encrypted data without revealing the data itself. Requires chain support for ZK-friendly operations or sufficient calldata capacity for proof publication.
Settlement
Using the chain as a final settlement layer for tokenized attestation receipts, payment attestations (wire proofs), or governance decisions. Requires chain support for programmable logic or token standards.

3. Status Designations

Supported
Production-deployed. The integration is tested, monitored, and available to all tenants.
In Progress
Implementation is active. Code exists in a development branch with passing tests. Not yet deployed to production.
Planned
Committed to the roadmap. Design is specified but implementation has not started.
N/A
The operation class is not applicable to this chain due to architectural constraints (e.g., the chain lacks programmable execution).

4. Primary Compatibility Matrix

ChainAnchoringProof VerificationPrivacy ProofsSettlement
Bitcoin Supported N/A N/A N/A
Ethereum Supported Supported Supported Supported
Solana Supported In Progress Planned In Progress
Base Supported Supported Supported In Progress
Arbitrum Supported Supported Supported In Progress
Optimism Supported Supported In Progress Planned
Avalanche In Progress Planned Planned Planned
Polygon Supported Supported In Progress Planned
Zcash Planned Planned Planned N/A

5. Anchoring Methods by Chain

Each supported chain uses a different mechanism to embed the 32-byte commitment. The anchoring method determines the gas cost, finality time, and data availability guarantees.

ChainAnchoring MethodData FieldCommitment SizeFinalityTypical Cost
Bitcoin Taproot witness (BIP-341) Witness script data push 32 bytes ~6 blocks (~60 min) ~$0.10 - $2.00
Ethereum Contract calldata bytes32 parameter 32 bytes ~2 epochs (~12.8 min) ~$0.50 - $5.00
Solana Memo program SPL Memo instruction data 32 bytes ~1 slot (~0.4 sec) ~$0.001
Base L2 calldata bytes32 parameter 32 bytes L2 ~2 sec / L1 ~12.8 min ~$0.01 - $0.10
Arbitrum L2 calldata bytes32 parameter 32 bytes L2 ~0.25 sec / L1 ~12.8 min ~$0.01 - $0.10
Optimism L2 calldata bytes32 parameter 32 bytes L2 ~2 sec / L1 ~12.8 min ~$0.01 - $0.10
Avalanche C-Chain calldata bytes32 parameter 32 bytes ~2 sec ~$0.02 - $0.20
Polygon PoS calldata bytes32 parameter 32 bytes ~2 sec / checkpoint ~30 min ~$0.005 - $0.05
Zcash Memo field (planned) Shielded memo 32 bytes ~10 blocks (~12.5 min) ~$0.01

6. Chain Target Identifiers

The chain_target field at byte offset 35 of the H33-74 primitive encodes the target chain as a single byte. The following values are assigned:

ValueChainStatus
0x00UnanchoredReserved
0x01BitcoinAssigned
0x02SolanaAssigned
0x03EthereumAssigned
0x04ArbitrumAssigned
0x05OptimismAssigned
0x06BaseAssigned
0x07PolygonAssigned
0x08AvalancheReserved
0x09ZcashReserved
0x0A-0xFFUnassignedReserved for future use

7. Batched Anchoring

To reduce per-attestation chain costs, H33 supports batched Merkle root anchoring. Multiple H33-74 commitments are collected over a configurable window (default: 60 seconds), organized into a Merkle tree, and the Merkle root is anchored as a single on-chain commitment.

Individual attestation primitives retain their per-attestation commitment values. The Merkle tree structure allows any individual commitment to be verified against the on-chain root using a standard inclusion proof. This approach reduces anchoring costs by a factor equal to the batch size while preserving per-attestation verifiability.

Batched anchoring is the default for all chains except Bitcoin, where individual Taproot-based anchoring is used for high-value attestations. Bitcoin batched anchoring (using OP_RETURN for the Merkle root) is available as a configuration option for cost-sensitive workloads.

Batched Merkle response attestation is covered by H33 substrate patent Claims 124-125, FIG 40-45.

8. Finality and Reorganization

Chain finality determines when an anchored commitment can be considered permanent. H33 applies chain-specific confirmation thresholds before marking an attestation as chain-finalized:

ChainConfirmation ThresholdApproximate TimeReorganization Risk
Bitcoin6 blocks60 minutesNegligible at 6 confirmations
Ethereum2 epochs (finalized)12.8 minutesNone post-finality (Casper FFG)
Solana31 slots (rooted)~12.4 secondsNone post-root
Base / Arbitrum / OptimismL1 finality12.8 minutes (L1)L2 sequencer reorgs possible pre-L1
PolygonCheckpoint~30 minutesNone post-checkpoint
Avalanche1 accepted~2 secondsNone (Snowman consensus)

Attestations are queryable immediately upon chain submission. The chain_finalized flag in the attestation receipt is updated asynchronously once the confirmation threshold is met.