Bridges between ecosystems

(Section: Ecosystem and Network)

1) Why bridges are needed

Bridges provide value and data transfer between different domains: blockchains, payment rails, partner platforms, data lakes and API networks. This expands liquidity, unites audiences and accelerates integrations without centralization. Key effects: GTV growth, reduced partner onboarding friction, new products (cross-game assets, multi-chain payments, single identity).

2) Taxonomy of bridges

1. Custodial - centralized custodian issues "wrapped" assets/messages. Simple, but counterparty risk.
2. Federated/MPC - a set of validators/oracles jointly signs events; decentralization is better, but there is trust in the federation.
3. Light-client-based - the target network checks the crypto evidence of the source network (headers/Merkle branches); high cryptographic reliability.
4. Optimistic - events are received with a delay for possible disputes (challenge period).
5. ZK-proof-based - brief proof of the correctness of the state/transitions; fast and safe, more expensive to calculate.
6. Liquidity-network - value transfer through market makers/channels (HTLC/channels, "instant" liquidity, but there is a risk of liquidity).
7. Messaging-only - data transfer/calls without tokens (commands, statuses, bills).

3) Trust model and architecture selection

Required guarantee: economic finalization (failure), cryptographic verification or trust in operators.
Delay: light-client/ZK - faster/more expensive; optimistic - delay for the dispute window; custodial - fast but "human" trust.
Cost: Gas charges/proofs/signatures, opportunistic liquidity cost.
Operating system: who rotates keys, monitors alerts, conducts emergency pauses.
Recommendation: for critical cash flows - light-client/ZK; for data and commands - messaging-only over signatures and acknowledgement; for retail payments - liquidity-network with limits and insurance.

4) Message objects and types

Token transfers: lock/mint, burn/release, escrows, rebalancing.
Payments and payouts: multi-chain, conversion, schedule.
Data/events: KYC statuses, limits, game events, verification results.
Cross-chain calls-Execute a function/transaction in the target domain.
Receipts and confirmations: proof-of-delivery, proof-of-execution, compensating operations.

5) Routing and finalization

Source→Relay→Target: the event is recorded in the source network, delivered by the relay, verified in the target.

• Economic: after K confirmations/eras.
• Cryptographic: light-client/ZK-proofs.
• Dispute window: optimistic model.
• Order and idempotency: deterministic idempotency-key and nonce, target-side deduplication.

6) Risks and threats

Message spoofing/replay.
Compromise of federation/operator keys.
Asset mapping errors (decimals mismatch, chainId).
Lack of liquidity, slip/front run.
Attacks on relayers/oracles (lags, censoring).
Inconsistency of forks/reorg.

Incorrect limits and lack of "stop valves."

7) Security policies

mTLS + event signatures (ed25519/secp256k1), key pinning.
Nonce/sequence per pair (chainA→chainB).
ACL by message type/asset/limit.
Rate-limits/velocity-checks on transfers and messages.
Circuit-breaker: global/pair pause for anomalies.
Two-factor execution: technical signature + operational multisig for large amounts.
List of trusted configs: mapping chainId, decimals, addresses of bridge contracts/services.

8) Economics and liquidity

Fee model: base fee + priority surcharge + proof fee.
Liquidity: pools on networks, monitoring of open exposures; rebalance via reverse flows/market orders.
Slippage and quotation: market quotes, pre-authorization of limits, fair distribution.
Insurance: risk fund/insurance of bridge operators with public reporting.
Payout SLAs: goals for confirmation/delivery speed, compensation for violation.

9) SLI/SLO and monitoring

• Time-to-Finality p50/p95 (min/sec).
• Success-Rate of messages/transfers (%).
• Reorg/Challenge events (pcs/day).
• Liquidity Utilization (%), Pending Backlog (pieces/amount).
• Cost-per-Transfer (ед.).
• Relay/Oracle Availability (%), Data Freshness (лаг).

• Success-Rate ≥ 99. 5%, p95 Finality ≤ 5 min (or network regulation).
• Liquidity buffer ≥ 150% of the 95th percentile of the daily net flow.
• MTTA abnormalities ≤ 5 min, MTTR SEV-1 ≤ 30 min.
• Bridge condition reports - daily, incident reports ≤ 72 hours.

10) Operating regulations

Protocol versioning: capability-negotiation, backward compatibility, deprecate window ≥ 90 days.
Key rotation: planned and emergency procedures, "double keys" (old/new) with alternate switching.
Limits: daily/hourly, by assets and by counterparties; "emergency" hard limits.
Pause/defrost: who activates, how it is announced, how it is removed; public statuses.
Logs: unchangeable event/decision logs linked to the proposal-ID (governance).
Compliance checks: regular audits of configs, forks/reorg simulations.

11) UX and developer experience

