📤 Relayer & Infrastructure
Overview
The KAT Bridge relayer layer is designed for independence, redundancy, and fault isolation. Each relayer is run by a unique operator in a separate environment, ensuring no single party can control the bridge.
Relayers are responsible for observing events, validating payloads, and either:
Submitting attestations on L2 (for deposits).
Producing partial signatures for FROST rounds (for withdrawals).
Relayer Design
Independence
5 servers, each in a separate datacenter and provider.
Each server is controlled by a unique individual/operator.
No shared databases or networking dependencies between relayers.
Autonomy
Relayers function without coordination from peers.
For deposits: each relayer submits attestations directly on L2.
For withdrawals: relayers produce partial signatures independently, then share them with the coordinator.
Storage
Each relayer maintains its own local Postgres database.
Tracks observed events, completed attestations/signatures, and health metrics.
Replication and backups exist but centralization doesn't — each relayer has its own state history.
Coordinator Application
Runs separately from the 5 relayers.
Role: Collects partial FROST signatures for withdrawals, verifies their validity, and assembles the final group signature.
Limitations: The coordinator cannot sign on its own; it only aggregates.
Outputs: Final group signature submitted to Kaspa L1 for releases.
Custom Chain Listeners
Kaspa Listener: Detects KRC-20 deposit transactions with the bridge’s EXTRA blob. Waits for 20 blocks before emitting an event.
EVM Listener: Detects ERC-20 burns on L2. Waits for 20 blocks before emitting an event.
Both listeners are implemented in-house for efficiency, auditability, and security.
Standardized event format ensures all relayers process identical inputs.
Observability & Operations
Health Metrics:
Event ingestion latency.
Database consistency.
Signature/attestation success rate.
Alerts: Operators are notified on relayer downtime, missed attestations, or repeated signature failures.
Retry Flow: Failed operations retry once. If the second attempt fails, admins are notified for manual review.
Guarantees
Safety: No single relayer can force bridge activity.
Resilience: Compromise of one relayer does not affect quorum or correctness.
Auditability: Independent databases + on-chain attestations create verifiable logs of each operator’s actions.
Transparency: Operator sets and governance changes are publicly documented.