Inter-chain audit

(Section: Ecosystem and Network)

1) Goals and scope

• Confirm the correctness and completeness of the records, taking into account the finalization and reorgs.
• Ensure the provability of decisions and transactions (crypto signatures, commercial proofs, ZK/optimistic models).
• Give a lineage from report to raw event.
• Reduce operational and regulatory risk through standardized journals and procedures.

2) Sources of truth and model of trust

On-chain states and logs: blocks, contract events, message packet hashes.
Bridges and trailers: applications, receipts, evidence (light-client/optimistic/ZK).
PSP/KYC/AML: check statuses, payment receipts, sanction hits.
Operating systems: configs, feature flags, SDK versions, limits, keys.
Governances/solutions: proposals, timelock, execution.

Trust levels: cryptographically verified → economically finalized → operationally certified (by signature and unchangeable log).

3) Finalization, reorgs and provability statuses

• `observed → confirmed(K) → finalized → challenged (optimistic) → invalidated(reorg)`

• K-confirmations per chain/asset/risk class.
• Challenge window for optimistic bridges.
• Delayed Finalization for large amounts/critical activities.
• Reorg handling: automatic disability/re-replay with reference to an old hash.

4) Immutable logs and hash chains

Audit-log (append-only): record = (time, source, payload-hash, signatures).

5) End-to-end lineage data

• Column-level lineage: from showcase/report to transformations and raw event.

6) Control of bridge and domain configurations

Register of bridges/vapor chains: chainId, type of evidence, K-confirmations/dispute window, contract addresses, decimals/asset-map.
SDK/agent versions: minimally supported, LTS, traffic share by version.
Keys and roles: org_id → peer_id → capability, terms and rotation.
ACL/limits: rate-limits, daily volumes, whitelist assets/methods.

7) Proof Stack

Log-proofs: source signatures + hash chains/anchors.
State-proofs: light-client/checking headers + merkle-branches.
Execution-proofs: ZK proofs of calculation correctness (if available).
Optimistic-proofs: true until challenged (challenge period, steak, umpires).
Receipt-pairing: proof-of-delivery/-execution.

8) SLI/SLO of inter-chain audit

• Freshness p95 (min) from 'observed _ at' to hit Gold.
• Completeness (%) vs expected by K-windows.
• Correctness (%) (scheme validations, signatures, proofs).
• Proof-Coverage (%) - the share of records with crypto evidence.
• Reorg Handling Success (%).
• Config Drift Detection MTTA (мин).

SLO: Freshness ≤ 15 min (batch )/ ≤ 3 min (stream), Completeness ≥ 99. 7%, Correctness ≥ 99. 9%, Proof-Coverage ≥ 99. 0%, Reorg Success ≥ 99. 9%, MTTA drift ≤ 5 min.

9) Data schemas (pseudo-SQL)

Register of events/translations

sql
CREATE TABLE xchain_events (
id TEXT PRIMARY KEY,
observed_at TIMESTAMPTZ,
status TEXT,         -- observed    confirmed    finalized    challenged    invalidated chain_id TEXT, block_height BIGINT, tx_hash TEXT, log_index INT,
type TEXT,          -- bridge.lock    bridge.mint    transfer    kyc.pass...
actor_src TEXT, actor_dst TEXT,
asset TEXT, amount NUMERIC, usd_value NUMERIC,
bridge_ref TEXT, idempotency_key TEXT,
proof_ref TEXT
);

Proofs

sql
CREATE TABLE proofs (
id TEXT PRIMARY KEY,
kind TEXT,          -- log    state    zk    optimistic root_hash TEXT, leaf_hash TEXT, proof JSONB,
anchored_chain TEXT, anchor_tx TEXT,
created_at TIMESTAMPTZ
);

Unmodifiable Audit Log

sql
CREATE TABLE audit_log (
seq BIGSERIAL PRIMARY KEY,
ts TIMESTAMPTZ,
source TEXT, record_hash TEXT, prev_hash TEXT,
sig_org TEXT, sig_payload TEXT
);

Bridge/Config Register

sql
CREATE TABLE bridge_registry (
pair_id TEXT PRIMARY KEY,
src_chain TEXT, dst_chain TEXT,
proof_mode TEXT, confirmations INT, challenge_minutes INT,
contracts JSONB, assets_map JSONB, sdk_min TEXT, lts TEXT,
updated_at TIMESTAMPTZ, updated_by TEXT
);

10) Report integrity control (pseudo requests)

Compare Report to Profs

sql
SELECT r.report_id, COUNT() AS rows,
100.0 SUM(CASE WHEN e.proof_ref IS NOT NULL THEN 1 ELSE 0 END) / COUNT() AS proof_coverage_pct
FROM report_rows r
JOIN xchain_events e ON r.event_id = e.id
GROUP BY r.report_id;

