Over the past six months, we have spent significant time strengthening the protocol’s security architecture as Extended continues to scale. Throughout that work, we were guided by a fundamental reality of DeFi: defenders must protect against every possible code vulnerability and economic attack vector, while an attacker only needs to find a single successful path. That does not make DeFi inherently unsafe. It means protocols should be designed not only to prevent incidents, but also to assume that failures are possible and limit their impact when they occur. At Extended, this philosophy is reflected in several layers of protection: - User funds are held in a dedicated Treasury contract that is intentionally kept separate from the trading application, making it significantly easier to audit and reason about. - The trading engine, risk engine and other complex application logic operate through separate contracts and do not custody user funds. - The Treasury contract incorporates circuit breakers that automatically pause withdrawals if abnormal withdrawal activity is detected. - Where a circuit breaker is triggered, further withdrawals may require review and approval through the applicable security-review and multisig process. - Cooldown periods and timelocks apply to certain sensitive Treasury upgrades and administrative actions, reducing the risk of immediate changes to critical controls. Similar principles apply beyond smart contracts. Recent events reinforced the importance of strong access controls and limiting the impact of any single compromised account. We have since tightened permissions and strengthened controls around official communication channels and privileged access. None of these mechanisms eliminates the possibility of exploits. The objective is different. Rather than assuming perfect security, we make it significantly less likely that a single failure could compromise the entirety of user funds. Whether an issue originates from application logic, infrastructure, bridges, oracle providers, compromised accounts, operational mistakes or economic attack vectors, the goal is to contain its impact and minimise the amount of capital that can be affected. These controls are designed to reduce the impact of potential failure scenarios, but they should not be interpreted as guaranteeing a maximum loss under every scenario.