A bridge exists to answer a question that is genuinely hard: chain B has no way to observe chain A, so something has to tell it that a deposit occurred. Every design is a different answer to „who attests, and what happens if they lie“.<\/p>\n
The most common design. A set of nodes watches chain A, and when enough of them sign an attestation, chain B mints or releases the corresponding assets.<\/p>\n
The trust assumption is explicit: a threshold of that validator set is honest and their keys are secure. If an attacker obtains enough keys, they can mint arbitrary assets on chain B without any deposit on chain A, and this is precisely the shape of the largest bridge losses to date.<\/p>\n
The relevant questions are how many validators, what threshold, who operates them, and \u2014 critically \u2014 whether they are genuinely independent. A „decentralised“ set of fifteen nodes run from three organisations on one cloud provider is a three-party trust assumption wearing a larger number.<\/p>\n
Key management is the recurring failure. Not the signature scheme, not the contract logic: how the keys are stored, who can access them, and whether signing is automated in a way that means compromising one machine compromises the threshold.<\/p>\n
The strongest design. Chain B runs a light client of chain A \u2014 actually verifying chain A’s consensus on chain B \u2014 so the trust assumption reduces to the security of chain A itself. No external attesters.<\/p>\n
The cost is that verifying another chain’s consensus on chain is computationally expensive, and it must be implemented separately for every pair of chains with different consensus rules. That is why these bridges are less common and typically support fewer routes. Zero-knowledge proofs of consensus are the active area of work here, reducing the on-chain cost substantially.<\/p>\n
Worth noting: a light-client bridge still has an upgrade key, and that key can be worth more than the design it protects.<\/p>\n
Structurally different. Nothing is minted; a liquidity provider on chain B hands you assets they already hold, and settles with their counterpart on chain A separately.<\/p>\n
This removes the catastrophic minting risk \u2014 there is no contract that can be tricked into creating unbacked assets. The trust assumption moves to the provider and to whatever mechanism guarantees settlement, and the practical constraint is available liquidity on the destination side.<\/p>\n
The failure mode is much less severe: a stuck or failed transfer rather than an unbacked mint that destroys the value of every wrapped asset at once.<\/p>\n
Borrowing from optimistic rollups: attestations are assumed valid unless challenged within a window. The trust assumption is that at least one honest watcher exists and can submit a challenge in time.<\/p>\n
The trade-off is latency \u2014 the challenge window is a real delay \u2014 and the practical questions are who is actually watching, whether they are incentivised to keep watching during a quiet year, and whether the challenge path has ever been exercised.<\/p>\n
Who attests, and what happens if they collude? How many independent parties, and independent in what sense? Where are the keys and is signing automated? Is there an upgrade key, and does a timelock sit in front of it? Has the failure path \u2014 challenge, forced exit, recovery \u2014 ever been used in production?<\/p>\n
That last question is the one that separates designs which work from designs which are described as working. A mechanism nobody has ever exercised is an assumption.<\/p>\n
Bridge losses have overwhelmingly been operational rather than cryptographic. Compromised keys, misconfigured thresholds, upgrade functions with inadequate protection, validator infrastructure sharing a failure domain. The cryptography has mostly held. The people and processes around it have not \u2014 which is where scrutiny is best spent.<\/p>\n","protected":false},"excerpt":{"rendered":"
The main crypto bridge designs and what each one actually asks you to trust \u2014 external validators, light clients, liquidity networks and optimistic models.<\/p>\n","protected":false},"author":10,"featured_media":133,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[56,57,45,47],"class_list":["post-92","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-layer-1-2","tag-bridges","tag-interoperability","tag-layer-2","tag-security"],"_links":{"self":[{"href":"https:\/\/tokenpr.net\/de\/wp-json\/wp\/v2\/posts\/92","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/tokenpr.net\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/tokenpr.net\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/tokenpr.net\/de\/wp-json\/wp\/v2\/users\/10"}],"replies":[{"embeddable":true,"href":"https:\/\/tokenpr.net\/de\/wp-json\/wp\/v2\/comments?post=92"}],"version-history":[{"count":1,"href":"https:\/\/tokenpr.net\/de\/wp-json\/wp\/v2\/posts\/92\/revisions"}],"predecessor-version":[{"id":98,"href":"https:\/\/tokenpr.net\/de\/wp-json\/wp\/v2\/posts\/92\/revisions\/98"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/tokenpr.net\/de\/wp-json\/wp\/v2\/media\/133"}],"wp:attachment":[{"href":"https:\/\/tokenpr.net\/de\/wp-json\/wp\/v2\/media?parent=92"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/tokenpr.net\/de\/wp-json\/wp\/v2\/categories?post=92"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/tokenpr.net\/de\/wp-json\/wp\/v2\/tags?post=92"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}