Blockchain Compatibility Matrix

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 a tamper-evident, independently re-verifiable timestamp and public ordering guarantee. The chain itself does not evaluate the commitment; it serves as a timestamping and publication layer. The commitment and its post-quantum signatures re-verify offline against the primitive's schema and hash, trusting no chain.

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

Chain	Anchoring	Proof Verification	Privacy Proofs	Settlement
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.

Chain	Anchoring Method	Data Field	Commitment Size	Finality	Typical 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:

Value	Chain	Status
0x00	Unanchored	Reserved
0x01	Bitcoin	Assigned
0x02	Solana	Assigned
0x03	Ethereum	Assigned
0x04	Arbitrum	Assigned
0x05	Optimism	Assigned
0x06	Base	Assigned
0x07	Polygon	Assigned
0x08	Avalanche	Reserved
0x09	Zcash	Reserved
0x0A-0xFF	Unassigned	Reserved 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.

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:

Chain	Confirmation Threshold	Approximate Time	Reorganization Risk
Bitcoin	6 blocks	60 minutes	Negligible at 6 confirmations
Ethereum	2 epochs (finalized)	12.8 minutes	None post-finality (Casper FFG)
Solana	31 slots (rooted)	~12.4 seconds	None post-root
Base / Arbitrum / Optimism	L1 finality	12.8 minutes (L1)	L2 sequencer reorgs possible pre-L1
Polygon	Checkpoint	~30 minutes	None post-checkpoint
Avalanche	1 accepted	~2 seconds	None (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.

9. Choosing an Anchor Chain

Because the H33-74 primitive is chain-agnostic, the anchor chain is an operational choice, not an architectural dependency. Select by the trust, cost, and finality profile you need:

Anchor to Bitcoin

When you need the most widely recognized, long-horizon public timestamp for high-value attestations. Taproot (BIP-341) witness anchoring; slower finality, higher cost.

Anchor to Ethereum

When you need the broadest verifiable-settlement ecosystem plus on-chain proof-verification and privacy-proof support (see the matrix in §4).

Anchor to an L2 or Solana

When cost and throughput dominate — Base, Arbitrum, Optimism, Polygon, or Solana give sub-second-to-seconds finality at a fraction of L1 cost. Best paired with batched Merkle anchoring (§7).

Anchor to more than one chain

When you want a migration hedge or multi-jurisdiction recognition. The same 74-byte primitive anchors independently to each chain; every anchor re-verifies on its own.

Do not anchor to a public chain

When a public ordered timestamp is not required. The evidence still re-verifies offline against schema and hash, so an internal database, archival store, or regulator ledger can serve as the anchor surface. Anchoring adds public timestamping; it is optional.

10. Frequently Asked Questions

Does the blockchain own or verify the H33 evidence?

No. The chain is a timestamping and publication layer only; it does not evaluate the commitment. Even if a chain's classical ECDSA/EdDSA is broken by a quantum adversary, the 32-byte commitment and the three post-quantum signatures over the receipt remain valid. Rendering the verdict on the evidence is H33 Verification — the chain is not the verifier, and it is not the owner or producer of the evidence (H33-74 is).

Does H33 depend on any single chain?

No. The H33-74 primitive is chain-agnostic. The same commitment can be anchored to Bitcoin, Ethereum, an L2, or none, and re-verifies offline. If a chain is deprecated the evidence survives and can be re-anchored — the evidence never depends on a particular chain remaining operational.

Is anchoring the same as governance?

No. Anchoring binds evidence to a public timestamp. Deciding who is authorized to act — the governance decision — is Agent-008, a separate layer. This matrix concerns only where evidence anchors, not who may produce it.

Which anchoring mechanisms does H33 use, and did H33 invent them?

H33 uses each chain's native mechanism — Taproot on Bitcoin, calldata on EVM chains, the memo program on Solana. These mechanisms, like the underlying cryptographic primitives (SHA3, ML-DSA, SLH-DSA), are external standards H33 uses and verifies against; H33 does not own or claim to have invented them.