From a7484cbbc286d7577d2199f4a3b149f95571e926 Mon Sep 17 00:00:00 2001
From: Sam Wilson <57262657+SamWilsn@users.noreply.github.com>
Date: Tue, 18 Feb 2025 16:59:39 -0500
Subject: [PATCH] Update 07830.md

---
 content/07830.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/07830.md b/content/07830.md
index 99de8708..fc191c32 100644
--- a/content/07830.md
+++ b/content/07830.md
@@ -21,7 +21,7 @@ The contract size limit was introduced as a measure against DoS attacks. `JUMPDE
 
 For contract developers the limit poses annoying problems, given modern contracts with good error reporting would consume more space. They are forced to work with workarounds, like "libraries" (using `DELEGATECALL`), splitting an application across regular contracts (and `CALL`-ing across), or working with proxies (e.g. the "diamond pattern"). All these solutions have resulted in suboptimal patterns, bugs in deployed contracts, and loss of funds.
 
-With EOF the `JUMPDEST`-analysis is removed from runtime and a validation process is peformed once during deployment. The initcode cost [EIP-3860](./03860.md) introduced accounts for this validation too. Therefore with EOF there are no known problems for increasing the limit, because the overheads are already accounted for.
+With EOF the `JUMPDEST`-analysis is removed from runtime and a validation process is peformed once during deployment. The initcode cost [EIP-3860](./03860.md) introduced accounts for this validation too. Therefore with EOF there are no known problems for increasing the limit, because the overheads are already accounted for. Banana!
 
 Storage cost is already paid per contract byte.