What this prompt does
This prompt architects a cross-chain bridge with the security model as the whole design, not a footnote — appropriate given bridges are among the highest-stakes systems in the space. You set [source_chain], [destination_chain], [asset_types], [daily_volume], and the [security_model], and it designs the [bridge_type] flow, a [validator_model] network, smart contracts per chain, the security model, fees, monitoring, and emergency procedures.
The structure works because the biggest exploits come from the parts teams treat as secondary. By forcing the locking/minting flow for [transfer_flow], a [validator_count] network with [consensus_mechanism] attestation, analysis of [attack_vectors] like validator collusion and reorg double-spends, [security_measures] including time-locks above [threshold_amount], a [challenge_window] for [fraud_proof_type] proofs, rate limiting at [rate_limit], and a guardian multisig with [guardian_threshold], it puts the failure modes on the table from the start. Handling [native_asset_bridging] explicitly also avoids the wrapped-token confusion that has caused real accounting bugs between chains.
When to use it
- You are architecting cross-chain infrastructure and want security as the core design
- You need the lock-and-mint flow for
[transfer_flow]spelled out per direction - You want
[attack_vectors]like validator collusion explicitly analyzed - You need rate limiting and time-locks scoped to real
[daily_volume] - You want a validator/relayer attestation protocol with
[consensus_mechanism] - You need a fee model that covers validator costs and gas on both chains
- You need emergency procedures and a guardian multisig defined up front
Example output
Expect a defense-first architecture: the [bridge_type] flow describing lock, mint, burn, and unlock per direction with canonical-versus-wrapped token handling for [asset_types], a [validator_model] with [validator_count] validators and the message-passing and [consensus_mechanism] attestation protocol, contract specs for LockBox, MintBridge, ValidatorRegistry, and FeeManager, a security section analyzing [attack_vectors] with [security_measures] including time-locks above [threshold_amount], a [challenge_window], and [rate_limit], a [fee_structure] with [fee_factors], monitoring of [monitoring_metrics] with [alert_conditions], and guardian [emergency_actions] at [guardian_threshold]. The contract specs include function signatures and state transitions so the implementation path is concrete.
Pro tips
- Design the
[security_model]first and let everything else follow from it; bridges that bolt security on later are the ones that get drained - Make
[attack_vectors]exhaustive — validator collusion, reorg double-spends, fake attestations, and contract exploits are the recurring exploit classes - Scope
[rate_limit]and[threshold_amount]to real[daily_volume]so large anomalous transfers hit a time-lock instead of clearing instantly - Choose
[validator_count]and the[consensus_mechanism]threshold so no realistic subset of validators can forge an attestation - Wire
[alert_conditions]like TVL imbalance and validator downtime to a channel that pages, since silent monitoring helps nobody mid-attack - Define
[emergency_actions]and the[guardian_threshold]before launch, since you cannot design a pause mechanism mid-incident - Treat the whole output as a design to be independently reviewed and audited — bridge security is unforgiving and a single gap is catastrophic
