SORA Cross-Chain Protocol (SCCP) contracts for EVM chains (BSC).

See contracts/ for:

• SccpRouter: burn wrapped ERC-20s to create an on-chain SCCP burn message + messageId
• SccpToken: minimal ERC-20 used as the wrapped representation of a SORA asset
• ISccpVerifier: pluggable on-chain verifier interface (light client / consensus proofs)

mintFromProof is fail-closed until a real verifier contract is configured. Router hardening is also fail-closed for unsupported domains: burn/mint/incident-control calls reject unknown domain IDs.

./scripts/compile.sh

1. Deploy SccpRouter with:
   • localDomain = 2 (BSC)
   • governor = <your on-chain governance address>
2. For each SORA asset_id you want to bridge, deploy/register a wrapped ERC-20:
   • call SccpRouter.deployToken(soraAssetId, name, symbol, decimals)
3. On SORA (runtime pallet sccp):
   • call set_domain_endpoint(SCCP_DOMAIN_BSC, <router address bytes>)
   • call set_remote_token(asset_id, SCCP_DOMAIN_BSC, <token address bytes>)
   • after setting all required domains, call activate_token(asset_id)

Minting on this chain is always driven by SORA finality:

• For SORA -> BSC, SORA burns and commits messageId into its auxiliary digest, and users call:
  • SccpRouter.mintFromProof(DOMAIN_SORA, payload, soraBeefyMmrProof)
• For X -> BSC where X != SORA, SORA must first verify the source-chain burn and commit its messageId into the auxiliary digest (SORA runtime extrinsic sccp.attest_burn). Then users call:
  • SccpRouter.mintFromProof(sourceDomain = X, payload, soraBeefyMmrProof)

SoraBeefyLightClientVerifier enforces:

• >= 2/3 validator signatures for each imported BEEFY commitment
• validator merkle-membership proofs against the stored validator set root
• duplicate signer-key rejection in one commitment proof
• ECDSA signature validity checks (r != 0, s != 0, and low-s)

Inbound proofs from BSC to SORA are finalized on SORA with explicit finality mode:

• default mode: BscLightClient for DOMAIN_BSC
• trustless path: BSC header-chain light client in SORA runtime (bsc_finalized state root + MPT proof)
• optional fallback path: governance can switch to BscLightClientOrAnchor or EvmAnchor and use EVM anchors (set_evm_anchor_mode_enabled + set_evm_inbound_anchor)
• alternative temporary override: AttesterQuorum (CCTP-style threshold ECDSA signatures over messageId)

Default behavior is strict/light-client-first; anchor usage is an explicit governance override.

To encode AttesterQuorum proof bytes for SORA submission:

npm run encode-attester-proof -- --message-id 0x<messageId32> --sig 0x<sig65> --sig 0x<sig65>

Use bridge-relayer to build on-chain proof inputs:

1. Export verifier init sets:
   • sccp evm init
2. Import finalized SORA MMR roots:
   • sccp evm import-root --justification-block <beefy_block>
3. Build mint proof payload for verifyBurnProof / mintFromProof:
   • sccp evm mint-proof --burn-block <burn_block> --beefy-block <beefy_block> --message-id 0x... --abi

--abi returns the exact ABI bytes expected by SoraBeefyLightClientVerifier.verifyBurnProof.