One API, Three Chains: Inside Anchora's Multi-Chain Architecture

The problem with picking one chain

Every blockchain anchoring service makes the same opinionated choice: pick one chain. Pick a public chain (Polygon, Ethereum, Bitcoin) and you get cheap public verifiability — great for SaaS, marketplaces, and AI-content provenance. Pick a private chain (Fabric, Quorum, Besu) and you get data sovereignty — required for banking, healthcare, defense.

The catch is that regulated industries usually need both:

• An internal audit trail on a network they control (Fabric)
• An externally verifiable proof that auditors, regulators, or end users can check without network access (Polygon)

Building this yourself means running two anchoring stacks, two verification flows, two retry queues, and two webhook receivers — for every record. We thought we could do better.

The four strategies

Anchora now supports four anchoring strategies. The strategy is a Settings flag on the project — switch it without changing your code:

1. Public — Polygon (default)

Anchors to Polygon Amoy or Mainnet. Anyone can verify on Polygonscan. ~$0.000007 per record after Merkle batching (256 records per on-chain transaction). Best for SaaS, AI provenance, public attestations.

2. Private — Hyperledger Fabric (BYO)

Bring your own Fabric network — peers, orderer, CA. Anchora deploys the anchora-anchor chaincode on your channel, authenticates with your X.509 identity, and starts anchoring. No gas. Data never leaves your network. Best for banking, healthcare, regulated consortiums.

3. Hybrid — Both at once

The same Merkle root committed to your Fabric AND a public chain (Polygon by default) in one batching pass. The webhook carries both anchors. /v1/verify returns independent verdicts for each chain. Best for any workflow that needs internal control AND external verifiability.

4. Custom — Any EVM RPC, any Fabric profile

Manual override: Besu, Quorum, Ethereum Mainnet, custom Fabric MSP. For consortiums and bespoke deployments.

The hard part: keeping the API stable

We had a constraint we refused to break: existing customers see zero changes. Their API calls keep working. Their webhook receivers keep parsing the same fields. Their SDK keeps the same types.

So we made the chain decision a project-level setting, not a request-level field. POST /v1/anchor looks identical for Public, Private, and Hybrid customers:

curl -X POST https://api.anchora.co.in/v1/anchor \
  -H "Authorization: Bearer dcp_live_..." \
  -H "X-Project-Id: <projectId>" \
  -H "Content-Type: application/json" \
  -d '{
    "data": { "orderId": "ORD-001" },
    "hashOnly": true,
    "webhookUrl": "https://your-app.com/anchora-webhook"
  }'

What's different is what comes back. Webhook + verify responses now carry chain provenance — additive fields, not replacements:

{
  "type": "ANCHORED",
  "hash": "63e33ef9...",
  "chainType": "fabric",        // NEW
  "networkId": "fabric-byo",    // NEW
  "blockNumber": null,           // always null for Fabric
  "transactionHash": "95cfed3ad9...",  // raw txID, no 0x
  "batchId": "7",                // string for Fabric
  "merkleProof": ["0x70bdd5..."]
}

EVM-only receivers that ignore chainType / networkId keep working. Fabric receivers branch on chainType === 'fabric'. Hybrid receivers also see a dualAnchor sub-object with the secondary chain's data.

The hardest part: dual-anchor reliability

Hybrid is where the engineering gets interesting. You have two chains that can fail independently. What happens if Fabric commits but the Polygon RPC times out? What if the secondary chain comes back 30 minutes later? What does /v1/verify say in the meantime?

We made three guarantees:

1. Primary stands alone. A Hybrid record is valid the moment the primary chain (Fabric, by default) confirms. The secondary is a bonus, not a blocker.
2. Automatic back-fill. If the secondary fails at batch time, the worker retries hourly up to 5 attempts. On success it back-fills record.dualAnchor and delivers a webhook with the complete shape.
3. Independent verification. /v1/verify returns separate verified verdicts for primary and dualAnchor. verified: null with a reason means "couldn't check — not tampering."

What unlocked

Multi-chain unlocks ~3x our addressable market. Before, prospects in regulated industries told us "we love the API, we can't use a public chain." Now they pick Hybrid, anchor their internal records to Fabric, and get a Polygon proof for external use as a side effect.

Concrete patterns the architecture is designed for:

• Banks anchoring loan documents to Fabric (internal audit), with a Polygon proof handed to the borrower as a verification link
• Pharma companies anchoring clinical-trial submissions to Fabric (sponsor + CRO), with a Polygon proof for FDA inspection
• Government agencies anchoring property records to Fabric (inter-agency), with a Polygon proof for citizen / FOIA verification

What's next

Multi-chain Core is shipped. Managed Fabric (we host the Fabric network, you skip the Docker/MSP setup) is the next major release. After that: Consortium Mode — multi-org shared Fabric networks for supply chains and regulator-supervised industries.

If you're evaluating Anchora for a regulated workload, the Anchoring Strategies guide walks through the decision tree. Or jump straight to the Fabric Setup guide if you already know you want Private or Hybrid.