# Value Is Only As Safe As the Code Immutability makes value permanent and mistakes permanent in the same proportion. The failure classes that actually drain funds, the cost asymmetry of skipping audits, and why security is the first layer — not an optional safeguard. --- There is a property of onchain systems that gets talked about as a feature and is almost never talked about as a moral weight: immutability. When a smart contract is deployed, it is done. The logic is written to the chain, the address is live, and whatever rules the code enforces are the rules — until the last interaction, or the last fund, or the last exploitable path through the execution tree. No one is going to push a patch at 2 a.m. There is no rollback. There is no hotfix. Once a contract is deployed, its code cannot be modified, patched, or silently fixed. Any vulnerability embedded in the logic becomes a permanent part of the system, creating long-term exposure if it is not identified and addressed before deployment. That is a fundamentally different world from traditional software. Traditional applications typically run on centralized servers where developers can patch bugs, roll back changes, or disable features if issues arise. A web server gets compromised, you isolate it, you patch, you redeploy. Inconvenient, expensive, embarrassing — but survivable. Smart contracts directly manage digital assets and enforce rules automatically. As a result, errors in smart contracts have immediate, irreversible effects, making secure design and validation far more critical than in conventional software development. This is what I mean when I say immutability cuts both ways. It makes value permanent. And it makes mistakes permanent in exactly the same proportion. ## The Categories of Failure That Actually Drain Funds I want to be clear about what follows: this is not a how-to. Understanding the shape of a class of failures is not the same as providing instructions for exploiting one. A surgeon needs to understand how infections spread without performing them. A structural engineer needs to understand how bridges fail without building ones that do. Security literacy for anyone building onchain — or trusting their savings to systems built onchain — requires the same kind of conceptual fluency. **Reentrancy** is perhaps the oldest wound. A reentrancy attack occurs when a contract makes an external call to another contract before updating its own state. The consequence is that an attacker can call back into the original contract mid-execution, before the accounting has been corrected. The books show a balance that no longer reflects reality. Funds move that shouldn't be able to move. The DAO hack of 2016 was a pivotal moment for all of blockchain. Attackers used a reentrancy flaw to drain over $60 million in ETH from a decentralized fund. The event resulted in major investor losses and even led to an Ethereum hard fork to reclaim funds. That was a decade ago. The vulnerability class persists. **Access control failures** are the single most expensive category in the current threat landscape. Access control vulnerabilities are the most expensive vulnerability class in smart contract history. In 2024, they caused $953.2 million in losses — more than reentrancy, oracle manipulation, flash loans, and integer overflow combined. The mechanism is straightforward in concept: access control flaws occur when a smart contract fails to properly restrict who can call sensitive functions. An admin function without a permission check. An initialization function left open after deployment. An upgrade mechanism accessible to any address. These are not exotic zero-days. They are design oversights — the digital equivalent of leaving a vault door open because the builder assumed no one would try it. **Oracle and price manipulation** attacks exploit the contract's relationship with external reality. Smart contracts often rely on external data, fetched by oracles. If an attacker can influence the oracle — for example, by controlling price feeds — they can manipulate contract behavior. Hackers can tamper with external data feeds to skew prices, leading to bad loans or trades. This is common in DeFi where accurate prices are crucial. Flash loans accelerate the attack surface: borrow millions, manipulate a price oracle or liquidity pool, exploit the mispricing in your protocol, repay the loan, and pocket the difference — all atomically in one transaction. The contract did exactly what it was told. It was told a lie. **Arithmetic vulnerabilities** occupy quieter territory but remain lethal. Integer overflow and underflow occur when arithmetic operations exceed the storage capacity of the data type, leading to unexpected results. Underflow occurs when a value is decreased below zero, while overflow occurs when it exceeds its maximum value. These vulnerabilities can lead to unexpected behavior in smart contracts, potentially resulting in financial losses or system failures. A contract's biggest enemy is not complexity — it's assumptions. Developers assume a function won't be reentered, that math operations will behave as expected, and that conditions will execute in the right order. The blockchain doesn't forgive wrong assumptions. **Upgrade key misuse** is the most structurally ironic of the failure categories. Upgradeability was invented to fix the rigidity of immutability. But the mechanism that allows a contract to be fixed is also the mechanism that allows it to be destroyed. Whoever controls the upgrade function controls the contract. If a single private key can authorize an upgrade, that key can rewrite what the contract does. An attacker who compromises the admin key, or an insider who abuses it, can deploy a malicious implementation that drains funds, mints unauthorized tokens, or changes balances. The original code can pass every audit and still be irrelevant once the upgrade function executes. Upgradeability does not reduce the need for security. It multiplies it. What is striking about this taxonomy is that none of these are obscure. Most smart contract exploits aren't zero-days. They're known vulnerability classes hitting code that skipped a serious review, or passed an audit too narrow to catch what mattered. The research is consistent. Incidents are rarely single-shot failures. Only 19 of 50 exploits hinged on merely a code defect; the rest were chains of two or more weaknesses, or contained a human factor enabling the incident. Complexity compounds risk. But the entry points are known. ## The Cost Asymmetry There is a financial argument here that should be obvious but apparently needs to be made repeatedly. The average loss per smart contract exploit across the past four years has been approximately $1.9 million. Against that number, a $70,000 audit for a mid-complexity DeFi protocol is not an expensive line item. It is a cost that scales with the risk it is being asked to reduce. In 2026, expect to pay between $1,000 and $15,000 for a basic token audit, $20,000 to $100,000 for a typical DeFi protocol, and $50,000 or more for bridges and complex multi-chain systems. Even at the high end of that range, the math is not close. Because blockchain transactions are irreversible, recovery is rare. Across a research sample of real-world breaches, the average breach results in losses exceeding $20 million. But the financial framing undersells the problem. As smart contracts increasingly manage valuable assets and critical logic, security failures can lead to irreversible financial loss and long-term trust erosion. The protocol that gets drained once does not get drained twice — it ceases to be used. The losses aren't just what left the contract. They are everything that would have come in after. The trust you lose in an exploit cannot be bought back at any price. ## Security as the First Layer At kooky, we ordered our principles deliberately. SECURE → BUILD → ANCHOR is not an arbitrary sequence. It is a causal one. Security is first because nothing else matters if the foundation is wrong. You can build the cleanest user experience, design the most elegant staking mechanics, obsess over every detail of interface and onboarding — and if the contract logic fails, all of it evaporates in a single transaction. The user doesn't lose a feature. They lose their principal. There is no version of that outcome that is acceptable, and there is no recovering from it by shipping a better UI next quarter. Smart contract security is a foundational requirement for Web3 success, not an optional safeguard. As smart contracts increasingly manage valuable assets and critical logic, security failures can lead to irreversible financial loss and long-term trust erosion. I agree with this framing, but I would go one step further: security isn't even a requirement in the sense of something you comply with. It is the precondition under which everything else becomes meaningful. BUILD assumes a secure foundation. ANCHOR assumes trust has been earned. Neither holds without SECURE. This is not a risk management posture. It is an architectural one. ## How This Shaped Shaka When we designed Shaka, this belief had a direct consequence on how we divided responsibility between the contract layer and the application layer. The principle we settled on is this: the contract calculates, the app obeys. What that means in practice is that Shaka's smart contracts carry the canonical logic. Reward calculations, stake accounting, access rules, fund custody — these live in the contract. The application layer reads the contract's outputs and renders them. It does not reinterpret them. It does not hold a parallel ledger that the contract needs to be kept in sync with. It does not make assumptions the contract hasn't already enforced. This matters for security because every place where application logic duplicates or overrides contract logic is a potential divergence point — a place where an attacker can find a gap between what the app thinks and what the contract does, or where a bug in the app creates an inconsistency that can be exploited. Keeping the truth inside the contract, and treating the app as a read-and-render layer, reduces that surface dramatically. An audit covers what the code does, not necessarily what it should do. That observation cuts to the heart of why specification matters as much as implementation. Before we wrote a line of Shaka's contract, we had to know exactly what it was supposed to do — not approximately, not "roughly this" — precisely. The security properties we wanted were defined before the code existed to express them. An audit can confirm that the code matches the spec. It cannot conjure a good spec from ambiguous intentions. The "contract calculates, app obeys" design is not a clever architectural choice. It is the security posture expressed as a division of labor. The contract is the authority. The app is the interface to it. That relationship is not supposed to be negotiable at runtime. ## The Obligation That Comes With Custody When someone deposits funds into a protocol, they are extending a form of trust that has no equivalent in most software contexts. They are not trusting that a feature will work. They are trusting that what they put in will still be there when they want it back, plus whatever the protocol promised on top of that. With new exploits emerging daily, there is an urgent need to prevent vulnerable contracts from being deployed. If they are deployed, they will be exploited. That is not cynicism. It is the observed behavior of public, adversarial networks. Smart contracts are visible to everyone, including everyone who would prefer to empty them. The code is the only protection. Once funds leave the contract, recovery is nearly impossible. There is a version of this problem that gets framed as a technical challenge — a matter of good engineering practices and thorough testing and competent auditors. All of that is true. But underneath the technical framing is an ethical one. When you ask someone to trust a contract with their money, you are making a promise that the contract will honor it. The quality of the code is the quality of the promise. Security, then, is not a feature we ship. It is the condition under which we have the right to ask for trust at all.