Single receipts and statuses (pending, finalized, challenged, failed).
Track & Trace: link/ID, finalization progress bar, ETA.
Idempotent SDKs with automatic retrays/deduplication.
Directory of assets and networks: a single register with versions and locales.
Alerts: webhooks/websites about status changes, limits, pauses.

12) Compliance and risk control

KYC/KYB for influencing roles (operators, providers, relayers).
AML/sanction filters before and after transfer; block lists.
Data residency: routing and encryption according to local requirements; pseudonymization.
Audit: external code/config checks, risk fund reporting.
Dispute policy: timing, evidence, reversibility (reversal policies for messaging-only).

13) Testing and validation

Forks/Reorg simulations: verification of re-delivery and cancellations.
Fuzzing input events: large payloads, rare edge cases.
Chaos tests of relayers/oracles: delays, disconnections, loss of connectivity.
Backfill/Replay: Secure re-replication of history with double protection.
Load tests of liquidity: storm of applications, rebalance under pressure.

14) Playbook incidents (cheat sheet)

• Freeze the corresponding chainA→chainB pairs, enable strict nonce/ACL checking, audit logs, publish status.

• Enable priority rebalancing, raise limits on market makers, temporarily increase commissions, inform ETA, for SLO - compensation.

• Immediate key revocation, switch to emergency multisig, recreate trusted lists, rotation of SDK configs, public report.

• Increase K-confirmations/delay, temporarily switch to "confirmed" checkpoints, postpone large transfers.

• Switching to backup channels, lowering the frequency of batches, enabling filters and quotas, independent cross-verification.

15) Configuration Examples (Pseudo-YAML)

Routing and finalization

yaml bridge:
pairs:
- from: chainA to: chainB confirmations: 20 finality_mode: light_client  # or optimistic    zk nonce_window: 1000 rate_limits:
per_minute: 500 per_hour: 20000 circuit_breaker:
enabled: true error_rate_threshold: 0.5  # %
open_window_sec: 900

Liquidity and fees

yaml liquidity:
pools:
chainA: { base: 2_000_000, buffer_pct: 50 }
chainB: { base: 1_500_000, buffer_pct: 60 }
fees:
base_bps: 8 priority_bps: 5 insurance_fund:
size: 1_000_000 policy: "cover shortfall up to 30%"

Security and keys

yaml security:
signing:
mode: mpc threshold: "t-of-n: 5/8"
acl:
assets_allowlist: [USDC, GAME, POINTS]
methods_allowlist: [transfer, call, message]
alerts:
pager_on:
- "success_rate<99.2%"
- "p95_finality>10m"
- "liquidity_utilization>85%"

16) Data schemas and idempotency (pseudo-SQL)

sql
-- Регистр заявок на перенос
CREATE TABLE bridge_transfers(
id TEXT PRIMARY KEY,
src_chain TEXT, dst_chain TEXT,
asset TEXT, amount NUMERIC,
src_tx TEXT, status TEXT, created_at TIMESTAMPTZ,
nonce BIGINT, sender TEXT, recipient TEXT,
meta JSONB
);

-- Квитанции/доказательства
CREATE TABLE bridge_receipts(
transfer_id TEXT REFERENCES bridge_transfers(id),
proof_type TEXT, proof JSONB, received_at TIMESTAMPTZ,
UNIQUE(transfer_id, proof_type)
);

-- Идемпотентность целевой цепи/домена
CREATE TABLE bridge_idempotency(
dst_chain TEXT, nonce BIGINT, hash TEXT,
PRIMARY KEY (dst_chain, nonce)
);

17) Dashboards

Real-time Ops: Success-Rate, p95/p99 Finality, backlog, relay/oracle availability, burn-rate SLO.
Liquidity & Cost: loading pools, utilization, cost-per-transfer, insurance fund.
Security & Risk: challenge/reorg events, rate-limit triggering, pause/defrost.
Governance & Compliance: limit/key changes, audit reports, SLA metrics.

18) Implementation checklist

1. Choose a trust model (light-client/ZK for money; messaging-only for commands).
2. Capture message schema, nonce/idempotency, ACL, and limits.
3. Set up finalization (K confirmations/dispute window), circuit-breaker and key rotation.
4. Raise SLI/SLO dashboards and alerts; draw up public statuses.
5. Expand the liquidity pool and insurance fund, and enable rebalancing.
6. Perform audit/penetration test and regular simulation of relay forks/failures.
7. Regulate communications and dispute policies.

19) Glossary

Finality - irreversibility of transactions/events.
Challenge period - challenge window (optimistic model).
Light client - verification of headers and proofs of another network.
ZK-proof - a short proof of the correctness of the calculation/state.
HTLC - atomic exchange on conditional payments/secrets.
MPC - joint signature without private key disclosure.
Idempotency - resistance to redelivery.

Bottom line: a reliable bridge is not only a "network connection," but a managed system of cryptography, limits, liquidity, observability and operational regulations. By following these principles, the ecosystem gains safe and predictable interoperability without surprises for users and partners.