Economic Security Bound

What is an economic security bound, and how does it differ from the trust minimization spectrum discussed earlier in this series?

The trust minimization spectrum discussed earlier in this series assesses how many parties a user needs to trust at each layer of a system — a relatively static architectural analysis, where the same architecture's trust-spectrum profile typically doesn't change just because the capital scale a system manages changes. An economic security bound addresses a completely different dimension: even if an architecture's technical design hasn't changed at all and its trust spectrum stays the same, the system's actual security can still undergo a qualitative shift as the capital scale it manages grows.

For example, if a cross-chain bridge uses a 5-validator multisig mechanism, an attacker needs to bribe or compromise 3 of those validators to succeed — if bribing 3 validators costs $10 million, and this bridge only has $5 million in locked assets, a rational attacker wouldn't launch the attack, because the cost exceeds the benefit; but if the assets this bridge manages grow to $50 million, the same technical architecture with the same validator mechanism suddenly makes the attack "worthwhile" — the economic security bound gets crossed just like that, and the entire process never involved any new technical vulnerability at all.

Why is the economic security bound concept especially important, and what does it share in common with the strategy capacity decay concept discussed earlier in this series?

The economic security bound is especially worth emphasizing because it reveals an easily overlooked fact: security isn't a fixed technical property — it's an economic relationship that dynamically shifts as the capital scale a system manages changes. This means an architecture once considered secure enough could, simply because users keep depositing capital and management scale keeps expanding, gradually cross its economic security bound with the architecture completely unchanged, becoming an increasingly attractive attack target.

This concept shares an abstract common pattern with the strategy capacity decay concept discussed earlier in this series: both involve some property of a system (strategy profitability, system security) inversely changing as the managed capital scale grows. Strategy capacity decay is scale growth eroding return; economic security bound is scale growth eroding security. Both remind us that evaluating a DeFAI system can't just look at a static snapshot at one point in time — it also needs to account for scale growth's dynamic impact on these properties.

経済的安全境界は実際どう評価すればよく、一般ユーザーはこの境界がどこにあるかを自分で見積もる方法がありますか？

完全な定量的評価には「攻撃コスト」の具体的な見積もりが必要である——例えば十分な数のバリデーターを買収する、または51%の計算力攻撃を実行するには、実際どれだけのリソースが必要かという分析であり、これは通常専門的なセキュリティ研究の背景を必要とする。しかし一般ユーザーでも比較的簡略化された間接的な判断はできる：このシステムが現在管理している資産の総規模（TVL）を確認し、シンプルな質問を考えてみる——もし自分が攻撃者だったら、このシステムの検証メカニズムを突破する（マルチシグ保有者を買収する、または経済的インセンティブを利用して十分な数の参加者に協力させるなど）のにおおよそどれくらいのコストがかかるか、そしてその見積もりコストは現在管理されている資産規模より明らかに低いかどうかである。

より実用的な間接指標は、このシステムの管理規模の成長傾向を観察することである——管理規模が急速に成長している場合、それは経済的安全境界が急速に圧縮されつつあることを意味する。現時点で技術的に依然安全であっても、成長する攻撃インセンティブに対応するために技術アーキテクチャを調整しているか（バリデーター数を増やす、マルチシグの閾値を上げるなど）を継続的に注視する価値がある。アーキテクチャを停滞させたまま、経済的安全境界が規模の成長によって徐々に侵食されるままにするのではなく。

経済的安全境界は一般ユーザーにどのような実際の影響を与えますか？DeFAI製品の評価と継続的な監視にどう応用すればいいですか？

利用しているDeFAI製品の管理規模が急速に成長している場合、それ自体はネガティブなシグナルではない（通常はますます多くの人がこの製品を信頼していることを意味する）が、この成長プロセス自体が、このシステムをますます魅力的な攻撃対象にしつつあることを意識する価値がある。技術アーキテクチャが同期してアップグレードされていなければ、システムのコードが一行も変わっていなくても、経済的安全境界は圧縮されつつある可能性がある。どのDeFAI製品を評価する際も、このチームが管理規模の成長に応じて検証メカニズムやセキュリティパラメータを積極的に調整したことがあるか、プロジェクトがローンチしたばかりで規模がまだ小さかった時に一度設計しただけで、その後見直していないのではないかを尋ねる価値がある。

実際に応用する際は、「このシステムの管理規模が自分を不安にさせるほど成長しているか」を、最初に資金を投入する時だけの一回限りの評価ではなく、継続的な観察指標として扱うことができる。責任あるチームは通常、管理規模が著しく成長した際に、セキュリティメカニズムも対応してアップグレードされたかを積極的に開示する。あるシステムの管理規模が既に数十倍に成長しているのに、技術アーキテクチャの文書に示されている検証メカニズムが全く更新されていない場合、この非対称性自体があなたのリスク評価リストに加える価値がある。