Daejun Park

1/ Moltbook is a great experiment, but it brings up a lingering question: How do we secure vibe coded applications? The answer, hopefully, is to have some AI help secure code written by AI, but the specific details are still an active question.

@ihorhanich fair point, but the invariants might be buggy too, then we'd need a way to fix that.

@daejunpark good idea. however, maybe I would do something differently: in case of broken runtime invariant I would not just revert the transaction, but pause the protocol until the upgrade. Broken inv is a bug, after all

Recent Balancer + yETH exploits share a common pattern: tiny numerical edge cases becoming real vulnerabilities. We outline the mechanics and argue for a missing defense: runtime checks on precision + invariants. This needs to be a first-class design requirement in DeFi.👇

@_czepluch @phylaxsystems 🫡

@daejunpark You should check out @phylaxsystems . Here's a small explainer on how it could be used to protect invariants in exploits like Balancer: x.com/_czepluch/stat…

@odysseas_eth 💯 perfectly put. really looking forward to the launch!

Runtime enforcement of invariants is the last crucial missing piece from the security landscape. Intuitively it makes sense: - Identify or prove how an invariant can be broken = extremely complex - Define the invariant (similar to an inverse intent) and then enforce it at runtime = simple With Invariants, you focus entirely on what state is unwanted, without needing to even think about how that state can be achieved. You don't care about the 10 different ways that some codepath can interact with internal or external systems. Simply define the unwanted. The result is not only easier to reason about (thus higher certainty for correctness), but also literally takes less time, which for pre-PMF dapps is of the essence. Runtime enforcement gives us two nice properties: 1. It's actually preventative, vs monitoring which is essentially damage control. 2. We can steer away from formal verification, which not only can't handle overly complex protocols, but also it's extremely challenging and time consuming to use. Instead, we can use other primitives, that are familiar to developers and make runtime enforcement a breeze to write & read. Of course, the question is: how do you enforce that at runtime? Well, for starters runtime must mean during the state transition, which in turns implies that you need to know both the transaction AND the state at which is applied. In other words, it can only really work if it happens during block production. Anything else can be gamed by a sufficiently sophisticated attacker. Another important characteristic, which took us a bit to identify, is that there is value in dislocating the business logic from the invariants. Not only it makes it simpler to be audited and enforced across the entire business logic, but also it allows for flexibility. Flexibility means that one may want to add or remove runtime invariants, according to new information. Maybe something was misunderstood or a new risk was identified. There is value in being able to modify these checks, without changing the core business logic. Invariants can only "stop things", but business logic can also "enable things". That means that updating the invariant definition is explicitly less dangerous than upgrading the core business logic. Finally, the on-chain EVM is by definition constrained. For example, the code only has context about the current call, rather than the whole transaction. Runtime enforcement requires new affordances for the developers to be able to fully express important invariants (or heuristics). Maybe they need all the state diffs in a transaction, or check the state between different calls. Since we are at it, we might as well optimize the whole damn thing. Invariants are mostly "atomic and read only", which means that their computations can be aggressively parallelized after every state transition. That translates to a new primitive, which not only introduces security, but also can support any scalability roadmap for the underlying blockchain. The cherry on the top? The blog post makes a hint, but such a system will need a powerful testing framework. Unit test, fuzzing, fork tests, backtesting (against historical blocks), Staging (against live blocks), you name it. Developers need to arrive to high confidence before they deploy their runtime enforcement of invariants. Taking all the above, and you have a pretty good idea on what we are building at @phylaxsystems. We are very excited to share this with the world as we are going live on [REDACTED] very soon. We took the contrarian bet, over a year ago, and we can't be more excited to see our approach validated by customers, partners, regulators, and the rest of the security community. See you in the trenches oh, and one last thing it's time to put Lazarus Group out of business

@ishverduzco 🥰

@daejunpark Daejun tweets, I stop what I’m doing to read 🫡

@AlexQuellsIt Most auditors can identify core invariants, but they rarely push for runtime enforcement unless the client asks. So I recommend asking them to include those invariants explicitly in the audit report; it changes the outcome.

@daejunpark Appreciate the insights. Do you see any auditors suggesting/ enforcing this?

@aklamun @GyroStable 🫡

Many viewed @GyroStable's GYD as overly complex. But it's the complexity you need for security. It was ahead of its time with invariants and runtime guardrails so that even if there were a bug, its impact is limited. DeFi would be a lot safer if more had been built like GYD.

@ittaia Love that point! Time delays could be the safest and most robust route when composability isn’t critical. UI would need some thoughtful design, but totally worth it. Really appreciate the feedback!

@daejunpark Nice! BTW, safety versus liveness often handled more continuously with time delays. Some wallets delay large changes so auditors can intervene. Here, instead of hard runtime enforcement failure, execution would move to delayed mode, giving auditors time for a go or no go decision

9/ Full post: a16zcrypto.com/posts/article/…

8/ As DeFi math gets more complex, this line of defense becomes essential. Even if an unforeseen numerical subtlety slips through, the protocol should never enter a state that violates its economic invariants.

Full post: a16zcrypto.com/posts/article/…

The future of DeFi security: Not “did we catch every bug?” but “can the system block unsafe behavior by design?” Core invariants + runtime guardrails = spec is law.