Detect configuration drift

sql
SELECT pair_id, COUNT() AS changes_24h
FROM config_audit
WHERE ts >= now() - INTERVAL '24 hours'
GROUP BY pair_id
HAVING COUNT() > 0;

Reorg analysis

sql
SELECT chain_id, date_trunc('hour', observed_at) AS h,
SUM(CASE WHEN status='invalidated' THEN 1 ELSE 0 END) AS reorg_cnt
FROM xchain_events
WHERE observed_at >= now() - INTERVAL '7 days'
GROUP BY chain_id, h;

11) Configurations (pseudo-YAML)

Finishing windows and proof modes

yaml finality:
eth-mainnet: { k: 12, proof: light_client }
polygon:   { k: 256, proof: light_client }
solana:   { k: "optimistic:32 slots", proof: optimistic, challenge_minutes: 20 }
zk-bridge:  { proof: zk, sla_proof_sec: 180 }

Quality audit parameters

yaml audit:
freshness_p95_min: 3 completeness_min_pct: 99.7 correctness_min_pct: 99.9 proof_coverage_min_pct: 99.0 drift_mtta_min: 5

Anchoring policy

yaml anchoring:
cadence: "15m"
chains: ["eth-mainnet"]
anchor_contract: "0xANCh..."

12) Observability and dashboards

Audit Ops (реал-тайм/час): Freshness, Completeness, Proof-Coverage, Reorg/Challenge, Drift-alerts, Error-budget burn.
Bridges Compliance: compliance of actual configs with the registry, SLA finalization, proportion of anomalies.
Data Lineage: interactive path report → showcase → transformation → raw material → proof/anchor.
Key & Access Hygiene: expired keys, suspicious signatures, rotation frequency.

13) Processes and roles

Data Owner-Schemas and storefronts are correct.
Auditor (Internal/External) - check proofs, sampling, compliance with policy.
Bridge/Relay Operator - Evidence Maintenance and Finalization.
Security/Compliance - sanctions, incidents, key and access reviews.
Governance - approval of changes to configs/limits, publication of reports.

14) Playbook incidents

A. Config drift (registry and fact mismatch)

1. Freeze affected pairs, 2) roll back the config to the last signed version, 3) recalculate reports, 4) public note.

B. Reorg/Challenge surge

1. Enlarge K/dispute window, 2) enable delayed finalization for large amounts, 3) warn participants, 4) retro analysis.

C. Insufficient Proof-Coverage

1. Restart of anchoring/mercurization, 2) raise the logging level, 3) sample 100 manual check cases, 4) report for 24 hours.

D. Source key compromise

1. Immediate revoke, 2) re-sign critical batches, 3) update trusted lists, 4) impact analysis and post-mortem.

E. Inconsistency of asset guide

1. Stop at reports with affected assets, 2) catalog rollback, 3) recalculation of USD normalization, 4) publication of the corrected report.

15) Checks and selections for external audit

Sampling plan: stratified sampling by circuits/bridges/sum classes.
Reperformance tests: independent reconstruction of metrics from raw materials.
Walk-through: from report to raw material (and back) with proof verification.
Key-control tests: rotations, revoked keys, rights restrictions.
Change-management: compliance of releases with timelock/deprecate policy.

16) Implementation checklist

1. Identify the sources of truth and the finalization window by domain.
2. Enable immutable logs, hash chains, and regular anchoring.
3. Standardize schemes, idempotency keys and lineage to columns.
4. Raise the register of bridges/configs with signatures and an audit log.
5. Configure SLI/SLO and audit dashboards; include drift alerts.
6. Automate reorg/challenge processing and delayed finalization.
7. Conduct an external audit pilot: sampling, walk-through, reperformance.
8. Put a regular post-mortem on incidents and update the policy.

17) Glossary

Finality - irreversibility of the state/event.
Reorg - reassembly of the chain, canceling part of the blocks.
Anchoring - fixing log hashes in a public network.
Merkle tree - a structure for provable aggregation of many records.
Light-client proof - checks the state of another network by headers/merkle branches.
ZK-proof - a short proof of the correctness of the calculation/state.
Optimistic proof - acceptance with the possibility of challenge in the 'challenge' window.
Lineage - end-to-end traceability of data origin.
Proof-Coverage - the proportion of records with valid evidence.

Bottom line: Chain audit is a discipline of provability. By combining finalization and reorg processing, unchanging logs with anchoring, unified schemes and registers of configs, as well as clear SLOs and playbooks, the ecosystem receives verifiable reports and manageable risks - from a raw event to a management decision.