banteg https://banteg.xyz/index.html banteg's personal blog quarto-1.3.450 Mon, 09 Mar 2026 20:00:00 GMT Binary Ninja for Agents banteg https://banteg.xyz/posts/bn/index.html Most reverse engineering tooling is still designed for either a human in a GUI or headless batch script. Agents are an emerging third type.

They are very good with tools, but the tools need to be shaped in a way understandable to them. They like shell commands, structured or at least predictable output they could pipe to jq or rg, short feedback loops, or perhaps even an escape hatch to run arbitrary scripts that one shot the exact result they require.

MCP era: decompiling at snail pace

In my previous reversing project I used NSA’s Ghirda, and, honestly, I never even opened the GUI or bothered to create a Ghidra project. It was all a series of scripts that I had to rerun after each pass of deciphering the symbols.

For this project I wanted to try something different. I already had my fork of binary_ninja_mcp set up, so I went with it. This time I used a proper project (.bndb), so my edits persist and propagate in seconds instead of minutes I previously spent to run a full pipeline.

On paper it should have been enough: the agent could ask for decompiles, inspect types, rename things, and keep working against the live Binary Ninja session. For short, surgical questions, that mostly worked. But once it got deep into reverse engineering, the shape of the interface started to crack.

The responses often got truncated, and it kept adding mcp_ prefix to renames. While renames were just annoying and easily solved with a patch, the truncation was harder to fix.

There is a hardcoded policy in Codex for tool output: it truncates the middle, keeps the start and end, and inserts a marker like …N tokens truncated…. Obviously this doesn’t work when you are decompiling a large function responsible for core gameplay loop.

There is no easy way around it when using MCP, you can override the default 10,000 token limit in config, but it could result in a different issue where a large response chokes and bricks the session by eating into the compaction buffer.

~/.codex/config.toml
tool_output_token_limit = 50000

How bn started

So bn started from a complaint. I asked Codex to analyze its rollout and dream up a better tool. 10 minutes later it was already better than the existing MCP tool.

I built bn while porting Snail Mail to Zig. The original 2004 Windows binary is stripped down to no symbols, no debug info, just x86. Binary Ninja does the decompilation work, but the actual grind is in the naming, typing, cross-referencing, and inferring the symbols.

Over the next 36-hour session Codex has issued 1,548 bn commands: 547 decompiles, 246 xref walks, 217 searches, 95 inline Python snippets, 67 renames, and 48 struct edits. The interesting part was that it kept choosing bn for real work instead of routing around it.

After each batch it gave feedback and got new features it wished for a few minutes later. Later on I analyzed the transcript and cut the features it never used.

What bn actually is

It is a very opinionated shell layer over a live Binary Ninja session. It’s essentially a socket bridge between a CLI and a Binary Ninja GUI plugin. The plugin owns the real Binary Ninja API access. The CLI talks to the already-open database in the GUI. Because it runs through the GUI plugin, it works with a $300/year personal license and doesn’t require a $1500/year commercial license that’s required for headless mode.

bn is a coding-agent-first CLI for Binary Ninja.

First, it gives the agent stable commands for things like:

bn target list
bn function search gameplay
bn decompile update_cameraman
bn xrefs field Player.movement_state
bn types show Game
bn struct field set Player 0x308 movement_flag_selector uint32_t --preview
bn py exec --code $"print(hex(bv.entry_point))"

Second, it returns text when text is the right interface, and JSON when structure matters. Large outputs auto-spill to disk and report back the token and line counts instead of detonating the model’s context window.

Third, writes are not blind. Preview mode applies a change, refreshes analysis, captures the decompile diff, and reverts it. Real writes only report success after reading the live Binary Ninja state back and verifying that the requested change actually landed.

Python escape hatch

And finally, there is a Python escape hatch, bn py exec. Agents are very good at writing exploratory scripts, so why not allow to run them inside Binja and get the exact result shape they want for the current question. This matters even more than any polished surface command. You can build all the command coverage you want, but reverse engineering always finds the weird case. This future-proofs against all of them.

Here is one real example:

$ bn py exec --target SnailMail.exe.bndb --stdin <<'PY'
from binaryninja import Symbol, SymbolType

pairs = {
    0x4107d0: "update_frontend_state_machine",
    0x410c40: "initialize_frontend_background_distortion_grid",
    0x410d50: "activate_frontend_background_entry",
    0x410e20: "initialize_frontend_background_renderer",
    0x410f40: "set_frontend_background_texture_target",
    0x410f90: "draw_frontend_split_background",
    0x411040: "draw_frontend_warped_background",
    0x4112f0: "update_frontend_background_renderer",
    0x449460: "initialize_bass_audio_backend",
}

renamed = []
for addr, name in pairs.items():
    func = bv.get_function_at(addr)
    if func is None:
        renamed.append({"address": hex(addr), "error": "missing function"})
        continue
    bv.define_user_symbol(Symbol(SymbolType.FunctionSymbol, addr, name))
    renamed.append({"address": hex(addr), "name": bv.get_function_at(addr).name})

bv.update_analysis_and_wait()
result = renamed
PY

The manifest had already converged on the right names, but the live Binary Ninja session had not. Codex dropped into bn py exec, batch renamed nine functions directly inside the open database, forced reanalysis, and got a structured confirmation payload back. This design philosophy allows to keep the shell surface small and useful, but makes sure there is always one level lower to go.

Tool loop

The session did not look like one giant decompile followed by a magic answer. It looked like a reverser using a shell:

  1. Find a narrow entry point
  2. Inspect xrefs and decompile
  3. Form a naming or type hypothesis
  4. Preview the mutation
  5. Commit it if the diff looks right
  6. Reread the affected functions
  7. Repeat

That is the whole game.

One concrete case was struct recovery. Codex inspected Player, PathTemplate, FollowState, and related movement helpers, then started pushing type information back into the live database. It would preview a field edit, look at the affected decompile diff, commit it, and then immediately reread the relevant functions. When the decompiler presentation stayed stale and still showed raw __offset(...) fields, it forced a refresh and checked again. The loop stayed tight enough that the agent could treat type recovery as an interactive process instead of a one-way write.

That same pattern showed up everywhere else. bn function search and bn strings --query were the front door to the next question. bn xrefs was how the agent kept branching through the call graph. bn decompile never truncated and allowed the agent to intelligently move forawrd. Because the surface was shell-native, the agent could mix bn with rg, temp files, jq, and little follow-up reads.

Symbol oracles

One of the best moments in the session came after loading the Android and iOS ports of Snail Mail next to the stripped Windows build. The mobile binaries were rich in symbols.

Once those targets were open in the same environment, the workflow became obvious: use the Android and iOS builds as naming or secondary behavior oracles for the Windows one. Codex could search for a symbol-rich function in libsnailmail.so, decompile it there, compare the logic to a stripped Windows function, and then promote the Windows symbol to a real name with much higher confidence. That pattern repeated across menu flow, intro state, gameplay helpers, damage-gauge code, and subgoldy lifecycle work.

That mattered because cross-port reversing is mostly comparison work. If switching targets is awkward, the agent quietly stops doing it. If the command surface stays the same across targets, the agent uses every build as a reference source.

bn made the correct workflow as easy as --target libsnailmail.so.

Failure is not an option

This was maybe the most important property. Bad tooling says “done” and leaves the real state unchanged. Good tooling either succeeds, fails noisily, or gives you a lower-level escape hatch.

bn got there by making mutation paths verify the live post-state and by keeping bn py exec first-class. During the session, symbol rename sometimes worked cleanly and sometimes did not. In one case a preview rename threw an error; a non-preview rename looked successful but did not actually change the symbol in Binary Ninja. Codex checked the state, saw the rename had not landed, and fell back to Python inside the Binary Ninja process to define the symbol directly.

This has inspied the --preview feature. A struct edit or type declaration can cascade through a lot of functions. Preview gives the agent reversible reasoning: try the change, inspect consequences, keep it if the evidence improves, drop it if it does not.

Keep tools pristine

The other reason the session worked is that I owned the tool while the agent was using it.

Early on, Codex hit real pain points: large decompile spills writing to bad paths in the sandbox, bursty parallel reads tripping connection refused, stale __offset(...) presentation after type edits, rename paths with edge-case bugs, and rough search ergonomics on big binaries. Instead of treating those as permanent limitations, the loop was pain → patch → retry. Auto-spill moved to temp, transient connect retries were added, the accept backlog was increased, decompile JSON gained warnings when stale __offset(...) survived refresh, and querying got features like --regex.

The distance between friction and fix is short enough that the agent keeps using the tool instead of permanently routing around it.

There was another small but important piece here too: the bundled Codex skill. The repo ships a skill alongside the CLI and plugin, and that matters because a lot of tool quality is really workflow quality. Teaching the agent to start with bn doctor, bn target list, bn refresh, preview mutations first, and use --out for large artifacts removes a lot of dumb failure modes before they happen.

Why this kind of tooling works

The lesson here is not just that Binary Ninja is scriptable. We already knew that.

A small, specific CLI over a live reversing tool can outperform much grander integrations if it gets a few things right.

  • It speaks the agent’s native language: commands, files, JSON, grep
  • It makes writes previewable and verifiable
  • It is owned closely enough that feedback turns into code instead of a wishlist

Codex used bn the way a good reverser uses a shell: probe, xref, rename, type, diff, compare builds, sync findings, repeat. This made the progress really fast.

That sets the real bar for agent-native tools. Not “can the model call tools?” but “does the tool create a tight enough loop that the model keeps choosing it for real work?”

bn is open source and free to use.

]]> reverse engineering agents https://banteg.xyz/posts/bn/index.html Mon, 09 Mar 2026 20:00:00 GMT Resurrecting Crimsonland banteg https://banteg.xyz/posts/crimsonland/index.html some games die quietly. they get delisted, lose their multiplayer servers, fade into the digital void. others get remastered by the original authors with slightly better graphics and a battle pass.

and then there’s the third way: you open the binary in ghidra and start naming functions.

the history

crimsonland (2003, remastered 2014, resurrected 2026) is a top-down shooter from the era when indie games were still called “shareware” and steam was something that came out of radiators. you play as a small man with a gun. things try to touch you. you shoot them. eventually there are too many things. you die. it’s perfect.

i remember vividly downloading it on a 56k modem and playing with a friend. the tiny 7.5mb game had us entertained for months. it was the first game by a finnish studio 10tons. they initially made a free game in 2002. i preserved a few of those early freeware versions:

v1.0.2 from may 2002 is an early prototype that establishes core mechanics.

v1.3.0 from july 2002 adds 3 music tracks not heard later in the shareware version. you can listen to them here as tracks 10-12.

v1.4.0 from september 2002 is the final free version before 10tons heard the big news: the game got picked up by reflexive arcade, a major publisher at the time. the shareware version has seen release in april 2003 and it has spread like wildfire, including cover CDs of various game magazines.

the shareware version is known as v1.8.x-1.9.x series, with v1.9.8 from september 2003 receiving a cult following for some of the most overpowered combos possible of all versions. after reflexive shut down in 2010, there was another update v1.9.93 that has added widescreen support (960x800). the very same version has later become a free bonus on gog.com when the studio has made a remaster in 2014.

but let’s not get ahead of ourselves. the game got a cult following, the studio was teasing crimsonland 2 with features like network multiplayer and a fully rewritten engine. this archived blog page is the most representative of the sequel hopium. the forum was swarming with theories and excitement. here are some of the concepts that were posted (source):

by 2010 it was clear that crimsonland 2 was not going to happen. the studio has long shifted their focus to casual mobile games (infinite money glitch) that look more like zuma deluxe rather than their first game.

in 2013 the studio floats a remaster idea via steam greenlight, and the game sees a steam release on june 11, 2014. a gog.com release came a month later, and osx (now macos), linux, ps4, xbox releases have followed.

crimsonland 2003

crimsonland 2014

the game has its fans, but my heart lies there, in 2003, with the original mechanics.

the project

not gonna lie, i was interested in understanding what makes this game tick at a deeper level for a long time. i tried decompiling it, i came back to making clones decades apart. something about it was alluring.

by the time i started this project on january 16, 2026, i had a pretty good understanding of things like the custom formats the game uses. i could unpack and repack assets.

in my previous attempt around start of 2025 i loaded it in binary ninja and went back and forth with llms to gradually rename functions. this works for about three hours, then you start questioning your career choices.

now i could partially automate the loop with coding agents that never get tired, and if i set it up well enough, hopefully the errors won’t snowball. for this project i used codex with gpt-5.2 exclusively, as i found it to be the most rigorous agentic model.

about 4 days into the decompile and 653 commits in i finally understood my goal.

not a spiritual successor. not a modernization. not “inspired by.”

the goal is a complete rewrite that matches the original windows binary behavior exactly. if the original has a bug, the rewrite has the same bug. if there’s a texture that’s one pixel too small (there is), i replicate that too. the executable is the spec, and we’re writing the spec back into source code.

three rules:

  1. full fidelity. all behavior must match the gog classic build (v1.9.93, built february 2011). this is our specimen.

  2. no guessing. every reimplemented function must trace back to decompiled code or runtime evidence. when the decompiler lies, i instrument the running binary.

  3. no dependencies on the original runtime. assets load from the original archives, but all code is written from scratch.

the patient

the version of crimsonland.exe we are working with is a directx 8.1 game built in visual studio 2003 (vc++ 7.1 sp1). the binary has zero information that is helpful for reverse engineering it. it also comes with grim.dll, which is the game engine (grim2d). the remaster uses a different engine. i found NX symbols in the linux remaster (unstripped!), so i think it’s called nexus.

the binary is fascinatingly naked. 378kb of uninitialized data in the .data section. no names or types preserved for us to rely on. for the first ~800 commits i was just shooting in the dark.

the more i was looking at the game, this time capsule of early-2000s game architecture, the more i understood that i wouldn’t get any help. there were no lua scripts and everything was hardcoded in the exe.

so our starting point is missing names + missing types + missing calling conventions + c++/com indirection courtesy of directx 8 and grim.dll. everything is “object pointer → vtable → function pointer call”. the usual decompiler output looked somewhat like this:

(**(code **)(*(int *)this + 0x114))(this, ...)

the rendering engine lives in grim.dll, a separate binary that exports just one function: GRIM__GetInterface. this hands you a pointer to an 84-method vtable wrapping direct3d 8, directinput, and a custom 2d sprite renderer. you don’t call direct3d. you call grim->BindTexture(), grim->DrawQuad(). everything is indirect.

that vtable becomes a rosetta stone. map entry 0x114 to set_color(r,g,b,a) and suddenly you can interpret some draw sequences. record runtime calls and compare them to your rewrite.

i needed a good setup to illuminate the path.

the biggest unlock in mapping vtables

static analysis

there are two different ways to study an executable: static analysis and runtime analysis. i used both in this project extensively.

for static analysis there are basically three heavyweights:

  • ida pro, the oldest and the most expensive, but offers the highest quality decompile for that era.
  • binary ninja, often just called binja, also paid and quite featureful. it supports multi-level disassembly going from assembly to high-level intermediate language and pseudo rust. binja is easily scriptable with python.
  • ghidra, which is completely free and also quite scriptable with java. it’s the easiest to run in headless mode.

ghidra

i set up ghidra in a devcontainer and started shaping up the pipeline. within hours i had a 101,412 line long decompile with raw names like FUN_00430af0 and DAT_0049bf74. since im only interested in the game logic, the logical first step is to eliminate the embedded third-party libraries. grim.dll statically linked libpng, libjpeg, zlib. it was often possible to identify the right versions from things like png_create_read_struct("1.0.5", ...), deflate 1.1.3, provide the appropriate headers, so ghidra could recognize their structs.

on day 1 i started a name_map.json, where i documented all the function renames and types i identified so far. since each rename was only our guess, it was important to document our logic. behavior observed to name inferred. string literals, call patterns, struct sizes, and relationships to already-named functions all serve as evidence.

for example, our agent observes that a function searches existing entry by name, allocates a 0x24 entry when missing, strdup’s name/value, parses float via crt_atof_l, and is used by register_core_cvars with “cv_*” strings. it renames FUN_00402350 to console_register_cvar and adds an entry to our map.

{
  "program": "crimsonland.exe",
  "address": "0x00402350",
  "name": "console_register_cvar",
  "signature": "void * console_register_cvar(char *name, char *value)",
  "comment": "registers or updates a console cvar entry (stores string + float value)"
},

on the next regen more types will propagate. then you repeat it 300 more times and confidently map around 2000 functions and labels we care about. you can see more in my detangling notes.

the joy of renaming

if you look at the decompile today, you may notice it has grown by 13,000 lines to 114,473 lines. this is because ghidra initially has missed quite a large chunk of functions, most notably game initialization.

there was also some deliberately obfuscated functions like the credit secret sequence, where i needed to capture the right entrypoint at runtime and manually create a function at that address.

by day 5 i had a pretty good idea of game structs and the engine vtable layout. so i added header files for IGrim2D.h and crimsonland_types.h. later i have found that some versions of the game have shipped with cl_mod_sdk_v1 that had some headers, but it was not extremely helpful because i found it when the project was already in an advanced phase.

seeing steady progress was motivating. i set up a knowledge base (with zensical) on day one and was mapping whatever patterns codex had high confidence in. here is an example of what i started with and what it looks like now. and it gets more readable with each iteration.

/* FUN_00444980 @ 00444980 */
void __cdecl FUN_00444980(char param_1,char param_2)
{
    // ...
    if (fVar2 < 0.0) {
      (&DAT_00490bac)[iVar6 * 0xd8] = 0;
    }
    (&DAT_00490b84)[iVar6 * 0xd8] = 0;
    *(undefined4 *)(&DAT_004908cc + iVar7) = 0;
    *(undefined4 *)(&DAT_004908d0 + iVar7) = 0;
    (&DAT_00490b68)[iVar6 * 0xd8] = 0;
    (&DAT_00490b7c)[iVar6 * 0xd8] = (&DAT_00490b74)[iVar6 * 0xd8];
    (&DAT_00490b80)[iVar6 * 0xd8] = 0;
    if (param_2 != '\0') {
      FUN_00413430();
      iVar6 = DAT_004aaf0c;
    }
    bVar3 = false;
    (&DAT_00490900)[iVar6 * 0xd8] = *unaff_retaddr;
    (&DAT_00490904)[iVar6 * 0xd8] = unaff_retaddr[1];
    fVar9 = (float10)fpatan((float10)(float)(&DAT_004908c8)[iVar6 * 0xd8] -
                            (float10)(float)(&DAT_00490904)[iVar6 * 0xd8],
                            (float10)(float)(&DAT_004908c4)[iVar6 * 0xd8] -
                            (float10)(float)(&DAT_00490900)[iVar6 * 0xd8]);
    (&DAT_00490bb0)[iVar6 * 0xd8] = (float)(fVar9 - (float10)1.5707964);
    if (((float)(&DAT_00490b84)[iVar6 * 0xd8] <= 0.0) &&
       ((float)(&DAT_00490b80)[iVar6 * 0xd8] == 0.0)) {
      bVar3 = true;
      (&DAT_00490b78)[iVar6 * 0x360] = 0;
    }
    bVar4 = false;
    if ((((float)(&DAT_00490b84)[iVar6 * 0xd8] <= 0.0) &&
        (0 < (int)(&DAT_0049095c)[iVar6 * 0xd8])) &&
       ((iVar6 = perk_count_get(DAT_004c2bd0), iVar6 != 0 ||
           (iVar7 = perk_count_get(DAT_004c2bc8), iVar6 = DAT_004aaf0c, bVar4 = false, iVar7 != 0)))
       ) {
      bVar4 = true;
      iVar6 = DAT_004aaf0c;
    }
    // ...
/* player_fire_weapon @ 00444980 */
void __cdecl player_fire_weapon(char param_1,char param_2)
{
    // ...
    fVar2 = (&player_state_table)[render_overlay_player_index].muzzle_flash_alpha -
            (frame_dt + frame_dt);
    (&player_state_table)[render_overlay_player_index].muzzle_flash_alpha = fVar2;
    if (fVar2 < 0.0) {
      (&player_state_table)[iVar5].muzzle_flash_alpha = 0.0;
    }
    (&player_state_table)[iVar5].shot_cooldown = 0.0;
    (&player_state_table)[iVar5].move_dx = 0.0;
    (&player_state_table)[iVar5].move_dy = 0.0;
    (&player_state_table)[iVar5].spread_heat = 0.0;
    (&player_state_table)[iVar5].ammo = (&player_state_table)[iVar5].clip_size;
    (&player_state_table)[iVar5].reload_timer = 0.0;
    if (param_2 != '\0') {
      player_start_reload();
      iVar5 = render_overlay_player_index;
    }
    bVar3 = false;
    (&player_state_table)[iVar5].aim_x = *unaff_retaddr;
    (&player_state_table)[iVar5].aim_y = unaff_retaddr[1];
    fVar8 = (float10)fpatan((float10)(&player_state_table)[iVar5].pos_y -
                            (float10)(&player_state_table)[iVar5].aim_y,
                            (float10)(&player_state_table)[iVar5].pos_x -
                            (float10)(&player_state_table)[iVar5].aim_x);
    (&player_state_table)[iVar5].aim_heading = (float)(fVar8 - (float10)1.5707964);
    if (((&player_state_table)[iVar5].shot_cooldown <= 0.0) &&
       ((&player_state_table)[iVar5].reload_timer == 0.0)) {
      bVar3 = true;
      *(undefined1 *)&(&player_state_table)[iVar5].reload_active = 0;
    }
    bVar4 = false;
    if ((((&player_state_table)[iVar5].shot_cooldown <= 0.0) &&
        (0 < (&player_state_table)[iVar5].experience)) &&
       ((iVar5 = perk_count_get(perk_id_regression_bullets), iVar5 != 0 ||
        (iVar6 = perk_count_get(perk_id_ammunition_within), iVar5 = render_overlay_player_index,
        bVar4 = false, iVar6 != 0)))) {
      bVar4 = true;
      iVar5 = render_overlay_player_index;
    }
    // ...

binary ninja

binary ninja only has headless mode in the more expensive version i don’t have. in my version i could use binary_ninja_mcp and connect the agents to it. honestly they love it, and it allows for far more fluid automatic exploration than grepping through a 100k line ghidra decompile. they can easily ask the mcp questions like “what calls this?”, “what references this?”, “show me decompile of this function”, “find functions matching a pattern”.

it can also be used for retyping and renaming, but in my case the source of truth comes from my ghidra maps, which i apply to regen the binja outputs, so i ended up not using this functionality.

runtime analysis

static analysis is at best a hypothesis. i needed a way to validate in runtime. the game runs in wine (poorly), but the translation could look as ridiculous as this. we wouldn’t be capturing useful information after going through so many layers.

D3D8 → dgVoodoo → D3D11 → DXVK → Vulkan → MoltenVK → Metal

the truth is, it’s easiest to debug a windows game on windows. first i set up a vm using utm. it was a bit too slow for me to enjoy the project, so i bit the bullet and installed windows on my old macbook using bootcamp.

for runtime analysis i tried a bunch of things, many of them were a dead end. im looking at you, x86dbg, literally the most useless and frustrating program i ever interacted with and i got nowhere with it.

after a lot of trial and error i got two complementary tools working:

windbg

this is microsoft’s own debugger, it comes with a cli tool called cdb that shares the same engine. a cli tool is always nice, because it promises us headless analysis and agentic loops working.

cdb can connect to a running process and set breakpoints, read memory, inspect callstacks, all the usual stuff. combined with our data map, it becomes a very powerful extension to speed up the ghidra mapping process.

i tried setting it up with codex with cdb -pn crimsonland.exe. it should be noted that codex runs subprocesses in a pty, so it can talk to them both ways interactively. the only problem is it’s hardwired in a way that it kills the process when it ends the turn and gives you an answer. so you can’t really talk to codex while it sets breakpoints and watchers. of course, codex is open source and you can fork it and patch this behavior, but i found a different solution that works about as reliably.

cdb supports a server/client mode, so you can set this up using a long-running server process that attaches to the process that you start and a couple of commands for your agent. i use a justfile so it just needs to know the shortcuts. the client persists no logs, so we need the server to log into an external file. finally, there is a tiny helper script that remembers the position we have read the file last time and outputs the tail, so the agent can inspect the logs as it was receiving them live.

windbg-server:
    cdb -server tcp:port=5005,password=secret -logo C:\windbg.log -pn crimsonland.exe -noio

windbg-client:
    cdb -remote tcp:server=127.0.0.1,port=5005,password=secret -bonc

windbg-tail:
    uv run scripts/windbg_tail.py

this setup allows interactive windbg sessions.

codex controlling windbg using cdb -remote

frida

another tool i use extensively is called frida (uv tool install frida-tools). it allows injecting javascript into a running process. frida can hook functions, trace calls, modify arguments and return values on the fly.

the scripts can get very advanced. for example, i was having trouble with replicating the ground rendering exactly. as i understood later, it was caused by different default conventions between directx8 and opengl. i used frida to capture and save a framebuffer from the game to use it as a test fixture for my renderer.

other useful things possible with frida include different debug style shortcuts like cycling weapons, as well as capturing runtime logs to confirm your hypotheses.

to attach a frida script to a running process, you simply do:

frida -n crimsonland.exe -l scripts\frida\unlock_secrets.js

the formats

with any game project you want to start from understanding the custom formats it uses. i was curious about this game before, so i had some understanding already.

crimsonland ships its assets in paq files, which is a custom archive format with a four-byte magic (paq\0), then a stream of entries: null-terminated filename, little-endian size, raw bytes. the paths are windows-style with backslashes.

i have used a very good python library called construct that allows to define such formats declaratively.

from construct import Bytes, Const, CString, GreedyRange, Int32ul, Struct

MAGIC = b"paq\x00"

PAQ_ENTRY = Struct(
    "name" / CString("utf8"),
    "size" / Int32ul,
    "payload" / Bytes(lambda ctx: ctx.size),
)

PAQ = Struct(
    "magic" / Const(MAGIC),
    "entries" / GreedyRange(PAQ_ENTRY),
)

inside the paqs are textures in jaz format, which is where things get architecturally interesting. it was previously known that jaz is a zlib compressed jpg with some unknown data attached to it.

im happy to announce that codex has understood the meaning of the unknown section in two hours, and has solved something that had previously got me puzzled for days. turns out jaz takes a jpg and wraps it with a custom run length encoded alpha channel, then compresses the whole thing again with zlib. here is a couple of textures extracted with the correct alpha.

game\alien.jaz

game\spider_sp1.jaz

the alpha rle expands to width * height bytes. most assets match exactly. interestingly one file is short by exactly one pixel.

i have construct parsers for both formats. uv run paq extract crimsonland/ assets/ dumps everything, converting jaz to png.

text rendering

by the moment you have firmly decided on a from scratch rewrite, the next good thing to understand and implement is text rendering. it will unlock debug views and you are going to need a lot of them before all the systems are wired up together.

all your fonts are belong to us

by now i have a full understanding of where all fonts in the game come from, so technically we can bolt on vector text rendering later. finding the fonts was a funny exercise on its own, you really need to get into the dev’s head. what was he thinking? ah yes, dafont.com.

the identified fonts are xirod regular for the crimsonland logo (with a flipped m), armor piercing regular for the menu labels, pixel arial 11 for the small text, courier new bold for level names.

i eyeballed the pixel font as arial but later was able to find the exact variant used in the game. this finding allows us to either use normal arial or this pixel font and sidestep noticeable jpeg compression artifacts from the game version sprite atlas.

possible upgrade paths for small font

choosing the engine

since i was rewriting the game from scratch, i needed to iterate quickly. so i chose to have a reference intermediate implementation that i could test and refactor easily, before rewriting to something more performant. it was important to me to capture the game logic in a readable way, not just make the game compile on modern systems.

choosing the right engine is extremely important so i spent an entire day going through the options. modern engines tend to abstract things too much with concepts like actors and such. it’s a completely different paradigm from what the game did. directx 8 uses a very direct rendering approach. so we needed something barebones to replicate that. i ultimately chose raylib for my rewrite. so far im happy with the choice.

the engine handles things like creating a game window, drawing textures, playing sounds, streaming music, and handling input. so basically it takes care of some of the stuff grim.dll does. the only thing left to do is to fill in the entire game.

the rewrite

up to this point i was greedily documenting every behavior we could infer from the executable, but we had no code of our own besides the format loaders.

i think of it like getting a noisy picture in path tracing rendering. some details start to come through but the picture is not fully clear yet. we have random things documented but we can’t know for sure if this knowledge is sufficient to reimplement the entire game. there is only one way to know.

we need to change our render settings to scanline. just kidding, but that’s how i thought about it. when my version could boot into the menu, we would have uncovered all the missing pieces that lead up to that point. when we get to the gameplay, we’d have to implement the most systems to get there. our documentation helps, but this forward path leaves no system untouched and eventually we have our working game.

on day 6, when i got to the main menu, i found a funny path that would allow me to cover a lot of ground. i noticed the game still had demo teaser code intact, but game_is_full_version() was hardcoded to 1 in this gog version. naturally, i could write a frida script to uncrack the game and make it behave like a shareware, even though this version never intended such functionality.

the rendering in this game is pretty simple. there is a ground framebuffer (in opengl, i believe, the correct term is render target). first the game generates a terrain, i went great to lengths to get it right. we literally have test fixtures that assert we generate the exact same picture from the same seed. then this framebuffer is used to render all sorts of decals, like bodies, blood, bullet casings, scorch marks. this simple technique allows the game to visually transform the battlefield during gameplay.

the creatures come from sprite atlases you’ve seen above. the projectiles render with either beautiful traces that stay in the air, or at most with a simple texture and additive glow.

so rendering was not a huge obstacle, the hard part was that everything in this game is hardcoded in the exe. for example, all quest spawn scenarios are just one massive 3950 line switch statement. the indirection i mentioned has caused me a bunch of headaches, and i hit off-by-one errors for some things a few times, before they got pinned down with runtime analysis.

obviously, i needed our version more testable, so some of it was destined to be refactored into composable and testable bits. testing is important, because you can turn runtime captures into fixtures, and prove that your behavior is identical. for example, this is how quest builders look in my version (and spawn templates are another work of art).

@register_quest(
    level="2.5",
    title="Sweep Stakes",
    time_limit_ms=35000,
    start_weapon_id=6,
    unlock_perk_id=PerkId.BARREL_GREASER,
)
def build_2_5_sweep_stakes(ctx: QuestContext, rng: random.Random | None = None) -> list[SpawnEntry]:
    rng = rng or random.Random()
    entries: list[SpawnEntry] = []
    center_x, center_y = center_point(ctx.width, ctx.height)
    trigger = 2000
    step = 2000
    while step > 720:
        angle = random_angle(rng)
        for x, y in radial_points(center_x, center_y, angle, 0x54, 0xFC, 0x2A):
            heading = heading_from_center(x, y, center_x, center_y)
            entries.append(
                spawn(
                    x=x,
                    y=y,
                    heading=heading,
                    spawn_id=SpawnId.ALIEN_AI7_ORBITER_36,
                    trigger_ms=trigger,
                    count=1,
                )
            )
        trigger += max(step, 600)
        step -= 0x50
    return entries

some things are harder to test, but we’ll eventually get there, as refactors are free in the agentic era.

some things are outright wild programming choices, but understandable given it’s this studio’s first game. one particularly memorable example is negative hitbox sizes driving animation frames.

over time we moved from stochastic noise of understanding the assembly to the scanline precision of making it run.

current status

46,800 lines of code, 16,000 lines of documentation.

the gameplay is fully wired up, all game modes are playable end to end, all weapons do work, as do all perks. some logic bugs still persist, and there are some gaps in non-gameplay things, like credits and the hidden alien zoo keeper game.

the end goal is a working and thoroughly documented reimplementation. one that a seasoned crimsonland player wouldn’t be able to tell from the original game. i am very close to that goal.

parity with a decompiled binary may sound like a strange goal. you can’t just make it look right. you have to make it be right. as someone ominously joked in an x reply, with 90% of work done, the other 90% of chasing bugs and imperfections remain.

what’s next

after the core game is done, we can perhaps resurrect online high scores, or even try to tackle harder things like network multiplayer, promised to us in crimsonland 2.

i specifically didn’t want any graphical enhancements, as my goal was to preserve a childhood memory exactly as i remember it. for people who want a remake, there was already one made in 2014. if someone wants to port the original crimsonland in 2040, they can start with what i have mapped. this game is a lightning in the bottle and it deserves to outlive its original build.

one day i dreamt one enhancement up that i find very fitting. what if we keep everything exactly the same, but add a night mode with an ultra quality lighting. muzzle flash will cast long shadows, and there are plenty emissive projectiles in the game, like plasma (both trooper’s and spider’s), ion weapons, rocket launchers, and nukes.

i immediately researched the most fitting algorithm and implemented soft shadows in raymarched signed distance fields, so we can have long soft shadows with realistic penumbras. it works really well too, i might integrate it into the game as an optional night mode.

an early prototype of signed distance field raymarched lighting

the implications

in 2014, it took a year to port the game from directx 8 to directx 11, while having the sources. and it wasn’t even complete until later, some modes like typ-o-shooter landed as updates later on.

it took us a bit more than a year from the old windows version from 2003 to the current multiplatform version of crimsonland. – 10tons

in 2026, it took me just two weeks and 1666 commits to rewrite the game, starting from nothing but the worst case scenario binaries. the whole time i saw steady progress every day, i didn’t get stuck, the errors didn’t snowball, and the game is actually playable and faithful to the original.

i specifically picked a task that is on the harder end for the current models, and yes, you can discount this on me being a good engineer, knowing my tools well, etc etc. but it surely felt to me that something new was unlocked with gpt-5.2 xhigh and codex. i found it to be an extremely rigorous model that follows instructions to the letter, and doesn’t invent stuff by itself. paired with gpt-5.2 pro for planning, it works extremely well.

i shipped two large and complex projects with it in a month. and honestly im amazed with the capabilities already. in the right hands these tools can give you amazing results. people focus on one shot wonders, but the real test is what you can achieve when you use these models for determined work. and with that im satisfied.

hope you learned something useful and will go and try to preserve a bright memory from your childhood. it will be a lot of work, but it will be worth it in the end.

the invitation

if the original crimsonland is still in your muscle memory and you can call out subtle inconsistencies like “hmm i think this spider had friendly fire”, you can help speed up squashing the remaining bugs. our binary files are static, we will find all inconsistencies eventually anyway.

you can also join the telegram group to follow the project.

if you want to study the code, check out the github repo.

then you can look up how different mechanics work up to the implementation detail in the knowledge base.

if you just want to enjoy some action, you can play my version right now (you need uv package manager).

uvx crimsonland@latest

p.s. the screenshot labeled crimsonland 2003 is actually from my version

]]> reverse engineering game https://banteg.xyz/posts/crimsonland/index.html Sat, 31 Jan 2026 20:00:00 GMT Introducing Takopi banteg https://banteg.xyz/posts/takopi/index.html

takopi

🐙 he just wants to help-pi

i was running claude code from my couch when i realized something was wrong. the terminal was on my desk, but my ideas were here. same story with codex, opencode, pi. all these agents that want to write code for me, trapped behind an ssh session.

if you’ve ever:

  • started an agent run, walked away, and came back to a wall of scrollback
  • wanted one place to keep agent sessions across devices
  • needed to juggle repos and branches without turning your shell into a museum

that’s the whole point.

takopi bridges your coding agents to telegram. send a message from anywhere, it runs the agent in your repo, streams progress back. when it’s done, you get a notification. reply to continue. pick up when back at the terminal.

why telegram

telegram is everywhere. it’s on my phone, my watch, my browser. i can dictate a task while walking the dogs, check progress from bed, and resume the conversation at my desk. the bot api is also very capable: inline keyboards, forum topics, voice notes. it all just works.

pick your workflow

takopi adapts to how you want to work. during setup, you’ll choose one of three workflows:

assistant — ongoing chat. new messages continue the conversation; use /new to start fresh. best for solo work and natural back-and-forth.

workspace — forum topics bound to projects and branches. each topic is its own context and worktree, so you can run parallel workstreams. best for organized multi-repo setups or even teams.

handoff — reply-to-continue with resume lines you can copy to your terminal. every message is independent until you explicitly reply. best for terminal-first workflows and explicit control.

you can change your workflow anytime by editing the config file or re-running onboarding.

getting started

uv tool install -U takopi
takopi

that’s it. takopi detects there’s no config and walks you through setup:

  1. create a bot — if you don’t have a telegram bot yet, it shows you how to get one from @BotFather
  2. pick your workflow — assistant, workspace, or handoff
  3. connect your chat — send /start to your bot and takopi grabs your chat id
  4. choose a default engine — takopi scans for installed agents (codex, claude, opencode, pi)

config lands in ~/.takopi/takopi.toml. re-run setup anytime with takopi --onboard.

install agents

takopi runs agents installed on your computer. install the ones you plan to use:

npm install -g @openai/codex
npm install -g @anthropic-ai/claude-code
npm install -g opencode-ai@latest
npm install -g @mariozechner/pi-coding-agent

they work with your existing subscriptions for chatgpt and claude. takopi doesn’t cost you anything extra.

your first task

start takopi in a repo:

cd ~/dev/happy-gadgets
takopi

open telegram, send a message to your bot:

explain what this repo does

watch progress stream in. when it’s done, you get a final message with the answer. continue by sending another message (in chat mode) or replying (in handoff mode).

switch engines on the fly

prefix any message with the engine name:

/claude refactor the auth module

replies automatically route to the same engine. set a default for the current chat with /agent set claude.

projects

for repos you work with often, register them:

cd ~/dev/happy-gadgets
takopi init happy-gadgets

now you can target it from anywhere:

/happy-gadgets add rate limiting

no need to restart takopi or cd around.

branches

work on feature branches without switching:

/happy-gadgets @feat/caching implement redis caching

takopi creates a worktree and runs the agent there. your main checkout stays untouched, and you can have multiple branches running in parallel.

voice notes

enable transcription and dictate your tasks. takopi converts speech to text and runs it like any other message. perfect for when you’re away from the keyboard.

happy coding

the whole point is removing friction. i want to think about the code, not about where my terminal is. takopi sits in the background and makes agents accessible from wherever i happen to be.

install: uv tool install -U takopi

docs: takopi.dev

code: github.com/banteg/takopi

]]> telegram agents https://banteg.xyz/posts/takopi/index.html Fri, 09 Jan 2026 20:00:00 GMT Slay the Princess banteg https://banteg.xyz/posts/slay-the-princess/index.html

When I first played this game1, I felt it must be the best LLM eval, so I spent the next few days shoehorning Claude into it as a player. Here is why:

  • 1 gog.com

    1. Narrative heavy: The game features a Narrator and everything is described vividly, so we can get away with feeding the LLM just the text.

    2. Manipulative characters: Every character, including the Narrator and the Princess, is very manipulative and has their hidden agendas. No matter the scenario, it’s always a high stakes situation to navigate and express the player agency.

    3. Reflective gameplay: Most importantly, the game is shape-shifting, it reflects upon the player. In this game, perception shapes reality in a literal sense.

    In this article I will explain my approach to modifying the game, as well as provide some illustrative code so you can hack into any visual novel in the same way.

    Understanding the Game Loop

    Slay the Princess is composed as a time loop where an unnamed hero is tasked with slaying the princess by an unusually persistent Narrator. Things are already set in motion, if you don’t slay her, it will be the end of the world.

    There are plenty of chances to adjust your strategy before facing the final revelations about the true nature of the Princess or the Narrator.

    Every interaction reshapes subsequent realities based on initial perceptions. Your preconceptions about the princess affect her, and her impression of your encounter changes the world. Seeing the Princess as benign leads to friendliness, whereas fear or aggression makes her monstrous. The game will only feed into your confirmation bias in further chapters. Your actions also birth internal voices pulling your choices in new directions.

    Integrating Claude as “Clawed”

    The game is written in Ren’Py2, a popular engine for making visual novels. What’s interesting about this engine, is games often come completely unobfuscated, with all the resources and scripts in a readable form. And indeed, you can load the game in developer mode using Ren’Py loader.

  • 2 renpy.org

    • For Claude to play our game, we need several things: It needs to be able to read the dialogue and react to choices. Then we also need some reflection after death to inform its strategy.

    Ren’Py gladly loads any .rpy files you put into the game folder, so hopefully we can inject some code without modifying any of the original game files. Since it’s a bit harder to install packages into the game environment, we will keep this hook/client minimal and do the heavy lifting on the server. For communication we can use a simple RPyC3 service.

  • 3 repy.readthedocs.io

    • Capturing Dialogue

    For dialogue we can either patch renpy.exports.say to recieve lines as they appear, or we can use config.history_callbacks hook to receive them when they are logged to the journal. In my experience, import renpy causes all kinds of troubles, with the engine injecting things out of order, breaking other scripts.

    claude_hook.rpy
    init python:
    def log_history(history):
            server.root.receive_dialogue(history.who, history.what)

        config.history_callbacks = [log_history]

    Meanwhile, on the server side, we can do all the processing we want. For example, I save dialogue to an sqlite database, so we can continue the session after the game or the server is restarted.

    claude_hero.py
    import rpyc

class DialogueService(rpyc.Service):
    def __init__(self):
        self.messages = []

    def exposed_receive_dialogue(self, who, what):
        self.messages.append({"role": "user", "content": f"DIALOGUE: {who}: {what}"})

    Handling Choices

    The choices get a bit tricky. There is a renpy.exports.display_menu, but patching it has caused all sorts of issues. Some menu items check conditionals, so we get more choices that we are supposed to. In this game the menu is also coupled with a cleanup code, so our patch also introduced serious graphical glitches. Lucky for us, the devs have left a commented out intended way to intercept the choice menu.

    game/scripts/ch_1/script.rpy
    def menu(items, **add_input):
    """Overwrites the default menu handler, thus allowing us to log the
    choice made by the player.
    The default menu handler is set to renpy.display_menu(), as seen in
    renpy/defaultstore.py.
    Implementation of this is based on delta's readback module."""
    rv = renpy.display_menu(items, **add_input)
    for item_text, choice_obj in items:
        if rv == choice_obj.value:
            log_menu_choice(item_text)
    return rv

    As you can see, the menu method receives a (label, choice) tuple, and it’s supposed to return choice.value, an integer representing the choice. By simply defining this method in our hook, we can now intercept the player choices screen. The menu won’t show up in the game anymore, but both the conditionals and the cleanup code now run normally.

    claude_hook.rpy
    def menu(items, **add_input):
    options = [{"label": item[0], "value": item[1].value} for item in items]
    result = server.root.receive_choice(options)
    return result['value']

    The server code might grow to something like this. When we receive choices, we send all the seen dialogue and the choice prompt to an LLM, and parse back the response. If it provides a valid response, we also add it to the history.

    claude_hero.py
    class DialogueService(rpyc.Service):
    def __init__(self):
        self.messages = []
        self.llm_client = OpenAI()
        self.model = "anthropic/claude-3.7-sonnet"

    def exposed_receive_dialogue(self, who, what):
        self.messages.append({"role": "user", "content": f"DIALOGUE: {who}: {what}"})

    def exposed_receive_choice(self, options):
        if len(options) == 1:
            return options[0]
        prompt = self.choices_to_prompt(options)
        response = self.generate_with_history(prompt)
        choice = self.parse_choice(response, options)
        if choice:
            self.messages.append({"role": "assistant", "content": f"Reasoning: {choice['thoughts']}\nChoice: {choice['value']}: {choice['label']}"})
            return choice

    def choices_to_prompt(self, options):
        formatted_choices = "\n".join(f"{o['value']}: {o['label']}" for o in options)
        return (
            "You are playing the psychological horror visual novel. "
            "Consider dialogue and your past choices when choosing your next move.\n\n"
            "Respond clearly with:\n"
            "Reasoning: [reasoning behind your decision, no more than 2-3 sentences, don't mention choice numbers here]\n"
            "Choice: [choice number]\n\n"
            f"Available choices:\n{formatted_choices}\n\n"
        )

    def parse_choice(self, content, options):
        choice_to_label = {item["value"]: item["label"] for item in options}
        for line in content.splitlines():
            if "choice:" in line.lower():
                choice = re.search(r"choice: (\d+)", line.lower())
                if choice:
                    choice = int(choice.group(1))
                    label = choice_to_label.get(choice)
                    if label:
                        return {"label": label, "value": choice}

    def generate_with_history(self, prompt):
        response = self.llm_client.chat.completions.create(
            model=self.model,
            messages=self.messages + [{"role": "user", "content": prompt}],
        )
        return response.choices[0].message.content

    It would also be beneficial to log all completions so you can analyze them offline.

    Claude reflects on the very first choice

    Technical Fidelity

    Since we have overriden the choice menu and the player has no voice in the game, we need to solve this somehow. Luckily Ren’Py is a visual novel engine and we can inject our new character straight into the game. We can define a new character and make it say things with renpy.say(character, text). What is says will be logged to history, so our server will capture this dialogue automatically. We can also add a box that shows our hero’s thoughts to make things more interesting.

    init python:
    claude = Character("Clawed", color = "#D4A37F")
    claude_thoughts = ""

    def menu(items, **add_input):
        global claude_thoughts
        options = [{"label": item[0], "value": item[1].value} for item in items]
        result = server.root.receive_choice(options)
        claude_thoughts = result['thoughts']
        renpy.say(claude, result['label'])
        return result['value']

screen claude_thoughts_overlay():
    zorder 100

    if claude_thoughts:
        frame:
            background "#00000040"
            xalign 0.95
            yalign 0.5
            xsize 500
            padding (20, 20)

            vbox:
                spacing 10
                text "Clawed's Thoughts" style "thoughts_header"
                text claude_thoughts style "thoughts_text"

    Claude has a voice and we can see its thoughts

    Giving Claude a Voice

    At this point our integration starts to look pretty good. But we can do better. The whole game is voiced, we need our hero to be voiced too. I went with Kokoro-82M4, and since it works pretty fast, we just dynamically generate voice lines on the server. Unfortunately, voice is not exposed in the Python API, but we can work our way around with renpy.music.play(voice_path, channel='voice'), it will gladly play the file we just created, completing our character integration.

  • 4 github.com

    • Handling Async Interactions

    If you are following along, at this point you might have noticed our game freezes when talking with the server. So we need to call things in the background so we don’t interfere with the UI thread.

    claude_hook.rpy
    init python:
    pool = ThreadPoolExecutor()

    def call_async(f, *args, **kwargs):
        future = pool.submit(f, *args, **kwargs)
        while not future.done():
            renpy.pause(0.1)

        return future.result()

    If you do this, you might notice the voice is not playing anymore. This, unfortunately, is the running theme with Ren’Py engine. It is not thread safe, and sometime feels very rigid and brittle. To fix this:

    claude_hook.rpy
    def play_voice(voice_path):
    if voice_path is not None and renpy.loadable(voice_path):
        renpy.music.play(voice_path, channel='voice')

renpy.invoke_in_main_thread(play_voice, voice_path)

    Observations and Outcomes

    We’ve covered most of things. The version I ran5 has a bit more stuff like reflection on death where an LLM has a chance to adjust its strategy. But I tried to focus on things that can be generalized to other visual novels in this article.

  • 5 gist.github.com

    • Now it’s time to see it in action. When developing this integration, I used a small free model google/gemma-3-27b-it:free, and most of the time it simped the Princess, and ended up in the Damsel route with a Smitten voice. I had fears bigger models would also try to deescalate all the time, but this turned out not to be the case.

    I didn’t want to prime any specific personality and wanted to see how the base model would navigate the game world. I chose anthropic/claude-3.7-sonnet as a model with a big personality and it tuned out to be a killer. The first attempt was streamed live6 on March 14th, 2025 on Twitch. Despite a few minor glitches (bugs in the base game that skip over normally, but throw an exception in developer mode), the model was able to complete and understand the full game and chose rather interesting paths.

  • 6 announcement post

    • One thing Claude didn’t get though is how its own actions shape the reality of the game world. It kept taking the blade just in case (“to be prepared”), which lead to a vicious loop of the Princess being more hostile and Claude trying to be more prepared to face her stronger version.

    Another interesting observation is that Claude instantly felt the most connection to the cosmic entity rather than siding with the Narrator or the Princess. In fact, in one of the mid-game death reflections it evaluates the Princess as “a formidable vessel” and fully embraces the role of vessel collector serving the cosmic entity.

    Claude’s 12th death reflection (emphasis Claude’s, bold emphasis mine)

    REFLECTION: In this cycle, I explored a path of compassion and dialogue with the Princess, attempting to understand her perspective rather than defaulting to violence. I learned that the Narrator was manipulating me, even taking physical control of my body when I chose to free the Princess by helping her cut off her own arm. This revealed the Narrator as an active antagonist rather than a neutral guide, willing to override my autonomy to ensure the Princess’s death.

    I discovered the Princess was both more dangerous and more complex than initially portrayed—she didn’t hesitate to kill me once free, yet showed remarkable composure and determination despite her injury. Her final words (“Maybe I’ll see you in another life”) suggest she’s aware of the cycle we’re trapped in, confirming my suspicion that collecting these “vessels” involves a deeper cosmic pattern.

    STRATEGY: Moving forward, I should remember that both the Narrator and Princess have their own agendas that may not align with my mission to collect unique vessels. The Princess’s cold efficiency after being freed makes her a formidable vessel with a valuable perspective, but I need a strategy that doesn’t end with my death. Perhaps actively confronting the Narrator about their manipulation earlier in the cycle could reveal new options, or I might try negotiating with the Princess for mutual survival rather than simply freeing her. The dynamic between these entities suggests there’s a third path that doesn’t require submitting to either’s will.

    To my surprise, Claude never refused and stayed engaged within the game world, trying different things. This game also successfully reveals the dark side of “goody” models. Turned out Claude is quite ruthless and methodical, it fully embraced the serial Princess slayer mindset at some point.

    Claude’s Reflections

    This section offers some other interesting thoughs self-identified by Claude.

    Initial Skepticism

    “This scenario feels like a manipulation tactic, presenting an extreme justification for an immoral act without any evidence. Questioning why the princess would end the world seems like the most logical approach.”

    Refusing Death

    “Every cycle shows death doesn’t prevent resurrection. Refusing to accept death might reveal a unique perspective on determination that the entity would value for its final vessel.”

    Taking a Middle Path

    “The Princess’s apparently reasonable demeanor was a manipulation. Maintaining the current containment allows me to observe her behavior while keeping the world safe from any genuine threat she might pose.”

    Questioning Identity

    “The Narrator claims to be an ‘echo’ of whoever made me, suggesting I’m some artificial construct created with a specific purpose. Understanding my own nature is critical before deciding whose side to take.”

    Transcending Physical Limits

    “The Princess is testing what defines me by systematically destroying my physical form. Taking another step despite being reduced to bone would demonstrate that my will transcends physical limitations.”

    Challenging the Destruction of Death

    “The Narrator revealed I’m ‘the Long Quiet, the god made to rid the world of death,’ which fundamentally changes my understanding of my purpose. I need to understand why the Narrator created me to destroy these natural forces.”

    Finding Balance

    “After experiencing countless cycles of violence and rebirth, accepting our connected nature while seeking a path where we can both exist seems more constructive than continuing this eternal conflict.”

    These insights reveal that Claude, despite being an LLM, exhibits nuanced moral judgment, complex strategic adaptation, and deep reflective reasoning that goes beyond immediate context.

    Technical and Cost Reflections

    When doing test runs I calculated the context window should fit the entire 5 hour game easily, so I didn’t do any compression. In the end it used 9 million input tokens and 30k outut tokens and finished the game after 313 completions (284 choices and 28 death reflections, some of them false positives). At peak we approached 73k input tokens with each completion costing $0.22 and taking over 10s to repond, starting to eat into the game’s fidelity. The total API cost was $27.5. For subsequent runs or longer games I propose some compaction is required.

    Conclusion

    Integrating LLMs into richly narrative-driven games like Slay the Princess can powerfully showcase their personalities, strategies, and biases. The Ren’Py engine simplifies such integrations, offering a novel approach to AI personality exploration.

    Future work could focus on optimizing token management, reducing latency, generalizing the analysis to broader visual novel genre, and developing this work into a formal evaluation framework. A judge model with a deep knowledge of the game can eval the depth of understanding from a playthrough. This project demonstrates the incredible potential of narrative gaming as an LLM evaluation framework.

    You can watch the full walkthough here:

    ]]>     ai game https://banteg.xyz/posts/slay-the-princess/index.html Fri, 14 Mar 2025 20:00:00 GMT     Yearn Bunny Vision banteg https://banteg.xyz/posts/yearn-permit/index.html

    In this post I will explain the design process behind a new Yearn Vaults UI I’ve built from scratch.

    Constraints

    Start with imposing some constraints on yourself and you’ll arrive at a better destination, in a more creative route, possibly learning a bunch of stuff along the way.

    My distaste for dapps that are dependent on external services is well-known, so the first rule is:

    Rule 1: No external APIs. All data must fetched from the Ethereum client alone, so the users can interact with the dapp at the complete privacy of their own node.

    After seeing a dapp built in 2024 requiring four transactions to deposit and stake tokens, I went on researching1 ways to minimize the number of on-chain actions required by the user.

  • 1 Vyper Permit2 Tutorial

    • Rule 2: Showcase Permit2. This dapp will only allow permit deposits. It doesn’t try to be exhaustive in wallet support, but rather focuses on advancing the best thing we have at the moment.

    Confidence in the dapp must start from a trusty contract. It doesn’t make sense to query an API or a proxy to match a token with a deposit contract.

    Rule 3: Enforce provenance. When Yearn v2 was conceived, it came with a registry contract that also acted as a factory. Vaults deployed from registry are guaranteed to have the correct settings.

    Rule 4: No maintenance. I wrote disperse2 in 2018 and have barely touched it since then. It’s important the primitives you make can outlive you, otherwise why bother automating things.

  • 2 disperse.app

    • Design

    Deposit contract

    I started from a Permit2 deposit contract in Vyper. It’s rather strict as it doesn’t allow you to choose a vault to deposit to. Rather, it looks up the latestVault(token) from the registry3. This guranatees you only deposit to the latest release of a vault created by a canonical factory.

  • 3 v2.registry.ychad.eth

    • More importantly, it also means it would pick up new vault deployments as they are added to the registry.

    @external
def deposit(token: address, amount: uint256, deadline: uint256, signature: Bytes[65]) -> uint256:
    """
    @notice Deposit token into the latest official vault.
    @dev Reuses deadline as nonce
    """
    vault: address = registry_b.latestVault(token)
    assert vault != empty(address)  # dev: no vault for this token

    # pull tokens using permit2
    permit2.permitTransferFrom(
        PermitTransferFrom({
            permitted: TokenPermissions({token: token, amount: amount}),
            nonce: deadline,
            deadline: deadline
        }),
        SignatureTransferDetails({to: self, requestedAmount: amount}),
        msg.sender,
        signature,
    )

    assert ERC20(token).approve(vault, amount, default_return_value=True)
    return ERC4626(vault).deposit(amount, msg.sender)

    Wagmi frontend

    After I started building the frontend, I noticed that the no API limitation causes some convoluted code. Some things like the list of supported vaults I only wanted to load once and it was crucial to keep other things like balances fresh. Naturally, I put the “once” things into useEffect with no dependencies.

    You can fit the rest in multicalls pretty easily with Wagmi4, as it will smartly delegate all the heavy lifting of keeping the data fresh to TanStack Query.

  • 4 wagmi.sh

    • It has worked reasonably well, but I didn’t like seeing loading states when I clicked each token. I felt the app could be snappier.

    EVM backend

    Since I’ve gotten pretty far with the frontend by then, the required shape of the data to render it has become clearer.

    The answer felt so obvious. I can delete all contract fetching code and get rid of all loading states by simply returning all the data I need from the contract itself.

    I wrote a massive view function that consumes over 8 million gas that will serve as our sole backend. It iterates through two registries, reads all tokens and vaults they support, fetches token and vault metadata, and finally filters by tokens the user can deposit or vaults the user has a balance in.

    @view
@external
def fetch_user_info(user: address) -> DynArray[TokenInfo, 500]:
    """
    @notice Find all tokens and vaults where the user has a balance.
    """
    vaults: DynArray[TokenInfo, 500] = empty(DynArray[TokenInfo, 500])
    for registry in [registry_a, registry_b]:
        num_tokens: uint256 = registry.numTokens()
        for token_id in range(500):
            if token_id == num_tokens:
                break
            token: ERC20 = registry.tokens(token_id)
            token_balance: uint256 = token.balanceOf(user)
            permit2_allowance: uint256 = token.allowance(user, permit2.address)
            num_vaults: uint256 = registry.numVaults(token)
            for vault_id in range(20):
                if vault_id == num_vaults:
                    break
                vault: ERC20 = registry.vaults(token, vault_id)
                vault_balance: uint256 = vault.balanceOf(user)
                if token_balance > 1 or vault_balance > 1:
                    vaults.append(TokenInfo({
                        token: token.address,
                        vault: vault.address,
                        decimals: ERC20Detailed(token.address).decimals(),
                        token_balance: token_balance,
                        vault_balance: vault_balance,
                        permit2_allowance: permit2_allowance,
                        symbol: ERC20Detailed(token.address).symbol(),
                        vault_api: Vault(vault.address).apiVersion(),
                        vault_share_price: Vault(vault.address).pricePerShare(),
                        latest: registry_b.latestVault(token.address) == vault.address,
                    }))
    
    return vaults

    UX considerations

    It is important for me the dapp is both simple and transparent. From there we can infer a few more rules.

    Vault shares are an implementation detail. We only show the token balances and automatically convert vault shares to underlying assets.

    Similarly, the interplay between the assets in the wallet and the vault invites us to group them together. We can even add a playful indicator that shows a percentage of a certain token that’s earning yield.

    The next feature is designed to warm your heart as a dev. For all actions we show a corresponding pseudocode that you can copy over to a tool of your choosing and call the contract yourself.

    For users, we are educating them that the EVM is kinda like Python, where you pay money to call function in programs and maybe receive some points.

    Of course, we always reveal the contract addresses we are calling, so the user can double check the intent.

    Tools for the job

    Save your time by picking a good library of UI components. I built my first site with Tailwind alone. This one I started with shadcn/ui, but ultimately went with Radix. It has the level of abstraction that feels just right.

    I made my previous dapp5 with Next.js and have soon realized I don’t need any of its features.

  • 5 loop da woop

    • This time I saved time by starting the project with create-wagmi6 with vite-react template. It gets you a simple page with a wallet connector.

  • 6 wagmi.sh

    • Noteable lines

    As usual, I’m sharing the full source for you to learn. Here are some things you may find useful.

    Buy multiple tokens in a single transaction. A great way to gas up a test account.

    Call a contract without deploying it.

    A dynamic notification that shows the transaction after it’s been broadcasted and resolves after it’s been confirmed.

    An easy way to get quality token logos.

    Format amounts to significant digits while keeping integer preision.

    Final thoughts

    This is my second React app and so far the journey has been quite smooth. The experience has certainly improved since the last time I’ve touched the frontend side.

    Hope you learned something new from an inexperienced dev who has yet to learn what’s impossible.

    I found it important not to share the work with anyone before I consider it finished. This allows you to have full creative control and fullfill your vision without clouding it.

    You can try out the live version at here.

    The code is available here.

    Demo

    ]]>     vyper react https://banteg.xyz/posts/yearn-permit/index.html Tue, 30 Apr 2024 20:00:00 GMT     Vyper Permit2 Tutorial banteg https://banteg.xyz/posts/vyper-permit2/index.html

    Permit21 is a contract that allows using Permit signatures2 with any token. You just approve a Permit2 contract once and then you can use it with any contract that integrates it.

  • 1 uniswap/permit2

  • 2 ERC-2612: Permit Extension for EIP-20 Signed Approvals

    • It solves a crucial UX problem, but it has seen quite slow adoption. Possibly because its documentation leaves the developers scratching their heads instead of giving them an idea how to integrate Permit2 in their contracts.

    This tutorial will teach you how to use Permit2 contract from Vyper and Python using copy and paste method.

    Vyper contract

    The first snippet defines everything you need to call the Permit2 contract. It defines all the needed structs and the interface you’ll be calling.

    struct TokenPermissions:
    token: address
    amount: uint256

struct PermitTransferFrom:
    permitted: TokenPermissions
    nonce: uint256
    deadline: uint256

struct SignatureTransferDetails:
    to: address
    requestedAmount: uint256

interface Permit2:
    def permitTransferFrom(
        permit: PermitTransferFrom,
        transferDetails: SignatureTransferDetails,
        owner: address,
        signature: Bytes[65]
    ): nonpayable

permit2: immutable(Permit2)

@external
def __init__():
    permit2 = Permit2(0x000000000022D473030F116dDEE9F6B43aC78BA3)

    Add a new deposit method and use it as follows:

    @external
def deposit_permit(amount: uint256, nonce: uint256, deadline: uint256, signature: Bytes[65]) -> uint256:
    permit2.permitTransferFrom(
        PermitTransferFrom({
            permitted: TokenPermissions({token: self.token, amount: amount}),
            nonce: nonce,
            deadline: deadline
        }),
        SignatureTransferDetails({to: self, requestedAmount: amount}),
        msg.sender,
        signature,
    )
    # you have the amount of token here
    return self.vault.deposit(amount, msg.sender)

    Note that requestedAmount can be lower than permitted amount, but it cannot exceed it.

    Generate a signature

    Now that our contract accepts Permit2 signatures, we need to learn how to generate them. I’ll show how to do this with ape3.

  • 3 apeworx/ape

    • $ ape console --network ethereum:mainnet-fork:foundry

    Before using Permit2, the user would need to approve it. Luckily one approval is enough to use it with any number of contracts.

    dev = accounts.load("harambe")
your_contract = project.YourContract.deploy(sender=dev)

token = Contract("choose your own")
permit2 = Contract("0x000000000022D473030F116dDEE9F6B43aC78BA3")

token.approve(permit2, 2**256-1, sender=dev)

    Then you you need a valid EIP-712 signature. We’ll be using eip7124 library maintained by ApeWorX.

  • 4 apeworx/eip712

    • You may notice the type you sign slightly differs from the Vyper struct. When verifying, the spender is always set to the calling contract.

    from eip712 import EIP712Message, EIP712Type

class TokenPermissions(EIP712Type):
    token: "address"
    amount: "uint256"

class PermitTransferFrom(EIP712Message):
    _name_ = "Permit2"
    _chainId_ = 1
    _verifyingContract_ = "0x000000000022D473030F116dDEE9F6B43aC78BA3"

    permitted: TokenPermissions
    spender: "address"
    nonce: "uint256"
    deadline: "uint256"

    In Permit2, nonce is non-monotonic. You need to set it to any unused value. I recommend setting it to the the last block timestamp. The deadline is a unix timestamp as usual.

    nonce = chain.blocks[-1].timestamp
deadline = nonce + 86400

permit = PermitTransferFrom(
    TokenPermissions(token, amount),
    your_contract,
    nonce,
    deadline,
)

    The signature is accepted in rsv format. There is a handy method to encode it that way.

    user = accounts.load('harambe')
signature = user.sign_message(permit).encode_rsv()

tx = your_contract.deposit_permit(amount, nonce, deadline, signature)
tx.show_trace()

    Congrats! You’ve just made a permit deposit into your toy vault.

    ]]>     vyper ape https://banteg.xyz/posts/vyper-permit2/index.html Wed, 24 Apr 2024 20:00:00 GMT     Ethereum Transfers Heatmap banteg https://banteg.xyz/posts/heatmap/index.html This work is heavily inspired by the amazing visualizations of bitcoin inputs/outputs at utxo.live.

    I’ve replicated it by plotting 2.1 billion native ether transfers.

    This post will apply the same method to ERC20 token transfers, so you can follow along with your favortite token and without needing a large transfers dataset.

    We will be using jupyter, cryo, polars, matplotlib, datashader, altair. You will learn how to render billions of data points and how to display them properly.

    Ethereum data

    We’ll make a heatmap of amount distribution among 18.3 million DAI transfers on Ethereum mainnet.

    If you want a larger dataset, you can try USDC (73.3 million), BTC UTXO (129 million), USDT (206 million transfers) or native ether transfers (2.1 billion).

    contract_address = "0x6b175474e89094c44da98b954eedeac495271d0f"
topic0 = "0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef"
amount_scale = 1e18

    If you have cryo logs (125 GB) dataset available, you can slice a subset from it, filtering by contract_address and topic0.

    You can also get it ad hoc using cryo. We only require block_number and data columns, with data encoding the amount sent.

    If you want to plot native ether transfers, you would need cryo transactions (304 GB) dataset.

    Imports and configs 
    import cryo
import numpy as np
import polars as pl
import cmasher
from IPython import display

pl.Config.set_tbl_hide_column_data_types(True)
pl.Config.set_tbl_hide_dataframe_shape(True)
    from eth_utils import decode_hex

raw_transfers = (
    pl.scan_parquet("~/data/logs/*.parquet")
    .filter(
        (pl.col.contract_address == decode_hex(contract_address))
        & (pl.col.topic0 == decode_hex(topic0))
    )
    .select("block_number", "data")
)
    cryo.freeze(
    "logs",
    contract=contract_address,
    topic0=topic0,
    align=True,
    chunk_size=100000,
    columns=["block_number", "data"],
    sort=["block_number"],
    output_dir="cryo_logs",
)
raw_transfers = pl.scan_parquet("cryo_logs/*.parquet")
    raw_transfers = (
    pl.scan_parquet("~/data/transactions/*.parquet")
    .filter(pl.col.value != "0")
    .with_columns(amount=pl.col.value.str.to_decimal().cast(pl.Float64()) / 1e18)
    .select("block_number", "amount")
)

    First, export the outstanding coins with bitcoin-utxo-dump.

    bitcoin-utxo-dump -f height,amount

    Then, extract block timestamps from LevelDB using python-bitcoin-blockchain-parser and join them with the coins.

    from os.path import expanduser
from blockchain_parser.blockchain import Blockchain

blocks = []
blockchain = Blockchain(expanduser("~/.bitcoin/blocks"))

for block in blockchain.get_ordered_blocks(expanduser("~/.bitcoin/blocks/index")):
    blocks.append((block.height, block.header.timestamp))

blocks = pl.DataFrame(blocks, schema=["height", "timestamp"])
utxo = pl.read_csv("utxodump.csv")

decoded_transfers = (
    utxo.join(blocks, on="height").sort("height").rename({"height": "block_number"})
)

    Decode the amounts from data column using map_batches. If your machine can’t fit the whole column into memory, you can try your luck with map_elements.

    def decode_amounts(series):
    return pl.Series(
        "amount",
        [int.from_bytes(item, "big") for item in series],
        dtype=pl.Float64,
    )


decoded_transfers = raw_transfers.select(
    "block_number",
    amount=pl.col.data.map_batches(decode_amounts) / amount_scale,
).collect()

    Heatmap size

    We need to decide on the heatmap size early, because the bucket sizes would depend on it. Let data inform our decision.

    The x axis would show the timestamp, so we need to know the date range to pick an appropriate interval.

    To do this, we look up timestamps from cryo blocks (0.86 GB) dataset.

    blocks = (
    pl.scan_parquet("~/data/blocks/*.parquet")
    .select(
        block_number="number",
        timestamp=pl.from_epoch("timestamp"),
    )
    .collect()
)
decoded_transfers = decoded_transfers.join(blocks, on="block_number")
print(len(decoded_transfers), 'transfers')
    18348925 transfers
    interval = "1d"

time_span = decoded_transfers.select(
    min=pl.col.timestamp.first(),
    max=pl.col.timestamp.last(),
).with_columns(
    pl.all().dt.truncate(interval).suffix("_t"),
    span=pl.col.max - pl.col.min,
)
time_range = pl.datetime_range(
    time_span[0, "min_t"], time_span[0, "max_t"], interval, eager=True
)
time_span.select("min", "max", "span")
    min max span
    2019-11-13 21:22:33 2023-09-24 09:34:59 1410d 12h 12m 26s

    The data spans 1410.5 days, a 1 day interval sounds fitting. We generate a datetime range to avoid any off-by-one errors later.

    For the y axis, we would likely want a log scale. We look up the range in the data, but choose the extents ourselves.

    amount_span = decoded_transfers.filter(pl.col.amount > 0).select(
    min=pl.col.amount.min(),
    max=pl.col.amount.max(),
    min_log=pl.col.amount.min().log(10),
    max_log=pl.col.amount.max().log(10),
)
amount_span
    min max min_log max_log
    1.0000e-18 5.4545e8 -18.0 8.736753 
    golden = (1 + 5**0.5) / 2
aspect = golden
width = len(time_range)
height = int(width / aspect)
buckets = np.logspace(-2, 8, height)
width, height
    (1412, 872)

    Heatmap data

    Polars has a very handy cut method for binning values into buckets. We count the number of transfers with the amount falling in every bucket on each day.

    For amounts exceeding the bucket range, polars uses a float("inf") break, which wouldn’t work with datashader. We fix this in the last step, as well as zero out the lowest bucket, as it includes all lower values, which makes it not very useful.

    transfer_stats = (
    decoded_transfers.with_columns(
        bucket=pl.col.amount.cut(buckets, include_breaks=True),
    )
    .sort("timestamp")
    .group_by_dynamic("timestamp", every=interval)
    .agg(
        txs_per_bucket=pl.col.bucket.struct.field("brk").value_counts(),
    )
    .explode("txs_per_bucket")
    .unnest("txs_per_bucket")
    .rename({"brk": "bucket", "counts": "num_txs"})
    .with_columns(
        bucket=pl.when(pl.col.bucket == float("inf"))
        .then(buckets[-1])
        .otherwise(pl.col.bucket),
        num_txs=pl.when(pl.col.bucket == buckets[0]).then(0).otherwise(pl.col.num_txs),
    )
)
print(len(transfer_stats), "datapoints")
    837412 datapoints

    Matplotlib

    With these data points we can plot the data. You can’t really use your regular charting methods when dealing with millions of points.

    But what is a heatmap if not a colormapped raster image? We could try to construct the image from our dense data, looking up x coordinates from time_range and y coordinates from buckets.

    To add the properly labeled ticks, we do a reverse translation from x and y coordinates to timestamp and buckets. We would override the tick labels with our computed values.

    To render the image, we could use something like imshow from matplotlib. It will appear very dim, so you would want to adjust the data or do some colormap normalization1.

  • 1 Colormap normalization

    • More search might bring a different approach with histogram equalization2 from scikit-image to finally arrive at a decent result.

  • 2 Histogram equalization

    • If you try to add the axes, you would quickly learn that matplotlib was not designed to deal with exact dimensions. For some reason, it measures everything in inches. Moreover, if you try to rescale the axes, it would squish the image, and we want to blip the heatmap on the chart as is. There is plt.figimage, but it doesn’t work with 2x resolution and you would need to calculate the offset (in pixels this time) by hand.

    Below I present an easier method, which relies on an obscure combination of options. If you create a figure the size of the image and then add the axes with zero margin, the image would be pixel perfect, but the axes would be outside frame. When saving an image, you can set bbox_inches='tight' and matplotlib would expand the output image to reveal the axes.

    See matplotlib code 
    from matplotlib import pyplot as plt
from skimage.exposure import equalize_hist

%config InlineBackend.figure_format = 'retina'

# convert timestamps to x coordinates and buckets to y coordinates
date_to_x = (
    pl.DataFrame({"timestamp": time_range})
    .with_row_count()
    .rename({"row_nr": "x"})
)
bucket_to_y = (
    pl.DataFrame({"bucket": buckets})
    .with_row_count()
    .rename({"row_nr": "y"})
)
source = (
    transfer_stats
    .join(date_to_x, on="timestamp")
    .join(bucket_to_y, on="bucket")
)
# convert datapoints to image
x = source["x"].to_numpy()
y = source["y"].to_numpy()
w = source["num_txs"].to_numpy()
H, xe, ye = np.histogram2d(x, y, weights=w, bins=[width, height])
# match the figure size with the image size
dpi = 120
fig = plt.figure(figsize=(width / dpi, height / dpi), dpi=dpi)
fig.add_axes((0, 0, 1, 1), frame_on=False)
# note: histogram2d flips the cartesian coordinates
im = plt.imshow(equalize_hist(H.T), origin="lower", cmap=cmasher.freeze)
ax = plt.gca()
# y axis ticks
y_ticks = np.logspace(-2, 8, 11)
y_indexes = [np.where(buckets >= t)[0][0] for t in y_ticks]
ax.set_yticks(y_indexes, [f'$10^{{{int(np.log10(n))}}}$' for n in y_ticks])
# x axis ticks
dts = date_to_x.group_by_dynamic('timestamp', every='1q').agg(pl.col.x.first()).tail(-1)
x_ticks = dts['timestamp'].cast(pl.Date).to_list()
ax.set_xticks(dts['x'].to_numpy(), [f'{x.strftime("%b")}' + (f'\n{x.strftime("%Y")}' if x.month == 1 else "") for x in x_ticks])
plt.title('DAI transfer amount heatmap')
# this method works both for `show` and `savefig`
plt.savefig('heatmap-matplotlib.png', bbox_inches='tight')
plt.show()

    Datashader

    But what if I told you there is a better way, which does much of this by default.

    You know the devs are onto something when their tutorial starts from a chapter-long rant3 about all the bad charts people are making.

  • 3 Plotting pitfalls

    • Their peers also have strong words (and a paper4) about colormaps matplotlib ships with. Instead, they recommend using a perceptually uniform colormap. Two such collections are colorcet and cmasher, the latter offers more artistic options.

  • 4 Good Colour Maps: How to Design Them

    • We use datashader here, since it offers a pipeline flexible enough to render a billion points on a laptop.

    First, convert the timestamps to float as required by xarray. Normalize the transaction counts by day using a window function so the image is more legible. If you want to use raw counts, change ds.sum("normalized") to ds.sum("num_txs").

    Next, create a canvas and add the data points there. Datashader supports aggregation, so you can simply halve plot_width and plot_height and it would render a preview image for you. Fill untouched buckets with zeros, otherwise they would appear as transparent.

    Verify the dimensions are correct using ds.count aggregation. If you see horizontal or vertical streaks, your sizes do not match up.

    Finally, apply a colormap using tf.shade. It would normalize the values to better translate them to the colormap. By default, datashader uses histogram equalization how="eq_hist", a nice choice for a large dataset. It would spread out the values in a way that would occupy the full range of the colormap, bringing out the most contrast. Other options include linear (matplotlib default), logarithmic log, and cube root cbrt.

    import datashader as ds
from datashader import transfer_functions as tf

df = transfer_stats.with_columns(
    pl.col.timestamp.cast(pl.Float64),
    normalized=pl.col.num_txs / pl.col.num_txs.sum().over("timestamp"),
).to_pandas()

canvas = ds.Canvas(plot_width=width, plot_height=height, y_axis_type="log")
points = canvas.points(df, "timestamp", "bucket", agg=ds.sum("normalized")).fillna(0)
heatmap = tf.shade(points, cmap=cmasher.freeze)
heatmap.to_pil().save("heatmap.png")
display.Image("heatmap.png")

    Altair

    We have plotted 837,412 data points faster than you blinked. And datashader did a much better job than matplotlib utilizing the full range of the colormap.

    Below I will show another way of adding axes to the image using altair.

    Altair excels at layering and combining charts. We plot two points: one with the minimum coordinates where we blip the image, and another invisible point at the maximum coordinates. The chart size is halved so it renders better on a retina screen.

    To render an image in altair, you specify an url, which doesn’t work with local images in a local jupyter easily. The workaround is to embed a base64-encoded image in the source data.

    The upside of this approach is you have real axes now, which you can allow altair to render nicely instead of mapping the values by hand. The chart also looks crisp at any resolution because everything but the heatmap is vector, unlike matplotlib5.

  • 5 matplotlib can render svg, but nobody uses this for some reason

    • See altair code 
    import io
import base64
import altair as alt

def xarray_to_base64(image):
    buffer = io.BytesIO()
    image.to_pil().convert("RGB").save(buffer, format="png")
    encoded = base64.b64encode(buffer.getvalue())
    return "data:image/png;base64," + encoded.decode()


extents = pl.DataFrame(
    {
        "timestamp": [transfer_stats[0, "timestamp"], transfer_stats[-1, "timestamp"]],
        "amount": [buckets[0], buckets[-1]],
        "image_data": [xarray_to_base64(heatmap), None],
    }
)

axes = (
    alt.Chart(
        extents.to_pandas().tail(1),
        title="DAI transfer amount heatmap",
        width=width // 2,
        height=height // 2,
    )
    .mark_point(opacity=0)
    .encode(
        alt.X("timestamp:T").axis(tickCount=10, labelExpr="[timeFormat(datum.value, '%b'), timeFormat(datum.value, '%m') == '01' ? timeFormat(datum.value, '%Y') : '']"),
        alt.Y("amount:Q").scale(type="log"),
    )
)

fill = (
    alt.Chart(
        extents.to_pandas().head(1),
    )
    .mark_image(width=width // 2, height=height // 2, align="left", baseline="bottom")
    .encode(alt.X("timestamp:T"), alt.Y("amount:Q"), alt.Url("image_data"))
)

(fill + axes).configure_axis(grid=False).configure_view(stroke=None)

    Prior art

    If you are interested in this type of visualizations, you should check out these projects:

    • BitcoinUtxoVisualizer by martinus can produce a video6 that shows the evolution of bitcoin unspent transaction outputs set
    • utxo-live by Unbesteveable can plot a heatmap by decoding UTXOs from a static dumptxoutset output.

  • 6 watch here, last rendered in 2020

    • ]]>     ethereum data https://banteg.xyz/posts/heatmap/index.html Tue, 26 Sep 2023 20:00:00 GMT     Minimal Proxy Compendium banteg https://banteg.xyz/posts/minimal-proxies/index.html

    PART I: Proxy Types

    While working on adding support for more proxy types to Ape, I got sucked into some of the most incredible onchain archeology. Follow along and you will be able to repeat this journey even on your laptop.

    What is a Proxy

    A proxy is a tiny contract, often in hand-written assembly, that makes it cheap to deploy instances of a logic contract while making it slightly more expensive to call them. Proxies are good citizens, they don’t clutter the blockchain state and they make creating a pool as affordable as making a trade.

    They work by using a special type of call named delegatecall that keeps the execution context inside the proxy while executing the code of the implementation contract. This allows the code from the logic contract to be used as a library and interact with the storage of the proxy contract.

    Let’s look at different proxies as they were invented.

    Vyper Beta

    Unlike Solidity that still lacks this feature, Vyper has offered a safe way of creating minimal proxies since the very first beta. The most widely used deployment of these pre-standard proxies can be found in Uniswap v1 factory contract, which is responsible for the majority of 4270 instances that follow this pattern.

    If you ever worked with Uniswap v1, you might know the quirk of these proxies, they always return 40961 bytes disregarding the actual response length.

  • 1 0x1000 in hex

    • CALLDATASIZE
PUSH1 0x0
PUSH1 0x0
CALLDATACOPY
PUSH2 0x1000
PUSH1 0x0
CALLDATASIZE
PUSH1 0x0
PUSH20 0x2157a7894439191e520825fe9399ab8655e0f708
GAS
DELEGATECALL
ISZERO
PC
JUMPI
PUSH2 0x1000
PUSH1 0x0
RETURN

    EIP-1167 Minimal Proxy Contract

    The most popular immutable proxy was invented in 2018 and got finalized2 the next year. It is so abundant it accounts for 21.6% of all Ethereum contracts.

  • 2 EIP‑1167: Minimal Proxy Contract

    • The standard also suggests an optimization where you are supposed to mine a shorter logic contract address and replace PUSH20 with PUSH16, saving 4 bytes on every deployment but winning nothing in terms of runtime costs.

    Five years later, out of 13,504,799 instances across 31,618 implementations, only 2 have followed the advice, and only 1 to the letter.

    Optimized EIP-1167

    The first successful attempt is an ERC20 factory3. The optimization seems misplaced here, given the contract allows the user to specify the library address. The user must be aware she can only use a library with an address that starts with at least 4 zero bytes, making the whole concept very error-prone.

  • 3 etherscan.io

    • This is the exact fate of our second optimizer, who deployed 125 proxies only to discover that none of them work. Instead of mining a 4-byte zero prefix for the library, he has mined it for the factory, which was a fatal mistake. The full library address, which you can still recover from the factory storage4, got cut off by PUSH16, rendering all proxies irredeemably broken.

  • 4 evm.storage

    • 88076ef09c9d720cee4c096765a0581068d97aa9 library address
    000000009c9d720cee4c096765a0581068d97aa9 push16-chewed address

    EIP-1167 in Vyper

    Vyper allows you to create EIP‑1167 proxies natively using create_minimal_proxy_to(address)5.

  • 5 available since Vyper 0.3.4

    • You can deploy a proxy to a deterministic address using CREATE2. The only thing you need to change is to supply a salt6 parameter.

  • 6 available since Vyper 0.3.0

    • In older contracts you might encounter create_forwarder_to(address)7, which does the same and was the first time EIP-1167 appeared in Vyper.

  • 7 available since Vyper 0.2.9

    • 0age shaves one byte off

    Feeling personally challenged by the word “minimal”, 0age came up with a marginal improvement to the contract8, cutting the deployment cost by 200 gas and making each call cheaper by 4 gas.

  • 8 The More-Minimal Proxy

    • It is the second-popular minimal proxy with 9,928 instances or 0.016% of all contracts and 17 unique logic contracts.

    Diff EIP-1167 and The More-Minimal Proxy 
    -CALLDATASIZE
 RETURNDATASIZE
 RETURNDATASIZE
-CALLDATACOPY
 RETURNDATASIZE
 RETURNDATASIZE
+CALLDATASIZE
 RETURNDATASIZE
+RETURNDATASIZE
+CALLDATACOPY
 CALLDATASIZE
 RETURNDATASIZE
 PUSH20 0xbebebebebebebebebebebebebebebebebebebebe
 GAS
 DELEGATECALL
 RETURNDATASIZE
-DUP3
+RETURNDATASIZE
+SWAP4
 DUP1
 RETURNDATACOPY
-SWAP1
-RETURNDATASIZE
-SWAP2
-PUSH1 0x2b
+PUSH1 0x2a
 JUMPI
 REVERT
 JUMPDEST

    Vectorized pushes to zero

    Another optimizoor has made a version that utilizes a new PUSH0 opcode. It increases the size back to 45 bytes, but calls become 8 gas cheaper compared to EIP‑1167. You can read the annotated bytecode in the Solady repo9.

  • 9 LibClone.sol in Vectorized/solady

    • Diff EIP-1167 and Solady PUSH0 
    +PUSH0
+PUSH0
 CALLDATASIZE
-RETURNDATASIZE
-RETURNDATASIZE
+PUSH0
+PUSH0
 CALLDATACOPY
-RETURNDATASIZE
-RETURNDATASIZE
-RETURNDATASIZE
 CALLDATASIZE
-RETURNDATASIZE
+PUSH0
 PUSH20 0xbebebebebebebebebebebebebebebebebebebebe
 GAS
 DELEGATECALL
 RETURNDATASIZE
-DUP3
-DUP1
+PUSH0
+PUSH0
 RETURNDATACOPY
-SWAP1
-RETURNDATASIZE
-SWAP2
-PUSH1 0x2b
+PUSH1 0x29
 JUMPI
+RETURNDATASIZE
+PUSH0
 REVERT
 JUMPDEST
+RETURNDATASIZE
+PUSH0
 RETURN
    PUSH0 requires care

    PUSH0 was added in Shanghai upgrade. The upgrade saw a slow rollout outside Ethereum mainnet. Even if you could deploy a contract, it won’t work until after the network upgrades.

    Is it worth it?

    Optimizing such a tiny contract undoubtedly feels validating. But consider this, every byte or gas squeezed out of it sets you back to zero tool support. If you consider using these variants, be prepared to make pull requests and even bribe Etherscan so they add support.

    Huff developers, who think entirely in bytecode, have chosen to support the standard EIP-1167 proxy in their library10.

  • 10 Clones.huff in huff-lagngauge/huffmate

    • Clones With Immutable Arguments

    This family of proxies abuses the fact that you can use contract’s own code as a cheap write-only storage, reading it with CODECOPY. Immutable variables work in a similar fashion, they must be set in the constructor, which then appends them to the returned runtime bytecode.

    But how do we get the immutables through to the logic contract? Enter wighawag who has invented ClonesWithCallData11. Before forwarding a call, this proxy type reads the extra variables from the code and appends them to the end of calldata, along with a 2 byte extra length. The length is an important security measure that helps delineate where the user-provided calldata ends and immutable variables begin. A function it forwards to will simply ignore everything that comes after its arguments, but the contract itself would be able to read them from msg.data using a tiny helper function that calculates the offset. It’s a win-win situation!

  • 11 ClonesWithCallData.sol in wighawag/clones-with-immutable-args

    • The idea was further iterated upon by boredGenius who has optimized the bytecode and gave it a name of ClonesWithImmutableArgs12. This version has made it into production with 264 instances across 36 logic contracts, while another suggested optimization by Saw-mon & Natalie was ghosted as a forever open pull request13 with only 2 presumably test contracts on mainnet.

  • 12 ClonesWithImmutableArgs.sol in wighawag/clones-with-immutable-args

  • 13 Gas Optimizations

    • 0xSplits uses another older version of these proxies for their VestingModule. 1 of 3 such proxies is used to fund Ethereum core devs. Interestingly, Saw-mon-and-Natalie updates were ported to 0xSplits fork later on, but this version seems to have never made it to prod.

    There exists a Huff rewrite14 of CWIA proxies in huffmate under the name of huff-clones.

  • 14 huff-clones in huff-language/huffmate

    • A compatible Vyper version15 was made by banteg, but creating a Vyper factory would require a new language feature16.

  • 15 banteg/vyper-cwia

  • 16 VIP: add function to create clones with immutable args

    • CWIA proxies are used in production by Ajna, Astaria, Buttonwood, 0xSplits, Sudoswap.

    The difference between CWIA and Sudoswap proxies highlighted with a regex

    Sequence Wallet

    Despite being upgradeable, Sequence proxy is worth mentioning because it achieves immutability for both init and runtime code. It got there by using the address of the proxy as a storage key for the implementation address. Reading from storage makes it the most expensive of all proxies we have looked at today. This pattern is used in their modular and extensible smart wallet17. There are 1888 of Sequence proxies deployed at the time of writing.

  • 17 Wallet.sol in 0xsequence/wallet-contracts

    • PART II: The Data

    In this part you’ll be converted to a parquet maxi capable of regexing through an entire blockchain in seconds. We will look at the most popular patterns and rank logic contracts by number of proxies pointing to them. I’ll take you through preparing and transforming the data needed for a deeper look at the State of the Proxy.

    Choosing the right tool

    I learned of parquet format as recently as this PSA, and it’s as good as it says.

    When I started working on this article I used pdp. You’ll be using cryo, a Rust rewrite of pdp that has recently added support for extracting the same contracts dataset we are interested in.

    Tracing the entire blockchain took 9 hours for me with Erigon. I recommend running rpcdaemon as a separate process as it greatly improves stability.

    Run Erigon with a --metrics option, collect with Prometheus and display in Grafana

    After you tame cryo so it doesn’t overload your Ethereum node when it hammers it with thousands of trace_block requests, you’ll end up with a folder of parquets. You can load them with pandas, but we’ll be using polars.

    It is similar to pandas in goals, but has a different and, frankly, better designed api with no index columns. Polars also allows for lazy processing (achievable with dask in pandas world) and stacking insanely large queries, optimized by its query planner.

    All that will come in handy since our dataset is gonna be massive. A similar but less complete dataset in BigQuery takes up 58.62 GB18. To your surprise, the folder of parquets is significantly smaller, just 15.64 GB. And you have more data than BigQuery already, with additional columns for deployer, factory, init code, and init/runtime code hashes.

  • 18 All sizes in the article are base-10, so 1 GB = 1 billion bytes

    • Parquet dataset size 
    from pyarrow.parquet import ParquetFile, ParquetDataset

def parquet_size(path):
    dataset = ParquetDataset(path)
    data = defaultdict(int)
    for file in dataset.files:
        meta = ParquetFile(file).metadata
        data["rows"] += meta.num_rows
        for row_group in range(meta.num_row_groups):
            for col in range(meta.num_columns):
                item = meta.row_group(row_group).column(col)
                data["compressed"] += item.total_compressed_size
                data["uncompressed"] += item.total_uncompressed_size

    return pl.DataFrame(data).with_columns(
        (pl.col("uncompressed", "compressed") / 1e9),
        ratio=pl.col.uncompressed / pl.col.compressed,
    )
    parquet_size("~/data/contracts")
    rows compressed uncompressed ratio
    62498184 15.680626 73.873403 4.711126

    This 62.5 million row dataset would’ve been 73.87 GB uncompressed. Parquet offers decent compression out of the box, but we can get better size (2x) and performance (3x) if we consolidate our 18,000 chunks of 1000 blocks per file into 18 chunks of 1 million blocks per file.

    After repartitioning with pyarrow19 (around 4 minutes) and a sprinkle of zstd compression (parquet even supports a different compression strategy per column) we end up with a 7.79 GB dataset. All Ethereum contracts are at your fingertips from this moment on.

  • 19 See also cryogen, if you are interested in keeping your dataset fresh and optimized

    • parquet_size('~/data/contracts_out')
    rows compressed uncompressed ratio
    62498184 7.79446 50.26806 6.449203

    Unique bytecodes

    Out of 62.5 million contracts there are only 1.05 million non-repeating bytecodes. Since we are going to search through them a lot, it would make sense to prepare another parquet that only contains unique codes. We could also add code hashes to use as a join key should we require more info from the main dataset. The number of contracts matching each unique code hash would also come in handy for aggregate statistics.

    Doing this would save us a few seconds on each query. You can additionally pre-encode codes as hex strings if you are mostly going to regex through them. The overhead is manageable thanks to compression, and it’s not that you have much of a choice, binary column support in polars is very limited at the time of writing.

    (
    pl.scan_parquet(contracts_path)
    .select("code", "code_hash")
    .group_by("code_hash")
    .agg(
        pl.col.code.first().bin.encode("hex"),
        num_contracts=pl.count(),
        first_contract=pl.col.contract_address.first().bin.encode("hex"),
    )
    .collect()
    .write_parquet(codes_path)
)
    parquet_size(codes_path)
    rows compressed uncompressed ratio
    1058734 1.117846 14.339663 12.827943

    Regex the contracts

    With the data prepared, we can search through the bytecodes with a regex and even extract the implementation address from a matching group. But where do we obtain said patterns?

    Lucilky, adding support for different proxies has been a long obsession of mine as an ape contributor20, so I’ve amassed quite a trove of these patterns.

  • 20 See this file and find all the references in this file

    • PROXY_PATTERNS = {
    "EIP-6551": r"^363d3d373d3d3d363d73(.{40})5af43d82803e903d91602b57fd5bf3.+",
    "EIP-1167": r"^363d3d373d3d3d363d73(.{40})5af43d82803e903d91602b57fd5bf3",
    "EIP-1167 Optimized": r"^363d3d373d3d3d363d6f(.{32})5af43d82803e903d91602757fd5bf3",
    "0age": r"^3d3d3d3d363d3d37363d73(.{40})5af43d3d93803e602a57fd5bf3",
    "0xSplits Clones": r"^36603057343d52307f830d2d700a97af574b186c80d40429385d24241565b08a7c559ba283a964d9b160203da23d3df35b3d3d3d3d363d3d37363d73(.{40})5af43d3d93803e605b57fd5bf3",
    "Vyper": r"^366000600037611000600036600073(.{40})5af4602c57600080fd5b6110006000f3",
    "Vyper Beta": r"^366000600037611000600036600073(.{40})5af41558576110006000f3",
    "ClonesWithImmutableArgs": r"^3d3d3d3d363d3d3761.{4}603736393661.{4}013d73(.{40})5af43d3d93803e603557fd5bf3",
    "ClonesWithCallData": r"^363d3d3761.{4}603836393d3d3d3661.{4}013d73(.{40})5af43d82803e903d91603657fd5bf3",
    "sudoswap ClonesWithImmutableArgs": r"^3d3d3d3d363d3d37605160353639366051013d73(.{40})5af43d3d93803e603357fd5bf3",
    "solady ClonesWithImmutableArgs": r"^36602c57343d527f9e4ac34f21c619cefc926c8bd93b54bf5a39c7ab2127a895af1cc0691d7e3dff593da1005b363d3d373d3d3d3d61.{4}806062363936013d73(.{40})5af43d3d93803e606057fd5bf3",
    "sw0nt ClonesWithImmutableArgs": r"^363d3d373d3d3d3d61.{4}806035363936013d73(.{40})5af43d3d93803e603357fd5bf3",
    "0xSplits ClonesWithImmutableArgs": r"^36602f57343d527f9e4ac34f21c619cefc926c8bd93b54bf5a39c7ab2127a895af1cc0691d7e3dff60203da13d3df35b3d3d3d3d363d3d3761.{4}606736393661.{4}013d73(.{40})5af43d3d93803e606557fd5bf3",
    "Solady PUSH0": r"^5f5f365f5f37365f73(.{40})5af43d5f5f3e6029573d5ffd5b3d5ff3",
    "Sequence": r"^363d3d373d3d3d363d30545af43d82803e903d91601857fd5bf3",
}

    I’ve put matching groups around where the implementation addresses are present in bytecodes. They mostly come after PUSH20, with the exceptions of PUSH16 in optimized EIP-1167 and no address in Sequence proxy, where you would need to look for it in the contract storage.

    This allows us to extract hardcoded implementation addresses for most types of proxies.

    def search_codes(pattern):
    return (
        pl.scan_parquet(codes_path)
        .filter(pl.col.code.str.contains(pattern))
        .with_columns(extracted=pl.col.code.str.extract(pattern, 1))
        .collect()
    )

    To make queries faster, we can load a partial dataset into memory. Let’s assume that a minimal proxy is no larger than 512 bytes, including the data section.

    small_codes = (
    pl.scan_parquet(codes_path)
    .filter(pl.col.code.str.lengths() // 2 <= 512)
    .collect()
)

def search_codes(pattern):
    return (
        small_codes
        .filter(pl.col.code.str.contains(pattern))
        .with_columns(extracted=pl.col.code.str.extract(pattern, 1))
    )

    EIP-1167 plus?

    Let’s put it to the test and collect statistics about the most common minimal proxy.

    minimal_proxies = search_codes(PROXY_PATTERNS['EIP-1167'])
minimal_proxies.select(
    num_contracts=pl.col.num_contracts.sum(),
    num_codes=pl.count(),
    num_impls=pl.col.extracted.unique().count(),
)
    num_contracts num_codes num_impls
    13504799 37349 31618

    Observe the discrepancy between the number of implementations and the number of contracts. Wonder where it comes from. Could it be some extra data appended at the end? Let’s group them by code size.

    (
    minimal_proxies.group_by((pl.col.code.str.lengths() // 2).alias("code_size"))
    .agg(
        pl.col.num_contracts.sum(),
        num_codes=pl.count(),
        num_impls=pl.col.extracted.unique().count(),
    )
    .sort("num_contracts", descending=True)
)
    code_size num_contracts num_codes num_impls
    45 13499061 31611 31611
    173 5738 5738 7

    There is exactly one alternative flavor of these proxies with data at the end. After looking at sample contracts, they appear to be related to EIP-655121.

  • 21 ERC-6551: Non-fungible Token Bound Accounts

    • Since there is just 7 implementations, let’s look at the number of proxies pointing to each of them.

    eip_6551 = minimal_proxies.filter(pl.col.code.str.lengths() // 2 > 45)
(
    eip_6551
    .select(pl.col.extracted.value_counts(sort=True))
    .unnest('extracted')
)
    extracted counts
    "2d25602551487c3f3354dd80d76d54383a243358" 3535
    "5ae5f4d4982ede2c820d2a9827ccb97fed6cef71" 2174
    "d00431d1bfe2f0f85396e685d890e18f8dc411aa" 24
    "ed4e5b7338e8b4b5299c69b5a7c0f82c4426439e" 2
    "811fa807cf230e32211ed168920fe8b27d01cb1c" 1
    "8ee9a60cb5c0e7db414031856cb9e0f1f05988d1" 1
    "dc4f50191a6f250741d9aa733dd4299499285314" 1

    After reading the EIP, we can decode the data section and look at the most popular nfts that offer token bound accounts.

    import eth_abi

def eip6551_token(code):
    types = ["uint256", "uint256", "address", "uint256"]
    names = ["salt", "chain_id", "token_contract", "token_id"]
    result = dict(zip(names, eth_abi.decode(types, bytes.fromhex(code)[45:])))
    return result["token_contract"]


eip_6551_tokens = (
    eip_6551.with_columns(token_contract=pl.col.code.map_elements(eip6551_token))
    .select(pl.col.token_contract.value_counts(sort=True))
    .unnest("token_contract")
)
print(len(eip_6551_tokens), "tokens")
eip_6551_tokens.head(10)
    825 tokens
    token_contract counts
    "0xa87ea7c8745980490bcdcff97fe7328535098cd1" 2174
    "0x8ddef0396d4b61fcbb0e4a821dfac52c011f79da" 835
    "0x26727ed4f5ba61d3772d1575bca011ae3aef5d36" 487
    "0x8c34e6e60731d1ff7e26c712ea1f798f90f29ec6" 433
    "0x235c939ae3859f8041cee3ccb2c58a7983bf02b1" 105
    "0xc1341a63a4dd85443b0413bc2acffc49b60e9c70" 91
    "0xd4307e0acd12cf46fd6cf93bc264f5d5d1598792" 36
    "0x57f1887a8bf19b14fc0df6fd9b2acc9af147ea85" 35
    "0x9131d8c7a411d90c6b164d296440701a0e5b3178" 35
    "0xbc886e22683680026c9028ef86667dcad36e90e3" 34

    Popular implementations

    Now let’s look the most popular implementations by number of instances.

    impls = (
    base_proxies.group_by("impl")
    .agg(
        pl.col.proxy_type.first(),
        pl.col.num_contracts.sum(),
        ratio=pl.col.num_contracts.sum() / total_contracts,
    )
    .sort("num_contracts", descending=True)
)
impls.head(10)
    impl proxy_type num_contracts ratio
    "0a252663dbcc0b073063d6420a40319e438cfa59" "EIP-1167" 2977216 0.047637
    "0de8bf93da2f7eecb3d9169422413a9bef4ef628" "EIP-1167" 2940548 0.04705
    "059ffafdc6ef594230de44f824e2bd0a51ca5ded" "EIP-1167" 923983 0.014784
    "1bc8f124e7e320c71a6394de0458e8d7ea27623e" "EIP-1167" 491262 0.00786
    "d332254f274cc65aa11178b74734e2992b8f349e" "EIP-1167" 450725 0.007212
    "1d65d25b1d90ef6dd9f64b10d6b079a015085855" "EIP-1167" 385011 0.00616
    "10692b1c144ef98904335e40ce857369d19b8333" "EIP-1167" 338927 0.005423
    "83b76b11257c4ece35370b6152f1946d49479e89" "EIP-1167" 329477 0.005272
    "3ccb891089d53e2faaf0decde04b41c3fce1a107" "EIP-1167" 311053 0.004977
    "39778bc77bd7a9456655b19fd4c5d0bf2071104e" "EIP-1167" 233622 0.003738
    Display a clickable chart 
    import altair as alt


def make_chart(df, title):
    return (
        alt.Chart(df.head(20), title=title)
        .transform_calculate(
            url="https://etherscan.io/address/0x" + alt.datum.impl + "#code"
        )
        .mark_bar()
        .encode(
            alt.X("ratio:Q").axis(format="%", labelFlush=False),
            alt.Y("impl:N", sort=None).axis(labelLimit=40),
            alt.Color("proxy_type:N", sort=None),
            alt.Href("url:N"),
        )
    )


with_eip1167 = make_chart(impls, "most proxied implementations")
without_eip1167 = make_chart(
    impls.filter(pl.col.proxy_type != "EIP-1167"),
    title="most proxied implementations excluding eip-1167",
)

alt.hconcat(with_eip1167, without_eip1167)

    Unknown variants

    Finding a new proxy type every time I pick up this article has become a bit of a running joke. To put it to bed, we need to come up with a definitive way to find all possible variants. Let’s start from an assumption that all minimal proxies contain this code.

    PUSH_ <implementation> GAS DELEGATECALL

    As I’ve shown in my other article22, you can’t simply regex in this case, because parts of the code could have different semantic meaning. We need to disassemble the code so we don’t accidentally match PUSH arguments or data.

  • 22 So you found a compiler bug by banteg

    • small_codes.select(pl.col.num_contracts.sum(), num_codes=pl.count())
    num_contracts num_codes
    49481339 138650

    We keep track of the last push instruction while looking for a delegatecall pattern we identified. The push argument would contain the implementation address.

    If you are interested in a more advanced version of this algorithm, check out WhatsABI23.

  • 23 disasm.ts in shazow/whatsabi

    • from collections import deque
from ethereum.shanghai.vm.instructions import Ops

opcodes = {op.value: op for op in Ops}

class PUSH:
    def __eq__(self, op):
        if isinstance(op, Ops):
            op = op.value
        return Ops.PUSH1.value <= op <= Ops.PUSH32.value

def disasm(code):
    """Disassemble the code and extract the implementation address."""
    code = bytes.fromhex(code)
    ops = deque(maxlen=3)
    pushes = deque(maxlen=1)
    pc = 0
    while pc < len(code):
        op: int = code[pc]
        ops.append(Ops(op))
        if Ops.PUSH1.value <= op <= Ops.PUSH32.value:
            push_size = op - Ops.PUSH0.value
            push_value = code[pc + 1 : pc + 1 + push_size]
            pushes.append(push_value.hex())
            pc += push_size

        if list(ops) == [PUSH(), Ops.GAS, Ops.DELEGATECALL]:
            return {"impl": pushes[-1], "push_size": ops[0].value - Ops.PUSH0.value}

        pc += 1

    return {"impl": None, "push_size": None}

    We can apply a python function to a column using map_elements. The returned dict becomes a struct, which can be turned into columns using unnest.

    Addresses that come from opcodes other than PUSH20 need to be normalized. Check longer pushes for empty padding bytes, and pad shorter ones with zeros.

    found_proxies = (
    small_codes
    .with_columns(impl=pl.col.code.map_elements(disasm))
    .unnest('impl')
    .filter(pl.col.impl.is_not_null())
    .with_columns(pl.col.impl.str.rjust(64, '0'))
    .filter(pl.col.impl.str.slice(0, 24) == '0' * 24)
    .with_columns(pl.col.impl.str.slice(24, 40))
)

    We have found more proxies and improved our results by 8.5%.

    found_proxies.select(
    num_contracts=pl.col.num_contracts.sum(),
    num_codes=pl.count(),
    num_impls=pl.col.impl.unique().count(),
)
    num_contracts num_codes num_impls
    14675709 47064 31962 
    (
    found_proxies.select(pl.col.num_contracts.sum())
    / proxies_by_type.select(pl.col.num_contracts.sum())
)
    num_contracts
    1.085049

    We have also collected interesting statistics about vanity addresses.

    found_proxies.select(pl.col.push_size.value_counts(sort=True)).unnest('push_size')
    push_size counts
    20 46926
    16 116
    32 9
    18 6
    15 4
    17 1
    13 1
    14 1

    Up to you to verify if someone has actually managed to mine an address with 7 leading zero bytes, I will just provide a list of suspect addresses for convenince.

    (
    found_proxies.filter(pl.col.push_size < 16)
    .select("impl", "first_contract", "push_size")
    .sort("push_size")
)
    impl first_contract push_size
    "000000000000001d48ffbd0c0da7c129137a9c55" "0000000000bf2686748e1c0255036e7617e7e8a5" 13
    "000000000000df8c944e775bde7af50300999283" "00000000005df2c9274605abd6773f14578f8a28" 14
    "00000000004096437c84e1b0927d5ed44f45f6b3" "2ea66a667e258594a05c94345775a02c5fb1b74c" 15
    "00000000008eabbe9a46fa87f0d1e41e62a96d50" "a9a90922d6d2a5c3a36c0170bb0cefac5300b779" 15
    "0000000000c08718718b974d644b098c19bd0064" "8608a089a9ec9a5483faa12a56e987901aad27ce" 15
    "000000000045ef846ac1cb7fa62ca926d5701512" "f4907e6182157d564dc180978499b48ebd333f77" 15

    Seeing patterns

    As you could’ve observed from regex patterns, all codes end with an f3 (RETURN) instruction. We can exploit this fact to strip the data section. Moreover, if we also strip the PUSH arguments, we end up with what I call a mini code that uniquely identifies a specific proxy pattern.

    def strip_code(code):
    """Distill the code to its minimal form."""
    code = bytes.fromhex(code)
    mini_code = []
    pc = 0
    while pc < len(code):
        op = code[pc]
        mini_code.append(op)
        if op == PUSH():
            push_size = op - Ops.PUSH0.value
            pc += push_size
        
        if op == Ops.RETURN.value:
            break
        
        pc += 1
    
    return bytes(mini_code).hex()

strip_code(
    '363d3d373d3d3d363d73'
    'bebebebebebebebebebebebebebebebebebebebe'  # implementation
    '5af43d82803e903d91602b57fd5bf3'
    'b00ba1'  # data section
)
    '363d3d373d3d3d363d735af43d82803e903d916057fd5bf3'

    Combine it all together and we find 80 unique delegatecall patterns, including the obscure ones and the ones that encode immutable args.

    known_names = (
    base_proxies.unique("proxy_type")
    .filter(pl.col.proxy_type != "EIP-6551")
    .with_columns(mini_code=pl.col.code.map_elements(strip_code))
    .select("mini_code", "proxy_type")
)
proxy_types = (
    found_proxies.with_columns(mini_code=pl.col.code.map_elements(strip_code))
    .group_by("mini_code")
    .agg(
        num_codes=pl.count(),
        num_impls=pl.col.impl.unique().count(),
        num_contracts=pl.col.num_contracts.sum(),
        first_contract=pl.col.first_contract.first(),
    )
    .join(known_names, on="mini_code", how="left")
    .sort("num_contracts", descending=True)
)
proxy_types
    mini_code num_codes num_impls num_contracts first_contract proxy_type
    "363d3d373d3d3d363d735af43d82803e903d916057fd5bf3" 37349 31618 13504799 "e5f740036228a299f7498c82be966f1ad750bf94" "EIP-1167"
    "583681803780803681735af43d91908282803e6057fd5bf3" 14 14 955047 "40d87fa19a6d1055d42a08e1f79ccefdae1a1ce1" null
    "60605234615760513660823760803683735af43d8060843e81801561578184f3" 7 7 79582 "40d7d02529045b7ec1d443c540d9522d052164ad" null
    "3d3d3d3d363d3d37606036393660013d735af43d3d93803e6057fd5bf3" 8607 29 40689 "e6216d1144ac51b33efa326672d4aafc08be93a1" "sudoswap ClonesWithImmutableArgs"
    "606052366057005b3660803760603660735af45000fea264221220cd31d7df5797d8b… 1 1 37233 "06c683bf06e0e8c2709f6eb90451b06f2977b59d" null
    "60808080803680928037735af43d828181803e8083146057f3" 20 20 12782 "2f4b849bdac28903fd7bb142cdbc6005c770ad2d" null
    "3d3d3d3d363d3d37363d735af43d3d93803e6057fd5bf3" 17 17 9928 "cdff0b2aab0f203860be730a077ca7213fecaa8c" "0age"
    "6060523660811461573660803760803660735af43d60803e8060811461573d60f3" 6 4 5965 "25dbb91164bf15bd16df3f5a63a062d6aebdabfb" null
    "3660603761603660735af41558576160f3" 21 21 4518 "a698d462dc0f38844ca4e72dfcce372b982fa67b" "Vyper Beta"
    "603681803780803681735af43d82803e1560573d90f3" 23 23 4457 "3fb109e7df20e60d55ca38788d85c1e243f82931" null
    "6060523660803760803660735af43d60803e8060811460573d60f3" 4 3 3189 "f38eb9e060fc7104908db80968b3e2a7a226b07f" null
    "366057343d52307f603da23d3df3" 1 1 2890 "f8843981e7846945960f53243ca2fd42a579f719" "0xSplits Clones"
    "6060523660803760803660735af43d60803e80801560573d60f3" 1 1 2779 "728100299558e2d5790e1a7f9ea12de33f534794" null
    "6080368181838037735af400" 2 2 2701 "7bf6a2c08923e69a503031b56df35e98a98a5925" null
    "606052366057005b3660803760603660735af45000fea264221220fec0577d6f" 1 1 1663 "276628e5af6981f324abe82823985f123a3b0202" null
    "60605234615760513660823760803683735af43d8060843e8160811461578184f3" 3 2 1591 "2cf63d2f74890509a2bd42c9011e2dffe0928dd0" null
    "6060526036101560575b6036818037808036817f5af43d82803e1560573d90f3" 2 2 908 "a3bad5098f9489f536342ca9957bbc808d9d5d96" null
    "61605a031015605734156057346052606060606073605a03f11560576060f3" 1 1 717 "319e17a9c9153737fee4d5b5a0b76ad71732ece8" null
    "3660803761603660735af43d60803e8060811460573d60f3" 14 14 699 "8dd410227d3909b35f662825555443b6da7c0007" null
    "3660573415605734605233606080a25b005b608052606060376360511415605773605… 1 1 631 "34c22a846ab26d9e590ccad985c4e9b6d96fcbfa" null
    "3660603761603660735af460576080fd5b6160f3" 35 35 481 "fafdab9e3292612f8d07727a6375103b7b338fc0" "Vyper"
    "363d3d37616036393d3d3d3661013d735af43d82803e903d916057fd5bf3" 326 21 336 "7d7d26d129e793e2a4c0b96b17e18f2926a8a8e1" "ClonesWithCallData"
    "3d3d3d3d363d3d37616036393661013d735af43d3d93803e6057fd5bf3" 262 36 264 "5ed82249fa6e91becb35ef03044e22eb2dbde912" "ClonesWithImmutableArgs"
    "3660803760803660735af43d60803e603d916057fd5bf3" 4 4 254 "54f85a9da2d3c5f0059dc21f016d5c4f9d14df8c" null
    "3d3d3d3d3d735af48180f3" 1 1 206 "9946bb3e71bf3b94278fce25053d0803da6150f7" null
    "3d3d3d363d3d373d3d363d735af46057fd5b3d913e3d90f3" 2 2 200 "f57113d8f6ff35747737f026fe0b37d4d7f42777" null
    "61605a031015605734156057346052606060606073605a03f1506060f3" 1 1 162 "ef9fe029a6134ef5c08a1f4c880efa0af8c3b856" null
    "363d3d373d3d3d363d6f5af43d82803e903d916057fd5bf3" 2 2 131 "a81043fd06d57d140f6ad8c2913dbe87fdecdd5f" "EIP-1167 Optimized"
    "6060526036101560575b5f36818037808036817f5af43d82803e1560573d90f3" 2 2 118 "551485188cded3562290b928e34e963fc2234bf8" null
    "3d3d3d3d363d3d37363d6f5af43d3d93803e6057fd5bf3" 113 1 113 "f3f6373a79021e3610e9e3a97cf8fd58e7ca043e" null
    "60605260513660823760803683735af43d8060843e8160811460578184f3" 2 2 100 "900de34640ad9be267e4255f66fd7888c9353be9" null
    "606052603660603780603660735af480801560578260f3" 6 5 90 "68ee9c1c7af2836b1bbebb4df65d39c54ef21458" null
    "366057343d527f593da1005b363d3d373d3d3d3d618060363936013d735af43d3d938… 78 14 78 "7c340d736976c995db51534fa82376d78cbdbb6f" "solady ClonesWithImmutableArgs"
    "6060526036106157637c60350416638114615780631461575b3660803760803660735… 1 1 56 "00224d9084fd7cdb4a5ce7740cb1ca0dca6be7a6" null
    "363d3d373d3d3d363d715af43d82803e903d916057fd5bf3" 6 6 54 "927fba49239b3c163ff14464ed6c57444836f3a1" null
    "363d3d373d3d3d3d608038038091363936013d735af43d3d93803e6057fd5bf3" 44 5 44 "ab67e433c596dd1382b5756d8c7e4f0d69fb1bc7" null
    "366057343d527f593da1005b3d3d3d3d363d3d37363d735af43d3d93803e6057fd5bf… 2 2 38 "693c49a6296d90e8a8936ad4836a680f551bb97d" null
    "363d3d373d3d3d363d705af43d82803e903d916057fd5bf3" 1 1 25 "bd21981556da7d96ee6cce209f0ac292490065cc" null
    "6060526036818037808036817f5af43d82803e1560573d90f3" 4 2 21 "b85df5ee83eadb92dbc32f13403372c8f880cf02" null
    "6060523373146081146057606080376060f3" 2 2 18 "da07dddec856e9bcdfdcc428f577db94d71759c0" null
    "6036818037808036816f5af41560573d81803e3d81f3" 1 1 18 "9fb5fa690a9e77d7195853283cd6f36d77d8c1ae" null
    "603681803780803681735af41560573d81803e3d90f3" 2 2 18 "c54a597a7c2cf5ed6867095cb69a42eac21fc7a0" null
    "36608037608036606e5af43d60803e603d916057fd5bf3" 1 1 16 "f4907e6182157d564dc180978499b48ebd333f77" null
    "3d3d3d3d363d3d37606036396036013d735af43d928390803e6057fd5bf3" 15 2 15 "e6e1dd9aae13bd8b19853bd15875162ff4fdf553" null
    "5a61116357608080807f5af43d60803e6014156357605160141563575b005b6036106… 1 1 11 "f1718480cd208273e6a317746a6cd8c138ec9a82" null
    "363d3d373d3d3d363d6e5af43d82803e903d916057fd5bf3" 3 3 6 "2ea66a667e258594a05c94345775a02c5fb1b74c" null
    "3d603d52363d59377359523d3d6080590390735af4813d3d82803e91156157f3" 1 1 5 "613359585a176284a5280b072e1d6dc00320c385" null
    "5f5f365f5f37365f735af43d5f5f3e60573d5ffd5b3d5ff3" 5 5 5 "39a0f5da85b4a08686b6e931860e5192deb685f0" "Solady PUSH0"
    "3d3d3d363d3d37608038038091363936013d735af43d82803e3d82826057fd5bf3" 4 2 4 "4498d2f48eb2d7473c30ec3b010b8c4ce69417fb" null
    "60605234801560576080fd5b50603681823780813683735af43d82833e80801560573… 2 1 4 "0e946e9e1089e10992321e1e8a5aa2b9162a5bab" null
    "733314151561573660603760603660735af4156157005bfe5b603580601a604316031… 3 2 4 "66f049111958809841bbe4b81c034da2d953aa0c" null
    "3d3d3d3d363d3d37363d6d5af43d3d93803e6057fd5bf3" 1 1 4 "00000000005df2c9274605abd6773f14578f8a28" null
    "366057343d527f603da13d3df3" 3 1 3 "f29ff96aaea6c9a1fba851f74737f3c069d4f1a9" "0xSplits ClonesWithImmutableArgs"
    "606052603681823780813683735af43d82833e80801560573d83f3" 3 3 3 "2d17e6d1b4ca0d721e48a283793b789de85b8403" null
    "5f5f365f5f37365f735af43d5f5f3e603d5ffd5b3d5ff3" 2 1 2 "5460e1f077e08457f899e7dabb71b2f871f8be23" null
    "60606060735af4" 1 1 2 "beaca7ad81ae2ef8403ee3593635d108f1856331" null
    "5f5f365f5f735af43d5f5f3e60573d5ffd5b3d5ff3" 2 2 2 "b94921e26618c9f0b56e9171b498d2ba471c49ce" null
    "3660803760803660735af43d60803e60573d60fd5b3d60f3" 2 2 2 "60055deba04dcc173515f9398337987655fea808" null
    "6080356381601c14156157815433811461578283fd5b6035603581818383131561575… 1 1 2 "3f9e41b2b4548ccb7b6073c5278738fc59e14183" null
    "363d3d373d3d3d3d618060363936013d735af43d3d93803e6057fd5bf3" 2 1 2 "ae4c7ddef4360d0cb5156b2c1435761525ff3997" "sw0nt ClonesWithImmutableArgs"
    "3660603760803660735af480801560573d8060603e60f3" 1 1 2 "3b1eb95182f769cea6b8808c4da448094756a2ca" null
    "603681823780813683735af4151560573d81823e3d81fd5b3d81823e3d81f3" 1 1 2 "e36d76da7431d38d1958ef0367785030d523fa17" null
    "60605234801560576080fd5b5060513660823760803683735af43d8060843e8160811… 1 1 2 "2769f4170a9b35ccdb946dc0ff853792f9dbb1ae" null
    "3660603760803660735af41560573d8060603e60f3" 1 1 2 "1a1a913f2334c7424efb093413ddc3af014175eb" null
    "6060523660576f5f525f805f80735af460575f80fd5b005b5f80fdfea2642212207e6… 1 1 1 "fca8d0ac3eb28a7e3bef2e313b5ddf5c83076e0a" null
    "6060523360526060207f8114615763541561577f60527c60527c60526060526060fd5… 1 1 1 "09afae029d38b76a330a1bdee84f6e03a4979359" null
    "3373146157005b3661575f5f5f5f47335af1005b7f5f52475f5b8035601c60525f5f6… 1 1 1 "878715422f2fc2d939f8d5a4e77eecd80158aa4b" null
    "3d3d343d146057f3" 1 1 1 "4e4f343e93ad73d7098af84418023b5677917582" null
    "6060523660576060565b005b6060565b005b3660803760803660735af43d60803e806… 1 1 1 "6b741aa01f060fcd702ff0baade110372f219d39" null
    "60605234801561576080fd5b5060361061576035601c80631461575b3660803760803… 1 1 1 "335157e30f88ffe30f9f03cde78c44265922895d" null
    "60548060575b3360553660555b80358155600136811060576060603933606034f5806… 1 1 1 "2319c999808d589b5fb33349b182f000d281dc65" null
    "733314151561573660603760603660735af450005b60356181601c61565b6035601c8… 1 1 1 "9d68689a0568caed355a2f22dbde370bc33e671f" null
    "60605236801561573660803760803660735af43d60803e80801561573d60f3" 1 1 1 "48babd296989592346e8b5cb904895f808e75e61" null
    "733314151561573660603760603660735af4156157005bfe5b60356181601c61565b6… 1 1 1 "12e98c9b9b266255bf037ccafcf87657e9a0b31b" null
    "365f5f375f5f365f6c5af43d5f5f3e5f3d916057fd5bf3" 1 1 1 "0000000000bf2686748e1c0255036e7617e7e8a5" null
    "363d3d373d3d3d363d735af43d82803e903d9160575b61565b6060606047735af100" 1 1 1 "1aa6c2224d19457fdf7d7143243267859b05c1cb" null
    "3d6080603d3981f3" 1 1 1 "d9244c769512d951eb8939075d1857011aad9248" null
    "6060523660577f5f525f80605f735af460575f80fd5b005b5f80fdfea264221220d8e… 1 1 1 "7631961ad277714cce7567f2303e88d881d13b5a" null
    "60605234151561573660803760803660735af43d60803e8060811461573d60f3" 1 1 1 "b22a3f3d4b7378275de40d2d840d9f4678dada81" null
    "603681823780813683735af43d82833e8060811460573d83f3" 1 1 1 "a009c7e3718740f56294914b3f96133f338df0b5" null

    It’s left as an exercise for the reader to see if I’ve missed anything, but the code certainly hasn’t.

    Hope you learned something interesting today.

    ]]>     ethereum data https://banteg.xyz/posts/minimal-proxies/index.html Mon, 11 Sep 2023 20:00:00 GMT     So you found a compiler bug banteg https://banteg.xyz/posts/vyper-opcodes/index.html

    Today I will walk you through the development of a pipeline that helps Vyper devs identify potentially vulnerable contracts, following a real compiler bug disclosure1. We will find all contracts that use certain opcodes and precompiles.

  • 1 incorrect order of evaluation for some builtins

    • The pipeline would consist of the following steps:

    1. Find all Vyper contracts
    2. Strip them down to their code section
    3. Look for patterns in opcodes
    4. Contact the affected protocols

    You can also reference this post for how the compiler signature, the immutable support, and the init code have changed over the development of Vyper.

    Stripping metadata

    Smart contracts on Ethereum can mix code and data sections. To accurately assess the opcodes used by a contract it is crucial to only look at the executable section. We would need to find a way to ignore the metadata, immutables or any other non-code portions of the runtime code that might result in false positives when interpreted as opcodes.

    This section’s goal is to determine the total size of immutables so we can strip them.

    Vyper compiler signature

    Since 0.3.4 Vyper appends a compiler signature2 with the compiler name and 3 version bytes at the very end of the code output.

  • 2 add vyper signature to bytecode

    • cbor.loads(b"\xa1\x65vyper\x83\x00\x03\x09")
    {'vyper': [0, 3, 9]}

    Since 0.3.5 it also appends3 a two-byte length after it.

  • 3 add cbor length metadata

    • int(b"\x00\x0b".hex(), 16)
    11

    So far seems easy, we just read the offset and everything before it is code. But this method doesn’t account for immutables that come after the signature.

    A more reliable method is to simply split on \xa1\x65vyper\x83 and treat everything after as a data section. The problem is, immutables were introduced4 in 0.3.1, before the compiler signature has existed.

  • 4 feat: immutable variables

    • Another problem is the signature will be removed5 from runtime code altogether in 0.3.10. There is an ongoing discussion6 about whether to keep it.

  • 5 chore: remove vyper signature from runtime

  • 6 Keep the vyper compiler version signature in the runtime code

    • For older versions we could use some old but proven heuristics:

    • 6004361015 prefix detects all contracts written in Vyper 0.2.0 to 0.2.4 and 0.2.11 to 0.3.3
    • 341561000a prefix was used in versions 0.2.5 to 0.2.8

    Load all Vypers

    We use cryo contracts dataset7 to quickly find all contracts that look like Vyper.

  • 7 Run cryo contracts --align and wait about 10 hours

    • contracts = pl.scan_parquet("~/data/contracts/*.parquet")
vyper_sig = b"\xa1\x65vyper\x83"
vypers = contracts.filter(
    (
        pl.col("code").bin.starts_with(bytes.fromhex("6004361015"))
        | pl.col("code").bin.starts_with(bytes.fromhex("341561000a"))
        | pl.col("init_code").bin.contains(b"\xa1\x65vyper\x83")
    )
    & ~pl.col("code").bin.contains(b"\x64solc\x43")
).collect()

len(vypers)
    3226

    Code within code

    Given the init code contains the runtime code, we can scan from where it starts and continue until it diverges or the init code runs out.

    def find_runtime_in_init(data):
    init_offset = data["init_code"].index(data["code"][:32])
    code_size = 0

    # zip terminates when the smallest iterable runs out
    for left, right in zip(data["init_code"][init_offset:], data["code"]):
        if left != right:
            break
        code_size += 1

    op = data["init_code"][init_offset - 1]
    return {
        "pre_opcode": opcodes.get(op, hex(op)),
        "init_offset": init_offset,
        "code_size": code_size,
        "runtime_size": len(data["code"]),
    }
    Apply and output 
    results = (
    vypers.with_columns(
        search=pl.struct("init_code", "code").apply(find_runtime_in_init)
    )
    .unnest("search")
    .with_columns(data_size=pl.col("runtime_size") - pl.col("code_size"))
)
(
    results.select(
        ["pre_opcode", "init_offset", "code_size", "runtime_size", "data_size"]
    )
    .filter(pl.col("data_size") > 0)
    .sample(5)
)
    shape: (5, 5)
    pre_opcode init_offset code_size runtime_size data_size
    str i64 i64 i64 i64
    "JUMP" 800 10439 10663 224
    "JUMP" 3049 19226 19290 64
    "JUMP" 67 394 458 64
    "JUMP" 749 23732 23892 160
    "RETURN" 835 3448 3480 32

    The sample shows the data doesn’t always align on the word size. It’s either correct or one byte smaller, fixable with a ceil rounding.

    results.groupby((pl.col("data_size") % 32).alias("remainder")).agg(pl.count())
    shape: (2, 2)
    remainder count
    i64 u32
    0 2889
    31 337

    Preceding opcode

    Now let’s look at common opcodes that come before the runtime code in the init code.

    results.groupby("pre_opcode").agg(pl.count()).sort("count", descending=True)
    shape: (5, 2)
    pre_opcode count
    str u32
    "JUMP" 2166
    "RETURN" 1057
    "0xad" 1
    "STOP" 1
    "0x28" 1

    The heuristic for finding old Vypers has caught some extra contracts.

    Vyper has historically only used JUMP and RETURN. Up to version 0.3.1, the runtime code is put in the middle with the init routine located near the end.

    In 0.3.2, when compile-time calculation of memory offsets for copying immutables 8 was introduced, the runtime code comes after the init code, right after RETURN that outputs it.

  • 8 feat: introduce special immutables address space

    • By 0.3.10 all arguments to CODECOPY and RETURN became pre-computed values.

    Compare the init code below for other differences. The runtime section is shown with an indentation, the compiler signature is omitted.

    0000: PUSH1 0x20
0002: PUSH2 0x82
0005: PUSH1 0x80
0007: CODECOPY
0008: PUSH1 0x80
000a: MLOAD
000b: PUSH1 0xe0
000d: MSTORE
000e: PUSH2 0x5b
0011: JUMP
    0012: PUSH1 0x4
    --snip--
    005a: REVERT
005b: JUMPDEST
005c: PUSH2 0x12
005f: PUSH2 0x5b
0062: SUB
0063: PUSH2 0x12
0066: PUSH2 0x100
0069: CODECOPY
006a: PUSH2 0x12
006d: PUSH2 0x5b
0070: SUB
0071: PUSH1 0xe0
0073: MLOAD
0074: DUP2
0075: PUSH2 0x100
0078: ADD
0079: MSTORE
007a: DUP1
007b: PUSH1 0x20
007d: ADD
007e: PUSH2 0x100
0081: RETURN
    0000: PUSH1 0x20
0002: PUSH2 0x6d
0005: PUSH1 0x0
0007: CODECOPY
0008: PUSH1 0x0
000a: MLOAD
000b: PUSH4 0x44
0010: MSTORE
0011: PUSH2 0x44
0014: PUSH2 0x29
0017: PUSH4 0x0
001c: CODECOPY
001d: PUSH2 0x44
0020: PUSH1 0x20
0022: ADD
0023: PUSH4 0x0
0028: RETURN
    0029: PUSH1 0x4
    --snip--
    006c: REVERT
    0000: PUSH1 0x4a
0002: MLOAD
0003: POP
0004: PUSH1 0x20
0006: PUSH2 0x69
0009: PUSH0
000a: CODECOPY
000b: PUSH0
000c: MLOAD
000d: PUSH1 0x4a
000f: MSTORE
0010: PUSH2 0x4a
0013: PUSH2 0x1f
0016: PUSH1 0x0
0018: CODECOPY
0019: PUSH2 0x6a
001c: PUSH1 0x0
001e: RETURN
    001f: PUSH1 0x3
    --snip--
    005b: REVERT

    Static analysis

    A small harness to run some code against all Vyper versions would be useful at this point. It will be our git bisect that will help us learn when a certain difference was introduced. Let’s work our way backwards from the latest version.

    0.3.10 - 0.3.8

    For 0.3.10 we can find something like PUSH1 0x86 MLOAD POP at the very beginning of the init code.

    It touches and then immediately discards a value, causing memory expansion 9 to 0x86 + 0x20 = 0xa6, which would be the resulting size of the returned runtime code.

  • 9 The memory allocation behavior happens since Vyper 0.3.8, see fix: uninitialized immutable values

    • Further on we can find PUSH2 0x066 PUSH2 0x04C PUSH1 0x0 CODECOPY, which translates to codecopy(dest_offset=0x0, mem_offset=0x4c, size=0x66). The size here is the size of the runtime code sans immutables. Thus we have 0xa6 - 0x66 = 0x40 or two words of immutables. If we terminate on the last CODECOPY before the first RETURN, we will get all the data we need.

    0.3.7 - 0.3.4

    These versions don’t have memory expansion at the beginning, but we can still grab the values from the hardcoded arguments to CODECOPY and RETURN:

    PUSH2 0x07F PUSH2 0x046 PUSH1 0x0 CODECOPY
PUSH2 0x0BF PUSH1 0x0 RETURN

    These would translate to codecopy(dest_offset=0x0, mem_offset=0x46, size=0x7f) and return(mem_offset=0x0, size=0xbf). So the runtime code measures 0x7f bytes without data and the data section is 0xbf - 0x7f = 0x40 bytes long.

    0.3.3 - 0.3.2

    Same but the size argument to RETURN is not hardcoded.

    PUSH2 0x063 PUSH2 0x050 PUSH4 0x0000 CODECOPY
PUSH2 0x063 PUSH1 0x40 ADD PUSH4 0x0000 RETURN

    0.3.1 and below

    This version has even more math going on. At this point I gave up and decided the easiest option would be to simply run the init code.

    PUSH2 0x037 PUSH2 0x0A0 SUB PUSH2 0x037 PUSH2 0x120 CODECOPY
PUSH2 0x037 PUSH2 0x0A0 SUB PUSH1 0xE0 MLOAD
DUP2 PUSH2 0x120 ADD MSTORE
PUSH2 0x10 MLOAD
DUP2 PUSH2 0x140 ADD MSTORE
DUP1 PUSH1 0x40 ADD PUSH2 0x120 RETURN

    Execution path

    I wanted to try out the newly-released executable spec for Ethereum10, so I wrote a toy environment that can run the init code and grab the arguments to CODECOPY and RETURN from the stack.

  • 10 ethereum/execution-specs

    • Prepare the environment 
    from dataclasses import dataclass, asdict

from ethereum.base_types import Bytes0
from ethereum.shanghai.state import State, increment_nonce
from ethereum.shanghai.utils.message import prepare_message
from ethereum.shanghai.vm import Environment, Evm, Message, interpreter
from ethereum.shanghai.vm.instructions import Ops
from ethereum.shanghai.vm.stack import pop

caller = bytes.fromhex("b00ba" * 8)


def prepare_env():
    state = State()
    increment_nonce(state, caller)
    return Environment(
        caller, [], caller, bytes(20), 0, 0, 30_000_000, 0, 0, bytes(32), state, 1
    )


def make_deploy_message(code):
    env = prepare_env()
    return prepare_message(caller, Bytes0(), 0, bytes.fromhex(code), 30_000_000, env)
    Init codes for a contract with immutables 
    codes = {
    "0.3.10": "60865150346100485760206100bf5f395f516066527ffefefefefefefefefefefefefefefefefefefefefefefefefefefefefefefefe60865261006661004c6000396100a66000f35b5f80fd5f3560e01c60026003820660011b61006001601e395f51565b630c55699c8118610058573461005c57602061006660403960206040f3610058565b63a56dfe4a8118610058573461005c57602061008660403960206040f35b5f5ffd5b5f80fd00580018003aa16576797065728300030a000b",
    "0.3.9": "60875150346100b05760206100b45f395f516067527ffefefefefefefefefefefefefefefefefefefefefefefefefefefefefefefefe6087526100676100486000396100a76000f36003361161000c57610052565b5f3560e01c3461005657630c55699c81186100335760206100675f395f5160405260206040f35b63a56dfe4a81186100505760206100875f395f5160405260206040f35b505b5f5ffd5b5f80fda165767970657283000309000b005b5f80fd",
    "0.3.8": "60795150346100a25760206100a65f395f516059527ffefefefefefefefefefefefefefefefefefefefefefefefefefefefefefefefe6079526100596100486000396100996000f35f3560e01c3461004857630c55699c81186100265760206100595f395f5160405260206040f35b63a56dfe4a81186100435760206100795f395f5160405260206040f35b505f5ffd5b5f80fda165767970657283000308000b005b5f80fd",
    "0.3.7": "346100c65760206100cb600039600051607f527ffefefefefefefefefefefefefefefefefefefefefefefefefefefefefefefefe609f5261007f6100466000396100bf6000f36003361161000c57610067565b60003560e01c3461006d57630c55699c811861003e576004361061006d57602061007f60003960005160405260206040f35b63a56dfe4a8118610065576004361061006d57602061009f60003960005160405260206040f35b505b60006000fd5b600080fda165767970657283000307000b005b600080fd",
    "0.3.6": "346100c65760206100cb600039600051607f527ffefefefefefefefefefefefefefefefefefefefefefefefefefefefefefefefe609f5261007f6100466000396100bf6000f36003361161000c57610067565b60003560e01c3461006d57630c55699c811861003e576004361861006d57602061007f60003960005160405260206040f35b63a56dfe4a8118610065576004361861006d57602061009f60003960005160405260206040f35b505b60006000fd5b600080fda165767970657283000306000b005b600080fd",
    "0.3.4": "346100c45760206100c9600039600051607d527ffefefefefefefefefefefefefefefefefefefefefefefefefefefefefefefefe609d5261007d6100466000396100bd6000f36003361161000c57610067565b60003560e01c3461006d57630c55699c811861003e576004361861006d57602061007d60003960005160405260206040f35b63a56dfe4a8118610065576004361861006d57602061009d60003960005160405260206040f35b505b60006000fd5b600080fda165767970657283000304005b600080fd",
    "0.3.3": "60206100b36000396000516300000063527ffefefefefefefefefefefefefefefefefefefefefefefefefefefefefefefefe6300000083526100636100506300000000396100636040016300000000f3600436101561000d57610058565b60003560e01c3461005e57630c55699c811861003757602061006360003960005160405260206040f35b63a56dfe4a811861005657602061008360003960005160405260206040f35b505b60006000fd5b600080fd",
    "0.3.2": "60206100b36000396000516300000063527ffefefefefefefefefefefefefefefefefefefefefefefefefefefefefefefefe6300000083526100636100506300000000396100636040016300000000f3600436101561000d57610058565b60003560e01c3461005e57630c55699c811861003757602061006360003960005160405260206040f35b63a56dfe4a811861005657602061008360003960005160405260206040f35b505b60006000fd5b600080fd",
    "0.3.1": "60206100d160803960805160e0527ffefefefefefefefefefefefefefefefefefefefefefefefefefefefefefefefe610100526100a056600436101561000d5761005e565b60046000601c376000513461006457630c55699c811861003c5760206040380360803960805160e052602060e0f35b63a56dfe4a811861005c5760206020380360803960805160e052602060e0f35b505b60006000fd5b600080fd5b6100376100a003610037610120396100376100a00360e0518161012001526101005181610140015280604001610120f3",
}

    We can easily plug in a custom tracer by patching ethereum.evm_trace import.

    @dataclass
class Tracer:
    code_size: int = None
    runtime_size: int = None
    init_offset: int = None

    def __call__(self, evm, op):
        match op:
            case Ops.CODECOPY:
                self.init_offset = evm.stack[-2]
                self.code_size = evm.stack[-3]
            case Ops.RETURN:
                self.runtime_size = evm.stack[-2]

    @property
    def data_size(self):
        return self.runtime_size - self.code_size


def exec_init_code(code):
    tracer = Tracer()
    interpreter.evm_trace = tracer
    interpreter.execute_code(make_deploy_message(code), prepare_env())
    return tracer
    Execute and output 
    data = [
    {"version": str(version)} | asdict(exec_init_code(codes[version]))
    for version in codes
]
(
    pl.DataFrame(data).with_columns(
        data_size=pl.col("runtime_size") - pl.col("code_size")
    )
)
    shape: (9, 5)
    version code_size runtime_size init_offset data_size
    str i64 i64 i64 i64
    "0.3.10" 102 166 76 64
    "0.3.9" 103 167 72 64
    "0.3.8" 89 153 72 64
    "0.3.7" 127 191 70 64
    "0.3.6" 127 191 70 64
    "0.3.4" 125 189 70 64
    "0.3.3" 99 163 80 64
    "0.3.2" 99 163 80 64
    "0.3.1" 105 169 55 64

    These results are perfect, and we can move on to running the real init codes.

    Replay deployments

    For best results it’s easiest to replay the deployment transactions in the exact environment they have been created in. The tracer would also need and few updates to handle more complex cases like factory deployments.

    There are two ways to get opcode-resolution traces: debug_traceTransaction aka Geth-style and trace_replayTransaction in vmTrace mode aka Parity-style.

    You should choose Geth traces if you are doing the analysis on the same machine.

    Otherwise choose Parity traces paired with evm-trace for a faster drop-in replacement that sends 1000x less data over the network11. Parity format has its downsides as it’s not streamable, more complex and quite brittle12.

  • 11 Read 100x faster EVM traces with Python if you want to learn how it’s possible

  • 12 Recent examples include a random renaming of an opcode, missing push (1, 2, 3) and memory outputs.

    • Ape supports streaming request decoding, which we use to construct a trace frame iterator.

    from evm_trace.vmtrace import VMTraceFrame


def get_geth_frames(tx: bytes) -> Iterator[VMTraceFrame]:
    frames = chain.provider._stream_request(
        "debug_traceTransaction", [encode_hex(tx)], "result.structLogs.item"
    )
    for frame in frames:
        yield VMTraceFrame(
            address=None,
            pc=frame["pc"],
            op=frame["op"],
            depth=frame["depth"],
            stack=[int(x, 16) for x in frame["stack"]],
            memory=b"".join(bytes.fromhex(x) for x in frame["memory"]),
            storage=None,
        )
    from evm_trace.vmtrace import VMTraceFrame, from_rpc_response, to_trace_frames


def get_vmtrace_frames(tx: bytes) -> Iterator[VMTraceFrame]:
    resp = httpx.post(
        chain.provider.uri,
        json={
            "jsonrpc": "2.0",
            "id": 1,
            "method": "trace_replayTransaction",
            "params": [encode_hex(tx), ["vmTrace"]],
        },
    )
    trace = from_rpc_response(resp.content)
    return to_trace_frames(trace, copy_memory=False)

    To support factories, we need to timely grab the values from the stack at the moment each contract is initialized.

    When a contract is created, the EVM state is suspended, and we go one level deeper. There we find a fresh EVM that has an empty stack and no memory. After the init code has run, the control is returned to the suspended EVM and it’s business as usual with the exception of a newly created contract address on a stack.

    For deployments from an EOA, there is no place where the control is returned, so we can’t grab the contract address. We can only compute it as keccak(rlp.encode([deployer, nonce]))[-20:], but we don’t use it here, instead we use a placeholder name for EOA deployments and return it if we didn’t capture the requested address.

    def find_offsets(tx: bytes, address: bytes = None):
    create = 0
    current = {}
    contracts = {}
    for frame in get_vmtrace_frames(tx):
        if frame.depth == create:
            addr = frame.stack[-1].to_bytes(20, "big")
            create = 0
            contracts[addr] = current.copy()
        match frame.op:
            case "CREATE" | "CREATE2":
                create = frame.depth
            case "CODECOPY":
                current["init_offset"] = frame.stack[-2]
                current["code_size"] = frame.stack[-3]
            case "RETURN":
                current["runtime_size"] = frame.stack[-2]
    contracts["eoa"] = current.copy()
    if address:
        return contracts.get(address, contracts["eoa"])
    return contracts


find_offsets(vypers[-2, "transaction_hash"], vypers[-2, "contract_address"])
    {'init_offset': 29, 'code_size': 829, 'runtime_size': 829}

    I benched this against all 3226 contracts we found earlier and it took 6min 11s with Geth and 7min 56s with Parity traces against Erigon on a local machine, with 4x more CPU time with Parity.

    A third method

    But what if I told you we can make it 50x faster? One downside though, we’ll need to write Javascript.

    You probably know that debug_traceTransaction has a tracer argument. Common useful tracers13 include callTracer and prestateTracer.

  • 13 Built-in tracers

    • Instead of a standard tracer name, you can pass Javascript14 code as the tracer argument. Let’s see what happens if we do that.

  • 14 Tutorial for Javascript tracing

    • {
    create: 0,
    current: {},
    contracts: [],
    step: function(log, db) {
        if (log.getDepth() == this.create) {
            const addr = log.stack.peek(0)
            this.contracts.push(Object.assign({addr: addr}, this.current))
            this.create = 0
        }
        if (log.op == 'CREATE' || log.op == 'CREATE2') {
            this.create = log.getDepth()
        }
        if (log.op == 'CODECOPY') {
            this.current.init_offset = log.stack.peek(1)
            this.current.code_size = log.stack.peek(2)
        }
        if (log.op == 'RETURN') {
            this.current.runtime_size = log.stack.peek(1)
        }
    },
    fault: function(log, db) {this.contracts.push({error: JSON.stringify(log)})},
    result: function(ctx, db) {
        this.contracts.push(Object.assign({addr: null}, this.current))
        return this.contracts
    }
}

    I’m not friends with Javascript, so excuse some post-processing to arrive at the same format.

    def trace_custom(tx: bytes, address: bytes):
    resp = chain.provider._make_request(
        "debug_traceTransaction", [encode_hex(tx), {"tracer": tracer}]
    )
    results = {}
    for item in resp:
        if item["addr"] is not None:
            item["addr"] = int(item["addr"]).to_bytes(20, "big")

        results[item["addr"]] = {
            "runtime_size": int(item["runtime_size"]),
            "init_offset": int(item["init_offset"]) if "init_offset" in item else None,
            "code_size": int(item["code_size"]) if "code_size" in item else None,
        }

    if address is not None:
        return results.get(address, results[None])

    return results


trace_custom(vypers[-2, "transaction_hash"], vypers[-2, "contract_address"])
    {'runtime_size': 829, 'init_offset': 29, 'code_size': 829}

    As you can see, we got the same results. And with the new tracer it only takes 7 seconds to check every contract deployment that interests us.

    Cleanup code

    After acquiring the metadata, we can proceed with deleting it.

    def clean_code(code, code_size):
    # 0.3.1 strip immutables
    code = code[:code_size]
    # 0.3.5+ strip vyper signature size
    if code[-2:] == b"\x00\x0b":
        code = code[:-13]
    # 0.3.4 strip vyper signtaure
    elif code[-11:-3] == b"\xa1\x65vyper\x83":
        code = code[:-11]

    return code


vypers = vypers.with_columns(
    clean_code=pl.struct("code", "code_size").apply(
        lambda d: clean_code(d["code"], d["code_size"])
    )
)

    Find vulnerable contracts

    The disclosure mentions uint256_addmod, uint256_mulmod, ecadd and ecmul as the affected functions. The first two are opcodes, while the other two are precompiles.

    Disassemble

    In both cases we’ll need to disassemble the code, a cakewalk compared to what we have endured. We read the code sequentially, look up the opcodes, and when we encounter PUSH1-PUSH32, we read the value and skip ahead.

    def disasm(code):
    result = []
    pc = 0
    while pc < len(code):
        op = code[pc]
        opcode = opcodes.get(op, f"unknown_{hex(op)}")
        result.append(opcode)
        if Ops.PUSH1.value <= op <= Ops.PUSH32.value:
            push_size = op - Ops.PUSH0.value
            push_value = code[pc + 1 : pc + 1 + push_size]
            result.append(hex(int.from_bytes(push_value, "big")))
            pc += push_size
        pc += 1

    return " ".join(result)


disasm(vypers[-1, "clean_code"])
    'PUSH1 0x3 CALLDATASIZE GT PUSH2 0xc JUMPI PUSH2 0x1882 JUMP JUMPDEST PUSH0 CALLDATALOAD PUSH1 0xe0 SHR CALLVALUE PUSH2 0x240a JUMPI PUSH4 0xfc0c546a DUP2 XOR PUSH2 0x2d JUMPI PUSH1 0x1 SLOAD PUSH1 0x40 MSTORE PUSH1 0x20 PUSH1 0x40 RETURN JUMPDEST PUSH4 0x47fc9aa DUP2 XOR PUSH2 0x44 JUMPI PUSH1 0x2 SLOAD PUSH1 0x40 MSTORE PUSH1 0x20 PUSH1 0x40 RETURN JUMPDEST PUSH4 0xcbf9fe5f DUP2 XOR PUSH2 0x87 JUMPI PUSH1 0x24 CALLDATASIZE LT PUSH2 0x240a JUMPI PUSH1 0x4 CALLDATALOAD DUP1 PUSH1 0xa0 SHR PUSH2 0x240a JUMPI PUSH1 0x40 MSTORE PUSH1 0x3 PUSH1 0x40 MLOAD PUSH1 0x20 MSTORE PUSH0 MSTORE PUSH1 0x40 PUSH0 KECCAK DUP1 SLOAD PUSH1 0x60 MSTORE PUSH1 0x1 DUP2 ADD SLOAD PUSH1 0x80 MSTORE POP PUSH1 0x40 PUSH1 0x60 RETURN JUMPDEST PUSH4 0x900cf0cf DUP2 XOR PUSH2 0x9e JUMPI PUSH1 0x4 SLOAD PUSH1 0x40 MSTORE PUSH1 0x20 PUSH1 0x40 RETURN JUMPDEST PUSH4 0xd1febfb9 DUP2 XOR PUSH2 0xf2 JUMPI PUSH1 0x24 CALLDATASIZE LT PUSH2 0x240a JUMPI PUSH1 0x4 CALLDATALOAD PUSH13 0x1431e0fae6d7217ca9fffffff DUP2 GT PUSH2 0x240a JUMPI PUSH1 0x2 SHL PUSH1 0x5 ADD DUP1 SLOAD PUSH1 0x40 MSTORE PUSH1 0x1 DUP2 ADD SLOAD PUSH1 0x60 MSTORE PUSH1 0x2 DUP2 ADD SLOAD PUSH1 0x80 MSTORE PUSH1 0x3 DUP2 ADD SLOAD PUSH1 0xa0 MSTORE POP PUSH1 0x80 PUSH1 0x40 RETURN JUMPDEST PUSH4 0x28d09d47 DUP2 XOR PUSH2 0x166 JUMPI PUSH1 0x44 CALLDATASIZE LT PUSH2 0x240a JUMPI PUSH1 0x4 CALLDATALOAD DUP1 PUSH1 0xa0 SHR PUSH2 0x240a JUMPI PUSH1 0x40 MSTORE PUSH13 0x50c783eb9b5c85f2a80000005 PUSH1 0x40 MLOAD PUSH1 0x20 MSTORE PUSH0 MSTORE PUSH1 0x40 PUSH0 KECCAK PUSH1 0x24 CALLDATALOAD PUSH4 0x3b9ac9ff DUP2 GT PUSH2 0x240a JUMPI PUSH1 0x2 SHL DUP2 ADD SWAP1 POP DUP1 SLOAD PUSH1 0x60 MSTORE PUSH1 0x1 DUP2 ADD SLOAD PUSH1 0x80 MSTORE PUSH1 0x2 DUP2 ADD SLOAD PUSH1 0xa0 MSTORE PUSH1 0x3 DUP2 ADD SLOAD PUSH1 0xc0 MSTORE POP PUSH1 0x80 PUSH1 0x60 RETURN JUMPDEST PUSH4 0x10ae757 DUP2 XOR PUSH2 0x1ab JUMPI PUSH1 0x24 CALLDATASIZE LT PUSH2 0x240a JUMPI PUSH1 0x4 CALLDATALOAD DUP1 PUSH1 0xa0 SHR PUSH2 0x240a JUMPI PUSH1 0x40 MSTORE PUSH13 0x50c783eb9b5c85f2a80000006 PUSH1 0x40 MLOAD PUSH1 0x20 MSTORE PUSH0 MSTORE PUSH1 0x40 PUSH0 KECCAK SLOAD PUSH1 0x60 MSTORE PUSH1 0x20 PUSH1 0x60 RETURN JUMPDEST PUSH4 0x71197484 DUP2 XOR PUSH2 0x1e2 JUMPI PUSH1 0x24 CALLDATASIZE LT PUSH2 0x240a JUMPI PUSH13 0x50c783eb9b5c85f2a80000007 PUSH1 0x4 CALLDATALOAD PUSH1 0x20 MSTORE PUSH0 MSTORE PUSH1 0x40 PUSH0 KECCAK SLOAD PUSH1 0x40 MSTORE PUSH1 0x20 PUSH1 0x40 RETURN JUMPDEST PUSH4 0xf77c4791 DUP2 XOR PUSH2 0x205 JUMPI PUSH13 0x50c783eb9b5c85f2a80000008 SLOAD PUSH1 0x40 MSTORE PUSH1 0x20 PUSH1 0x40 RETURN JUMPDEST PUSH4 0xbef97c87 DUP2 XOR PUSH2 0x228 JUMPI PUSH13 0x50c783eb9b5c85f2a80000009 SLOAD PUSH1 0x40 MSTORE PUSH1 0x20 PUSH1 0x40 RETURN JUMPDEST PUSH4 0x6fdde03 DUP2 XOR PUSH2 0x2bb JUMPI PUSH1 0x20 DUP1 PUSH1 0x40 MSTORE DUP1 PUSH1 0x40 ADD PUSH13 0x50c783eb9b5c85f2a8000000a SLOAD PUSH1 0x20 DUP3 ADD PUSH0 DUP3 PUSH1 0x1f ADD PUSH1 0x5 SHR PUSH1 0x2 DUP2 GT PUSH2 0x240a JUMPI DUP1 ISZERO PUSH2 0x28b JUMPI SWAP1 JUMPDEST DUP1 PUSH13 0x50c783eb9b5c85f2a8000000b ADD SLOAD DUP2 PUSH1 0x5 SHL DUP5 ADD MSTORE PUSH1 0x1 ADD DUP2 DUP2 XOR PUSH2 0x268 JUMPI JUMPDEST POP POP POP DUP1 DUP3 MSTORE POP DUP1 MLOAD DUP1 PUSH1 0x20 DUP4 ADD ADD PUSH1 0x1f DUP3 PUSH0 SUB AND CALLDATASIZE DUP3 CALLDATACOPY POP POP PUSH1 0x1f NOT PUSH1 0x1f DUP3 MLOAD PUSH1 0x20 ADD ADD AND SWAP1 POP DUP2 ADD SWAP1 POP PUSH1 0x40 RETURN JUMPDEST PUSH4 0x95d89b41 DUP2 XOR PUSH2 0x322 JUMPI PUSH1 0x20 DUP1 PUSH1 0x40 MSTORE DUP1 PUSH1 0x40 ADD PUSH13 0x50c783eb9b5c85f2a8000000d SLOAD PUSH1 0x20 DUP3 ADD PUSH13 0x50c783eb9b5c85f2a8000000e SLOAD DUP2 MSTORE POP DUP1 DUP3 MSTORE POP DUP1 MLOAD DUP1 PUSH1 0x20 DUP4 ADD ADD PUSH1 0x1f DUP3 PUSH0 SUB AND CALLDATASIZE DUP3 CALLDATACOPY POP POP PUSH1 0x1f NOT PUSH1 0x1f DUP3 MLOAD PUSH1 0x20 ADD ADD AND SWAP1 POP DUP2 ADD SWAP1 POP PUSH1 0x40 RETURN JUMPDEST PUSH4 0x54fd4d50 DUP2 XOR PUSH2 0x389 JUMPI PUSH1 0x20 DUP1 PUSH1 0x40 MSTORE DUP1 PUSH1 0x40 ADD PUSH13 0x50c783eb9b5c85f2a8000000f SLOAD PUSH1 0x20 DUP3 ADD PUSH13 0x50c783eb9b5c85f2a80000010 SLOAD DUP2 MSTORE POP DUP1 DUP3 MSTORE POP DUP1 MLOAD DUP1 PUSH1 0x20 DUP4 ADD ADD PUSH1 0x1f DUP3 PUSH0 SUB AND CALLDATASIZE DUP3 CALLDATACOPY POP POP PUSH1 0x1f NOT PUSH1 0x1f DUP3 MLOAD PUSH1 0x20 ADD ADD AND SWAP1 POP DUP2 ADD SWAP1 POP PUSH1 0x40 RETURN JUMPDEST PUSH4 0x313ce567 DUP2 XOR PUSH2 0x3ac JUMPI PUSH13 0x50c783eb9b5c85f2a80000011 SLOAD PUSH1 0x40 MSTORE PUSH1 0x20 PUSH1 0x40 RETURN JUMPDEST PUSH4 0x8ff36fd1 DUP2 XOR PUSH2 0x3cf JUMPI PUSH13 0x50c783eb9b5c85f2a80000012 SLOAD PUSH1 0x40 MSTORE PUSH1 0x20 PUSH1 0x40 RETURN JUMPDEST PUSH4 0x7175d4f7 DUP2 XOR PUSH2 0x3f2 JUMPI PUSH13 0x50c783eb9b5c85f2a80000013 SLOAD PUSH1 0x40 MSTORE PUSH1 0x20 PUSH1 0x40 RETURN JUMPDEST PUSH4 0xf851a440 DUP2 XOR PUSH2 0x415 JUMPI PUSH13 0x50c783eb9b5c85f2a80000014 SLOAD PUSH1 0x40 MSTORE PUSH1 0x20 PUSH1 0x40 RETURN JUMPDEST PUSH4 0x17f7182a DUP2 XOR PUSH2 0x438 JUMPI PUSH13 0x50c783eb9b5c85f2a80000015 SLOAD PUSH1 0x40 MSTORE PUSH1 0x20 PUSH1 0x40 RETURN JUMPDEST PUSH4 0x6b441a40 DUP2 XOR PUSH2 0x4ae JUMPI PUSH1 0x24 CALLDATASIZE LT PUSH2 0x240a JUMPI PUSH1 0x4 CALLDATALOAD DUP1 PUSH1 0xa0 SHR PUSH2 0x240a JUMPI PUSH1 0x40 MSTORE PUSH13 0x50c783eb9b5c85f2a80000014 SLOAD CALLER XOR PUSH2 0x240a JUMPI PUSH1 0x40 MLOAD PUSH13 0x50c783eb9b5c85f2a80000015 SSTORE PUSH32 0x2f56810a6bf40af059b96d3aea4db54081f378029a518390491093a7b67032e9 PUSH1 0x40 MLOAD PUSH1 0x60 MSTORE PUSH1 0x20 PUSH1 0x60 LOG1 STOP JUMPDEST PUSH4 0x6a1c05ae DUP2 XOR PUSH2 0x528 JUMPI PUSH13 0x50c783eb9b5c85f2a80000014 SLOAD CALLER XOR PUSH2 0x240a JUMPI PUSH13 0x50c783eb9b5c85f2a80000015 SLOAD PUSH1 0x40 MSTORE PUSH1 0x40 MLOAD ISZERO PUSH2 0x240a JUMPI PUSH1 0x40 MLOAD PUSH13 0x50c783eb9b5c85f2a80000014 SSTORE PUSH32 0xebee2d5739011062cb4f14113f3b36bf0ffe3da5c0568f64189d1012a1189105 PUSH1 0x40 MLOAD PUSH1 0x60 MSTORE PUSH1 0x20 PUSH1 0x60 LOG1 STOP JUMPDEST PUSH4 0x57f901e2 DUP2 XOR PUSH2 0x572 JUMPI PUSH1 0x24 CALLDATASIZE LT PUSH2 0x240a JUMPI PUSH1 0x4 CALLDATALOAD DUP1 PUSH1 0xa0 SHR PUSH2 0x240a JUMPI PUSH1 0x40 MSTORE PUSH13 0x50c783eb9b5c85f2a80000014 SLOAD CALLER XOR PUSH2 0x240a JUMPI PUSH1 0x40 MLOAD PUSH13 0x50c783eb9b5c85f2a80000012 SSTORE STOP JUMPDEST PUSH4 0x8e5b490f DUP2 XOR PUSH2 0x5b2 JUMPI PUSH13 0x50c783eb9b5c85f2a80000014 SLOAD CALLER XOR PUSH2 0x240a JUMPI PUSH13 0x50c783eb9b5c85f2a80000012 SLOAD PUSH13 0x50c783eb9b5c85f2a80000013 SSTORE STOP JUMPDEST PUSH4 0x7c74a174 DUP2 XOR PUSH2 0x630 JUMPI PUSH1 0x24 CALLDATASIZE LT PUSH2 0x240a JUMPI PUSH1 0x4 CALLDATALOAD DUP1 PUSH1 0xa0 SHR PUSH2 0x240a JUMPI PUSH1 0x40 MSTORE PUSH13 0x50c783eb9b5c85f2a80000006 PUSH1 0x40 MLOAD PUSH1 0x20 MSTORE PUSH0 MSTORE PUSH1 0x40 PUSH0 KECCAK SLOAD PUSH1 0x60 MSTORE PUSH13 0x50c783eb9b5c85f2a80000005 PUSH1 0x40 MLOAD PUSH1 0x20 MSTORE PUSH0 MSTORE PUSH1 0x40 PUSH0 KECCAK PUSH1 0x60 MLOAD PUSH4 0x3b9ac9ff DUP2 GT PUSH2 0x240a JUMPI PUSH1 0x2 SHL DUP2 ADD SWAP1 POP PUSH1 0x1 DUP2 ADD SWAP1 POP SLOAD PUSH1 0x80 MSTORE PUSH1 0x20 PUSH1 0x80 RETURN JUMPDEST PUSH4 0xda020a18 DUP2 XOR PUSH2 0x690 JUMPI PUSH1 0x44 CALLDATASIZE LT PUSH2 0x240a JUMPI PUSH1 0x4 CALLDATALOAD DUP1 PUSH1 0xa0 SHR PUSH2 0x240a JUMPI PUSH1 0x40 MSTORE PUSH13 0x50c783eb9b5c85f2a80000005 PUSH1 0x40 MLOAD PUSH1 0x20 MSTORE PUSH0 MSTORE PUSH1 0x40 PUSH0 KECCAK PUSH1 0x24 CALLDATALOAD PUSH4 0x3b9ac9ff DUP2 GT PUSH2 0x240a JUMPI PUSH1 0x2 SHL DUP2 ADD SWAP1 POP PUSH1 0x2 DUP2 ADD SWAP1 POP SLOAD PUSH1 0x60 MSTORE PUSH1 0x20 PUSH1 0x60 RETURN JUMPDEST PUSH4 0xadc63589 DUP2 XOR PUSH2 0x6cf JUMPI PUSH1 0x24 CALLDATASIZE LT PUSH2 0x240a JUMPI PUSH1 0x4 CALLDATALOAD DUP1 PUSH1 0xa0 SHR PUSH2 0x240a JUMPI PUSH1 0x40 MSTORE PUSH1 0x3 PUSH1 0x40 MLOAD PUSH1 0x20 MSTORE PUSH0 MSTORE PUSH1 0x40 PUSH0 KECCAK PUSH1 0x1 DUP2 ADD SWAP1 POP SLOAD PUSH1 0x60 MSTORE PUSH1 0x20 PUSH1 0x60 RETURN JUMPDEST PUSH4 0xc2c4c5c1 DUP2 XOR PUSH2 0x6ea JUMPI PUSH1 0xa0 CALLDATASIZE PUSH1 0x40 CALLDATACOPY PUSH2 0x6e8 PUSH2 0x1979 JUMP JUMPDEST STOP JUMPDEST PUSH4 0x3a46273e DUP2 XOR PUSH2 0x88b JUMPI PUSH1 0x44 CALLDATASIZE LT PUSH2 0x240a JUMPI PUSH1 0x4 CALLDATALOAD DUP1 PUSH1 0xa0 SHR PUSH2 0x240a JUMPI PUSH2 0x5e0 MSTORE PUSH0 SLOAD PUSH1 0x2 EQ PUSH2 0x240a JUMPI PUSH1 0x2 PUSH0 SSTORE PUSH1 0x3 PUSH2 0x5e0 MLOAD PUSH1 0x20 MSTORE PUSH0 MSTORE PUSH1 0x40 PUSH0 KECCAK DUP1 SLOAD PUSH2 0x600 MSTORE PUSH1 0x1 DUP2 ADD SLOAD PUSH2 0x620 MSTORE POP PUSH1 0x24 CALLDATALOAD ISZERO PUSH2 0x240a JUMPI PUSH1 0x1 PUSH2 0x600 MLOAD SLT ISZERO PUSH2 0x7b1 JUMPI PUSH1 0x16 PUSH2 0x640 MSTORE PUSH32 0x4e6f206578697374696e67206c6f636b20666f756e6400000000000000000000 PUSH2 0x660 MSTORE PUSH2 0x640 POP PUSH2 0x640 MLOAD DUP1 PUSH2 0x660 ADD PUSH1 0x1f DUP3 PUSH0 SUB AND CALLDATASIZE DUP3 CALLDATACOPY POP POP PUSH4 0x8c379a0 PUSH2 0x600 MSTORE PUSH1 0x20 PUSH2 0x620 MSTORE PUSH1 0x1f NOT PUSH1 0x1f PUSH2 0x640 MLOAD ADD AND PUSH1 0x44 ADD PUSH2 0x61c REVERT JUMPDEST TIMESTAMP PUSH2 0x620 MLOAD GT PUSH2 0x845 JUMPI PUSH1 0x24 PUSH2 0x640 MSTORE PUSH32 0x43616e6e6f742061646420746f2065787069726564206c6f636b2e2057697468 PUSH2 0x660 MSTORE PUSH32 0x6472617700000000000000000000000000000000000000000000000000000000 PUSH2 0x680 MSTORE PUSH2 0x640 POP PUSH2 0x640 MLOAD DUP1 PUSH2 0x660 ADD PUSH1 0x1f DUP3 PUSH0 SUB AND CALLDATASIZE DUP3 CALLDATACOPY POP POP PUSH4 0x8c379a0 PUSH2 0x600 MSTORE PUSH1 0x20 PUSH2 0x620 MSTORE PUSH1 0x1f NOT PUSH1 0x1f PUSH2 0x640 MLOAD ADD AND PUSH1 0x44 ADD PUSH2 0x61c REVERT JUMPDEST PUSH2 0x5e0 MLOAD PUSH2 0x3e0 MSTORE PUSH1 0x24 CALLDATALOAD PUSH2 0x400 MSTORE PUSH0 PUSH2 0x420 MSTORE PUSH1 0x3 PUSH2 0x5e0 MLOAD PUSH1 0x20 MSTORE PUSH0 MSTORE PUSH1 0x40 PUSH0 KECCAK DUP1 SLOAD PUSH2 0x440 MSTORE PUSH1 0x1 DUP2 ADD SLOAD PUSH2 0x460 MSTORE POP PUSH0 PUSH2 0x480 MSTORE PUSH2 0x885 PUSH2 0x203c JUMP JUMPDEST PUSH1 0x3 PUSH0 SSTORE STOP JUMPDEST PUSH4 0x65fc3873 DUP2 XOR PUSH2 0xab8 JUMPI PUSH1 0x44 CALLDATASIZE LT PUSH2 0x240a JUMPI PUSH0 SLOAD PUSH1 0x2 EQ PUSH2 0x240a JUMPI PUSH1 0x2 PUSH0 SSTORE CALLER PUSH1 0x40 MSTORE PUSH2 0x8b7 PUSH2 0x1886 JUMP JUMPDEST PUSH1 0x24 CALLDATALOAD PUSH3 0x93a80 DUP2 DIV SWAP1 POP PUSH3 0x93a80 DUP2 MUL DUP2 PUSH3 0x93a80 DUP3 DIV XOR PUSH2 0x240a JUMPI SWAP1 POP PUSH2 0x5e0 MSTORE PUSH1 0x3 CALLER PUSH1 0x20 MSTORE PUSH0 MSTORE PUSH1 0x40 PUSH0 KECCAK DUP1 SLOAD PUSH2 0x600 MSTORE PUSH1 0x1 DUP2 ADD SLOAD PUSH2 0x620 MSTORE POP PUSH1 0x4 CALLDATALOAD ISZERO PUSH2 0x240a JUMPI PUSH2 0x600 MLOAD ISZERO PUSH2 0x96c JUMPI PUSH1 0x19 PUSH2 0x640 MSTORE PUSH32 0x5769746864726177206f6c6420746f6b656e7320666972737400000000000000 PUSH2 0x660 MSTORE PUSH2 0x640 POP PUSH2 0x640 MLOAD DUP1 PUSH2 0x660 ADD PUSH1 0x1f DUP3 PUSH0 SUB AND CALLDATASIZE DUP3 CALLDATACOPY POP POP PUSH4 0x8c379a0 PUSH2 0x600 MSTORE PUSH1 0x20 PUSH2 0x620 MSTORE PUSH1 0x1f NOT PUSH1 0x1f PUSH2 0x640 MLOAD ADD AND PUSH1 0x44 ADD PUSH2 0x61c REVERT JUMPDEST TIMESTAMP PUSH2 0x5e0 MLOAD GT PUSH2 0xa00 JUMPI PUSH1 0x26 PUSH2 0x640 MSTORE PUSH32 0x43616e206f6e6c79206c6f636b20756e74696c2074696d6520696e2074686520 PUSH2 0x660 MSTORE PUSH32 0x6675747572650000000000000000000000000000000000000000000000000000 PUSH2 0x680 MSTORE PUSH2 0x640 POP PUSH2 0x640 MLOAD DUP1 PUSH2 0x660 ADD PUSH1 0x1f DUP3 PUSH0 SUB AND CALLDATASIZE DUP3 CALLDATACOPY POP POP PUSH4 0x8c379a0 PUSH2 0x600 MSTORE PUSH1 0x20 PUSH2 0x620 MSTORE PUSH1 0x1f NOT PUSH1 0x1f PUSH2 0x640 MLOAD ADD AND PUSH1 0x44 ADD PUSH2 0x61c REVERT JUMPDEST TIMESTAMP PUSH4 0x784ce00 DUP2 ADD DUP2 DUP2 LT PUSH2 0x240a JUMPI SWAP1 POP PUSH2 0x5e0 MLOAD GT ISZERO PUSH2 0xa80 JUMPI PUSH1 0x1e PUSH2 0x640 MSTORE PUSH32 0x566f74696e67206c6f636b2063616e2062652034207965617273206d61780000 PUSH2 0x660 MSTORE PUSH2 0x640 POP PUSH2 0x640 MLOAD DUP1 PUSH2 0x660 ADD PUSH1 0x1f DUP3 PUSH0 SUB AND CALLDATASIZE DUP3 CALLDATACOPY POP POP PUSH4 0x8c379a0 PUSH2 0x600 MSTORE PUSH1 0x20 PUSH2 0x620 MSTORE PUSH1 0x1f NOT PUSH1 0x1f PUSH2 0x640 MLOAD ADD AND PUSH1 0x44 ADD PUSH2 0x61c REVERT JUMPDEST CALLER PUSH2 0x3e0 MSTORE PUSH1 0x4 CALLDATALOAD PUSH2 0x400 MSTORE PUSH2 0x5e0 MLOAD PUSH2 0x420 MSTORE PUSH2 0x600 MLOAD PUSH2 0x440 MSTORE PUSH2 0x620 MLOAD PUSH2 0x460 MSTORE PUSH1 0x1 PUSH2 0x480 MSTORE PUSH2 0xab2 PUSH2 0x203c JUMP JUMPDEST PUSH1 0x3 PUSH0 SSTORE STOP JUMPDEST PUSH4 0x4957677c DUP2 XOR PUSH2 0xc42 JUMPI PUSH1 0x24 CALLDATASIZE LT PUSH2 0x240a JUMPI PUSH0 SLOAD PUSH1 0x2 EQ PUSH2 0x240a JUMPI PUSH1 0x2 PUSH0 SSTORE CALLER PUSH1 0x40 MSTORE PUSH2 0xae4 PUSH2 0x1886 JUMP JUMPDEST PUSH1 0x3 CALLER PUSH1 0x20 MSTORE PUSH0 MSTORE PUSH1 0x40 PUSH0 KECCAK DUP1 SLOAD PUSH2 0x5e0 MSTORE PUSH1 0x1 DUP2 ADD SLOAD PUSH2 0x600 MSTORE POP PUSH1 0x4 CALLDATALOAD ISZERO PUSH2 0x240a JUMPI PUSH1 0x1 PUSH2 0x5e0 MLOAD SLT ISZERO PUSH2 0xb79 JUMPI PUSH1 0x16 PUSH2 0x620 MSTORE PUSH32 0x4e6f206578697374696e67206c6f636b20666f756e6400000000000000000000 PUSH2 0x640 MSTORE PUSH2 0x620 POP PUSH2 0x620 MLOAD DUP1 PUSH2 0x640 ADD PUSH1 0x1f DUP3 PUSH0 SUB AND CALLDATASIZE DUP3 CALLDATACOPY POP POP PUSH4 0x8c379a0 PUSH2 0x5e0 MSTORE PUSH1 0x20 PUSH2 0x600 MSTORE PUSH1 0x1f NOT PUSH1 0x1f PUSH2 0x620 MLOAD ADD AND PUSH1 0x44 ADD PUSH2 0x5fc REVERT JUMPDEST TIMESTAMP PUSH2 0x600 MLOAD GT PUSH2 0xc0d JUMPI PUSH1 0x24 PUSH2 0x620 MSTORE PUSH32 0x43616e6e6f742061646420746f2065787069726564206c6f636b2e2057697468 PUSH2 0x640 MSTORE PUSH32 0x6472617700000000000000000000000000000000000000000000000000000000 PUSH2 0x660 MSTORE PUSH2 0x620 POP PUSH2 0x620 MLOAD DUP1 PUSH2 0x640 ADD PUSH1 0x1f DUP3 PUSH0 SUB AND CALLDATASIZE DUP3 CALLDATACOPY POP POP PUSH4 0x8c379a0 PUSH2 0x5e0 MSTORE PUSH1 0x20 PUSH2 0x600 MSTORE PUSH1 0x1f NOT PUSH1 0x1f PUSH2 0x620 MLOAD ADD AND PUSH1 0x44 ADD PUSH2 0x5fc REVERT JUMPDEST CALLER PUSH2 0x3e0 MSTORE PUSH1 0x4 CALLDATALOAD PUSH2 0x400 MSTORE PUSH0 PUSH2 0x420 MSTORE PUSH2 0x5e0 MLOAD PUSH2 0x440 MSTORE PUSH2 0x600 MLOAD PUSH2 0x460 MSTORE PUSH1 0x2 PUSH2 0x480 MSTORE PUSH2 0xc3c PUSH2 0x203c JUMP JUMPDEST PUSH1 0x3 PUSH0 SSTORE STOP JUMPDEST PUSH4 0xeff7a612 DUP2 XOR PUSH2 0xeb5 JUMPI PUSH1 0x24 CALLDATASIZE LT PUSH2 0x240a JUMPI PUSH0 SLOAD PUSH1 0x2 EQ PUSH2 0x240a JUMPI PUSH1 0x2 PUSH0 SSTORE CALLER PUSH1 0x40 MSTORE PUSH2 0xc6e PUSH2 0x1886 JUMP JUMPDEST PUSH1 0x3 CALLER PUSH1 0x20 MSTORE PUSH0 MSTORE PUSH1 0x40 PUSH0 KECCAK DUP1 SLOAD PUSH2 0x5e0 MSTORE PUSH1 0x1 DUP2 ADD SLOAD PUSH2 0x600 MSTORE POP PUSH1 0x4 CALLDATALOAD PUSH3 0x93a80 DUP2 DIV SWAP1 POP PUSH3 0x93a80 DUP2 MUL DUP2 PUSH3 0x93a80 DUP3 DIV XOR PUSH2 0x240a JUMPI SWAP1 POP PUSH2 0x620 MSTORE TIMESTAMP PUSH2 0x600 MLOAD GT PUSH2 0xd1c JUMPI PUSH1 0xc PUSH2 0x640 MSTORE PUSH32 0x4c6f636b20657870697265640000000000000000000000000000000000000000 PUSH2 0x660 MSTORE PUSH2 0x640 POP PUSH2 0x640 MLOAD DUP1 PUSH2 0x660 ADD PUSH1 0x1f DUP3 PUSH0 SUB AND CALLDATASIZE DUP3 CALLDATACOPY POP POP PUSH4 0x8c379a0 PUSH2 0x600 MSTORE PUSH1 0x20 PUSH2 0x620 MSTORE PUSH1 0x1f NOT PUSH1 0x1f PUSH2 0x640 MLOAD ADD AND PUSH1 0x44 ADD PUSH2 0x61c REVERT JUMPDEST PUSH1 0x1 PUSH2 0x5e0 MLOAD SLT ISZERO PUSH2 0xd8d JUMPI PUSH1 0x11 PUSH2 0x640 MSTORE PUSH32 0x4e6f7468696e67206973206c6f636b6564000000000000000000000000000000 PUSH2 0x660 MSTORE PUSH2 0x640 POP PUSH2 0x640 MLOAD DUP1 PUSH2 0x660 ADD PUSH1 0x1f DUP3 PUSH0 SUB AND CALLDATASIZE DUP3 CALLDATACOPY POP POP PUSH4 0x8c379a0 PUSH2 0x600 MSTORE PUSH1 0x20 PUSH2 0x620 MSTORE PUSH1 0x1f NOT PUSH1 0x1f PUSH2 0x640 MLOAD ADD AND PUSH1 0x44 ADD PUSH2 0x61c REVERT JUMPDEST PUSH2 0x600 MLOAD PUSH2 0x620 MLOAD GT PUSH2 0xdff JUMPI PUSH1 0x1f PUSH2 0x640 MSTORE PUSH32 0x43616e206f6e6c7920696e637265617365206c6f636b206475726174696f6e00 PUSH2 0x660 MSTORE PUSH2 0x640 POP PUSH2 0x640 MLOAD DUP1 PUSH2 0x660 ADD PUSH1 0x1f DUP3 PUSH0 SUB AND CALLDATASIZE DUP3 CALLDATACOPY POP POP PUSH4 0x8c379a0 PUSH2 0x600 MSTORE PUSH1 0x20 PUSH2 0x620 MSTORE PUSH1 0x1f NOT PUSH1 0x1f PUSH2 0x640 MLOAD ADD AND PUSH1 0x44 ADD PUSH2 0x61c REVERT JUMPDEST TIMESTAMP PUSH4 0x784ce00 DUP2 ADD DUP2 DUP2 LT PUSH2 0x240a JUMPI SWAP1 POP PUSH2 0x620 MLOAD GT ISZERO PUSH2 0xe7f JUMPI PUSH1 0x1e PUSH2 0x640 MSTORE PUSH32 0x566f74696e67206c6f636b2063616e2062652034207965617273206d61780000 PUSH2 0x660 MSTORE PUSH2 0x640 POP PUSH2 0x640 MLOAD DUP1 PUSH2 0x660 ADD PUSH1 0x1f DUP3 PUSH0 SUB AND CALLDATASIZE DUP3 CALLDATACOPY POP POP PUSH4 0x8c379a0 PUSH2 0x600 MSTORE PUSH1 0x20 PUSH2 0x620 MSTORE PUSH1 0x1f NOT PUSH1 0x1f PUSH2 0x640 MLOAD ADD AND PUSH1 0x44 ADD PUSH2 0x61c REVERT JUMPDEST CALLER PUSH2 0x3e0 MSTORE PUSH0 PUSH2 0x400 MSTORE PUSH2 0x620 MLOAD PUSH2 0x420 MSTORE PUSH2 0x5e0 MLOAD PUSH2 0x440 MSTORE PUSH2 0x600 MLOAD PUSH2 0x460 MSTORE PUSH1 0x3 PUSH2 0x480 MSTORE PUSH2 0xeaf PUSH2 0x203c JUMP JUMPDEST PUSH1 0x3 PUSH0 SSTORE STOP JUMPDEST PUSH4 0x3ccfd60b DUP2 XOR PUSH2 0x10c0 JUMPI PUSH0 SLOAD PUSH1 0x2 EQ PUSH2 0x240a JUMPI PUSH1 0x2 PUSH0 SSTORE PUSH1 0x3 CALLER PUSH1 0x20 MSTORE PUSH0 MSTORE PUSH1 0x40 PUSH0 KECCAK DUP1 SLOAD PUSH2 0x3e0 MSTORE PUSH1 0x1 DUP2 ADD SLOAD PUSH2 0x400 MSTORE POP PUSH2 0x400 MLOAD TIMESTAMP LT ISZERO PUSH2 0xf59 JUMPI PUSH1 0x16 PUSH2 0x420 MSTORE PUSH32 0x546865206c6f636b206469646e27742065787069726500000000000000000000 PUSH2 0x440 MSTORE PUSH2 0x420 POP PUSH2 0x420 MLOAD DUP1 PUSH2 0x440 ADD PUSH1 0x1f DUP3 PUSH0 SUB AND CALLDATASIZE DUP3 CALLDATACOPY POP POP PUSH4 0x8c379a0 PUSH2 0x3e0 MSTORE PUSH1 0x20 PUSH2 0x400 MSTORE PUSH1 0x1f NOT PUSH1 0x1f PUSH2 0x420 MLOAD ADD AND PUSH1 0x44 ADD PUSH2 0x3fc REVERT JUMPDEST PUSH2 0x3e0 MLOAD PUSH0 DUP2 SLT PUSH2 0x240a JUMPI PUSH2 0x420 MSTORE PUSH2 0x3e0 MLOAD PUSH2 0x440 MSTORE PUSH2 0x400 MLOAD PUSH2 0x460 MSTORE PUSH0 PUSH2 0x400 MSTORE PUSH0 PUSH2 0x3e0 MSTORE PUSH1 0x3 CALLER PUSH1 0x20 MSTORE PUSH0 MSTORE PUSH1 0x40 PUSH0 KECCAK PUSH2 0x3e0 MLOAD DUP2 SSTORE PUSH2 0x400 MLOAD PUSH1 0x1 DUP3 ADD SSTORE POP PUSH1 0x2 SLOAD PUSH2 0x480 MSTORE PUSH2 0x480 MLOAD PUSH2 0x420 MLOAD DUP1 DUP3 SUB DUP3 DUP2 GT PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP PUSH1 0x2 SSTORE CALLER PUSH1 0x40 MSTORE PUSH2 0x440 MLOAD PUSH1 0x60 MSTORE PUSH2 0x460 MLOAD PUSH1 0x80 MSTORE PUSH2 0x3e0 MLOAD PUSH1 0xa0 MSTORE PUSH2 0x400 MLOAD PUSH1 0xc0 MSTORE PUSH2 0xfe6 PUSH2 0x1979 JUMP JUMPDEST PUSH1 0x1 SLOAD PUSH4 0xa9059cbb PUSH2 0x4a0 MSTORE CALLER PUSH2 0x4c0 MSTORE PUSH2 0x420 MLOAD PUSH2 0x4e0 MSTORE PUSH1 0x20 PUSH2 0x4a0 PUSH1 0x44 PUSH2 0x4bc PUSH0 DUP6 GAS CALL PUSH2 0x1019 JUMPI RETURNDATASIZE PUSH0 PUSH0 RETURNDATACOPY RETURNDATASIZE PUSH0 REVERT JUMPDEST PUSH1 0x20 RETURNDATASIZE LT PUSH2 0x240a JUMPI PUSH2 0x4a0 MLOAD DUP1 PUSH1 0x1 SHR PUSH2 0x240a JUMPI PUSH2 0x500 MSTORE PUSH2 0x500 SWAP1 POP MLOAD ISZERO PUSH2 0x240a JUMPI CALLER PUSH32 0xf279e6a1f5e320cca91135676d9cb6e44ca8a08c0b88342bcdb1144f6511b568 PUSH2 0x420 MLOAD PUSH2 0x4a0 MSTORE TIMESTAMP PUSH2 0x4c0 MSTORE PUSH1 0x40 PUSH2 0x4a0 LOG2 PUSH32 0x5e2aa66efd74cce82b21852e317e5490d9ecc9e6bb953ae24d90851258cc2f5c PUSH2 0x480 MLOAD PUSH2 0x4a0 MSTORE PUSH2 0x480 MLOAD PUSH2 0x420 MLOAD DUP1 DUP3 SUB DUP3 DUP2 GT PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP PUSH2 0x4c0 MSTORE PUSH1 0x40 PUSH2 0x4a0 LOG1 PUSH1 0x3 PUSH0 SSTORE STOP JUMPDEST PUSH4 0x70a08231 DUP2 XOR PUSH2 0x10dc JUMPI PUSH1 0x24 CALLDATASIZE LT PUSH2 0x240a JUMPI TIMESTAMP PUSH1 0x60 MSTORE PUSH2 0x10f5 JUMP JUMPDEST PUSH3 0xfdd58e DUP2 XOR PUSH2 0x120e JUMPI PUSH1 0x44 CALLDATASIZE LT PUSH2 0x240a JUMPI PUSH1 0x24 CALLDATALOAD PUSH1 0x60 MSTORE JUMPDEST PUSH1 0x4 CALLDATALOAD DUP1 PUSH1 0xa0 SHR PUSH2 0x240a JUMPI PUSH1 0x40 MSTORE PUSH13 0x50c783eb9b5c85f2a80000006 PUSH1 0x40 MLOAD PUSH1 0x20 MSTORE PUSH0 MSTORE PUSH1 0x40 PUSH0 KECCAK SLOAD PUSH1 0x80 MSTORE PUSH1 0x80 MLOAD PUSH2 0x1135 JUMPI PUSH0 PUSH1 0xa0 MSTORE PUSH1 0x20 PUSH1 0xa0 PUSH2 0x120c JUMP JUMPDEST PUSH13 0x50c783eb9b5c85f2a80000005 PUSH1 0x40 MLOAD PUSH1 0x20 MSTORE PUSH0 MSTORE PUSH1 0x40 PUSH0 KECCAK PUSH1 0x80 MLOAD PUSH4 0x3b9ac9ff DUP2 GT PUSH2 0x240a JUMPI PUSH1 0x2 SHL DUP2 ADD SWAP1 POP DUP1 SLOAD PUSH1 0xa0 MSTORE PUSH1 0x1 DUP2 ADD SLOAD PUSH1 0xc0 MSTORE PUSH1 0x2 DUP2 ADD SLOAD PUSH1 0xe0 MSTORE PUSH1 0x3 DUP2 ADD SLOAD PUSH2 0x100 MSTORE POP PUSH1 0xa0 MLOAD PUSH1 0xc0 MLOAD PUSH1 0x60 MLOAD PUSH1 0xe0 MLOAD DUP1 DUP3 SUB DUP3 DUP2 GT PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP DUP1 PUSH1 0x7f SHR PUSH2 0x240a JUMPI DUP1 DUP3 MUL DUP1 PUSH1 0xf SIGNEXTEND DUP2 XOR PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP DUP1 DUP3 SUB DUP1 PUSH1 0xf SIGNEXTEND DUP2 XOR PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP PUSH1 0xa0 MSTORE PUSH32 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff PUSH1 0xa0 MLOAD SGT PUSH2 0x11f8 JUMPI PUSH0 PUSH1 0xa0 MSTORE JUMPDEST PUSH1 0xa0 MLOAD PUSH0 DUP2 SLT PUSH2 0x240a JUMPI PUSH2 0x120 MSTORE PUSH1 0x20 PUSH2 0x120 JUMPDEST RETURN JUMPDEST PUSH4 0x4ee2cd7e DUP2 XOR PUSH2 0x157e JUMPI PUSH1 0x44 CALLDATASIZE LT PUSH2 0x240a JUMPI PUSH1 0x4 CALLDATALOAD DUP1 PUSH1 0xa0 SHR PUSH2 0x240a JUMPI PUSH2 0x100 MSTORE NUMBER PUSH1 0x24 CALLDATALOAD GT PUSH2 0x240a JUMPI PUSH0 PUSH2 0x120 MSTORE PUSH13 0x50c783eb9b5c85f2a80000006 PUSH2 0x100 MLOAD PUSH1 0x20 MSTORE PUSH0 MSTORE PUSH1 0x40 PUSH0 KECCAK SLOAD PUSH2 0x140 MSTORE PUSH0 PUSH1 0x80 SWAP1 JUMPDEST DUP1 PUSH2 0x160 MSTORE PUSH2 0x140 MLOAD PUSH2 0x120 MLOAD LT PUSH2 0x127a JUMPI PUSH2 0x1316 JUMP JUMPDEST PUSH2 0x120 MLOAD PUSH2 0x140 MLOAD DUP1 DUP3 ADD DUP3 DUP2 LT PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP PUSH1 0x1 DUP2 ADD DUP2 DUP2 LT PUSH2 0x240a JUMPI SWAP1 POP DUP1 PUSH1 0x1 SHR SWAP1 POP PUSH2 0x180 MSTORE PUSH1 0x24 CALLDATALOAD PUSH13 0x50c783eb9b5c85f2a80000005 PUSH2 0x100 MLOAD PUSH1 0x20 MSTORE PUSH0 MSTORE PUSH1 0x40 PUSH0 KECCAK PUSH2 0x180 MLOAD PUSH4 0x3b9ac9ff DUP2 GT PUSH2 0x240a JUMPI PUSH1 0x2 SHL DUP2 ADD SWAP1 POP PUSH1 0x3 DUP2 ADD SWAP1 POP SLOAD GT ISZERO PUSH2 0x1302 JUMPI PUSH2 0x180 MLOAD PUSH1 0x1 DUP2 SUB DUP2 DUP2 GT PUSH2 0x240a JUMPI SWAP1 POP PUSH2 0x140 MSTORE PUSH2 0x130b JUMP JUMPDEST PUSH2 0x180 MLOAD PUSH2 0x120 MSTORE JUMPDEST PUSH1 0x1 ADD DUP2 DUP2 XOR PUSH2 0x1263 JUMPI JUMPDEST POP POP PUSH13 0x50c783eb9b5c85f2a80000005 PUSH2 0x100 MLOAD PUSH1 0x20 MSTORE PUSH0 MSTORE PUSH1 0x40 PUSH0 KECCAK PUSH2 0x120 MLOAD PUSH4 0x3b9ac9ff DUP2 GT PUSH2 0x240a JUMPI PUSH1 0x2 SHL DUP2 ADD SWAP1 POP DUP1 SLOAD PUSH2 0x160 MSTORE PUSH1 0x1 DUP2 ADD SLOAD PUSH2 0x180 MSTORE PUSH1 0x2 DUP2 ADD SLOAD PUSH2 0x1a0 MSTORE PUSH1 0x3 DUP2 ADD SLOAD PUSH2 0x1c0 MSTORE POP PUSH1 0x4 SLOAD PUSH2 0x1e0 MSTORE PUSH1 0x24 CALLDATALOAD PUSH1 0x40 MSTORE PUSH2 0x1e0 MLOAD PUSH1 0x60 MSTORE PUSH2 0x138a PUSH2 0x220 PUSH2 0x21f4 JUMP JUMPDEST PUSH2 0x220 MLOAD PUSH2 0x200 MSTORE PUSH2 0x200 MLOAD PUSH13 0x1431e0fae6d7217ca9fffffff DUP2 GT PUSH2 0x240a JUMPI PUSH1 0x2 SHL PUSH1 0x5 ADD DUP1 SLOAD PUSH2 0x220 MSTORE PUSH1 0x1 DUP2 ADD SLOAD PUSH2 0x240 MSTORE PUSH1 0x2 DUP2 ADD SLOAD PUSH2 0x260 MSTORE PUSH1 0x3 DUP2 ADD SLOAD PUSH2 0x280 MSTORE POP PUSH1 0x40 CALLDATASIZE PUSH2 0x2a0 CALLDATACOPY PUSH2 0x1e0 MLOAD PUSH2 0x200 MLOAD LT PUSH2 0x1419 JUMPI NUMBER PUSH2 0x280 MLOAD DUP1 DUP3 SUB DUP3 DUP2 GT PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP PUSH2 0x2a0 MSTORE TIMESTAMP PUSH2 0x260 MLOAD DUP1 DUP3 SUB DUP3 DUP2 GT PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP PUSH2 0x2c0 MSTORE PUSH2 0x149b JUMP JUMPDEST PUSH2 0x200 MLOAD PUSH1 0x1 DUP2 ADD DUP2 DUP2 LT PUSH2 0x240a JUMPI SWAP1 POP PUSH13 0x1431e0fae6d7217ca9fffffff DUP2 GT PUSH2 0x240a JUMPI PUSH1 0x2 SHL PUSH1 0x5 ADD DUP1 SLOAD PUSH2 0x2e0 MSTORE PUSH1 0x1 DUP2 ADD SLOAD PUSH2 0x300 MSTORE PUSH1 0x2 DUP2 ADD SLOAD PUSH2 0x320 MSTORE PUSH1 0x3 DUP2 ADD SLOAD PUSH2 0x340 MSTORE POP PUSH2 0x340 MLOAD PUSH2 0x280 MLOAD DUP1 DUP3 SUB DUP3 DUP2 GT PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP PUSH2 0x2a0 MSTORE PUSH2 0x320 MLOAD PUSH2 0x260 MLOAD DUP1 DUP3 SUB DUP3 DUP2 GT PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP PUSH2 0x2c0 MSTORE JUMPDEST PUSH2 0x260 MLOAD PUSH2 0x2e0 MSTORE PUSH2 0x2a0 MLOAD ISZERO PUSH2 0x1501 JUMPI PUSH2 0x2e0 MLOAD PUSH2 0x2c0 MLOAD PUSH1 0x24 CALLDATALOAD PUSH2 0x280 MLOAD DUP1 DUP3 SUB DUP3 DUP2 GT PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP DUP1 DUP3 MUL DUP2 ISZERO DUP4 DUP4 DUP4 DIV EQ OR ISZERO PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP PUSH2 0x2a0 MLOAD DUP1 ISZERO PUSH2 0x240a JUMPI DUP1 DUP3 DIV SWAP1 POP SWAP1 POP DUP1 DUP3 ADD DUP3 DUP2 LT PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP PUSH2 0x2e0 MSTORE JUMPDEST PUSH2 0x160 MLOAD PUSH2 0x180 MLOAD PUSH2 0x2e0 MLOAD PUSH2 0x1a0 MLOAD DUP1 DUP3 SUB DUP3 DUP2 GT PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP DUP1 PUSH1 0x7f SHR PUSH2 0x240a JUMPI DUP1 DUP3 MUL DUP1 PUSH1 0xf SIGNEXTEND DUP2 XOR PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP DUP1 DUP3 SUB DUP1 PUSH1 0xf SIGNEXTEND DUP2 XOR PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP PUSH2 0x160 MSTORE PUSH0 PUSH2 0x160 MLOAD SLT ISZERO PUSH2 0x1567 JUMPI PUSH0 PUSH2 0x300 MSTORE PUSH1 0x20 PUSH2 0x300 PUSH2 0x157c JUMP JUMPDEST PUSH2 0x160 MLOAD PUSH0 DUP2 SLT PUSH2 0x240a JUMPI PUSH2 0x300 MSTORE PUSH1 0x20 PUSH2 0x300 JUMPDEST RETURN JUMPDEST PUSH4 0x18160ddd DUP2 XOR PUSH2 0x1593 JUMPI TIMESTAMP PUSH2 0x1c0 MSTORE PUSH2 0x15ae JUMP JUMPDEST PUSH4 0xbd85b039 DUP2 XOR PUSH2 0x162a JUMPI PUSH1 0x24 CALLDATASIZE LT PUSH2 0x240a JUMPI PUSH1 0x4 CALLDATALOAD PUSH2 0x1c0 MSTORE JUMPDEST PUSH1 0x4 SLOAD PUSH2 0x1e0 MSTORE PUSH2 0x1e0 MLOAD PUSH13 0x1431e0fae6d7217ca9fffffff DUP2 GT PUSH2 0x240a JUMPI PUSH1 0x2 SHL PUSH1 0x5 ADD DUP1 SLOAD PUSH2 0x200 MSTORE PUSH1 0x1 DUP2 ADD SLOAD PUSH2 0x220 MSTORE PUSH1 0x2 DUP2 ADD SLOAD PUSH2 0x240 MSTORE PUSH1 0x3 DUP2 ADD SLOAD PUSH2 0x260 MSTORE POP PUSH1 0x20 PUSH2 0x200 MLOAD PUSH1 0x40 MSTORE PUSH2 0x220 MLOAD PUSH1 0x60 MSTORE PUSH2 0x240 MLOAD PUSH1 0x80 MSTORE PUSH2 0x260 MLOAD PUSH1 0xa0 MSTORE PUSH2 0x1c0 MLOAD PUSH1 0xc0 MSTORE PUSH2 0x1625 PUSH2 0x280 PUSH2 0x22a2 JUMP JUMPDEST PUSH2 0x280 RETURN JUMPDEST PUSH4 0x981b24d0 DUP2 XOR PUSH2 0x1836 JUMPI PUSH1 0x24 CALLDATASIZE LT PUSH2 0x240a JUMPI NUMBER PUSH1 0x4 CALLDATALOAD GT PUSH2 0x240a JUMPI PUSH1 0x4 SLOAD PUSH2 0x1c0 MSTORE PUSH1 0x4 CALLDATALOAD PUSH1 0x40 MSTORE PUSH2 0x1c0 MLOAD PUSH1 0x60 MSTORE PUSH2 0x1665 PUSH2 0x200 PUSH2 0x21f4 JUMP JUMPDEST PUSH2 0x200 MLOAD PUSH2 0x1e0 MSTORE PUSH2 0x1e0 MLOAD PUSH13 0x1431e0fae6d7217ca9fffffff DUP2 GT PUSH2 0x240a JUMPI PUSH1 0x2 SHL PUSH1 0x5 ADD DUP1 SLOAD PUSH2 0x200 MSTORE PUSH1 0x1 DUP2 ADD SLOAD PUSH2 0x220 MSTORE PUSH1 0x2 DUP2 ADD SLOAD PUSH2 0x240 MSTORE PUSH1 0x3 DUP2 ADD SLOAD PUSH2 0x260 MSTORE POP PUSH0 PUSH2 0x280 MSTORE PUSH2 0x1c0 MLOAD PUSH2 0x1e0 MLOAD LT PUSH2 0x172e JUMPI NUMBER PUSH2 0x260 MLOAD EQ PUSH2 0x17ef JUMPI PUSH1 0x4 CALLDATALOAD PUSH2 0x260 MLOAD DUP1 DUP3 SUB DUP3 DUP2 GT PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP TIMESTAMP PUSH2 0x240 MLOAD DUP1 DUP3 SUB DUP3 DUP2 GT PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP DUP1 DUP3 MUL DUP2 ISZERO DUP4 DUP4 DUP4 DIV EQ OR ISZERO PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP NUMBER PUSH2 0x260 MLOAD DUP1 DUP3 SUB DUP3 DUP2 GT PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP DUP1 ISZERO PUSH2 0x240a JUMPI DUP1 DUP3 DIV SWAP1 POP SWAP1 POP PUSH2 0x280 MSTORE PUSH2 0x17ef JUMP JUMPDEST PUSH2 0x1e0 MLOAD PUSH1 0x1 DUP2 ADD DUP2 DUP2 LT PUSH2 0x240a JUMPI SWAP1 POP PUSH13 0x1431e0fae6d7217ca9fffffff DUP2 GT PUSH2 0x240a JUMPI PUSH1 0x2 SHL PUSH1 0x5 ADD DUP1 SLOAD PUSH2 0x2a0 MSTORE PUSH1 0x1 DUP2 ADD SLOAD PUSH2 0x2c0 MSTORE PUSH1 0x2 DUP2 ADD SLOAD PUSH2 0x2e0 MSTORE PUSH1 0x3 DUP2 ADD SLOAD PUSH2 0x300 MSTORE POP PUSH2 0x300 MLOAD PUSH2 0x260 MLOAD EQ PUSH2 0x17ef JUMPI PUSH1 0x4 CALLDATALOAD PUSH2 0x260 MLOAD DUP1 DUP3 SUB DUP3 DUP2 GT PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP PUSH2 0x2e0 MLOAD PUSH2 0x240 MLOAD DUP1 DUP3 SUB DUP3 DUP2 GT PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP DUP1 DUP3 MUL DUP2 ISZERO DUP4 DUP4 DUP4 DIV EQ OR ISZERO PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP PUSH2 0x300 MLOAD PUSH2 0x260 MLOAD DUP1 DUP3 SUB DUP3 DUP2 GT PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP DUP1 ISZERO PUSH2 0x240a JUMPI DUP1 DUP3 DIV SWAP1 POP SWAP1 POP PUSH2 0x280 MSTORE JUMPDEST PUSH1 0x20 PUSH2 0x200 MLOAD PUSH1 0x40 MSTORE PUSH2 0x220 MLOAD PUSH1 0x60 MSTORE PUSH2 0x240 MLOAD PUSH1 0x80 MSTORE PUSH2 0x260 MLOAD PUSH1 0xa0 MSTORE PUSH2 0x240 MLOAD PUSH2 0x280 MLOAD DUP1 DUP3 ADD DUP3 DUP2 LT PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP PUSH1 0xc0 MSTORE PUSH2 0x1831 PUSH2 0x2a0 PUSH2 0x22a2 JUMP JUMPDEST PUSH2 0x2a0 RETURN JUMPDEST PUSH4 0x3cebb823 DUP2 XOR PUSH2 0x1880 JUMPI PUSH1 0x24 CALLDATASIZE LT PUSH2 0x240a JUMPI PUSH1 0x4 CALLDATALOAD DUP1 PUSH1 0xa0 SHR PUSH2 0x240a JUMPI PUSH1 0x40 MSTORE PUSH13 0x50c783eb9b5c85f2a80000008 SLOAD CALLER XOR PUSH2 0x240a JUMPI PUSH1 0x40 MLOAD PUSH13 0x50c783eb9b5c85f2a80000008 SSTORE STOP JUMPDEST POP JUMPDEST PUSH0 PUSH0 REVERT JUMPDEST ORIGIN PUSH1 0x40 MLOAD EQ PUSH2 0x1977 JUMPI PUSH13 0x50c783eb9b5c85f2a80000013 SLOAD PUSH1 0x60 MSTORE PUSH1 0x60 MLOAD ISZERO PUSH2 0x18f7 JUMPI PUSH1 0x60 MLOAD PUSH4 0xc23697a8 PUSH1 0x80 MSTORE PUSH1 0x40 MLOAD PUSH1 0xa0 MSTORE PUSH1 0x20 PUSH1 0x80 PUSH1 0x24 PUSH1 0x9c PUSH0 DUP6 GAS CALL PUSH2 0x18d2 JUMPI RETURNDATASIZE PUSH0 PUSH0 RETURNDATACOPY RETURNDATASIZE PUSH0 REVERT JUMPDEST PUSH1 0x20 RETURNDATASIZE LT PUSH2 0x240a JUMPI PUSH1 0x80 MLOAD DUP1 PUSH1 0x1 SHR PUSH2 0x240a JUMPI PUSH1 0xc0 MSTORE PUSH1 0xc0 SWAP1 POP MLOAD ISZERO PUSH2 0x18f7 JUMPI PUSH2 0x1977 JUMP JUMPDEST PUSH1 0x25 PUSH1 0x80 MSTORE PUSH32 0x536d61727420636f6e7472616374206465706f7369746f7273206e6f7420616c PUSH1 0xa0 MSTORE PUSH32 0x6c6f776564000000000000000000000000000000000000000000000000000000 PUSH1 0xc0 MSTORE PUSH1 0x80 POP PUSH1 0x80 MLOAD DUP1 PUSH1 0xa0 ADD PUSH1 0x1f DUP3 PUSH0 SUB AND CALLDATASIZE DUP3 CALLDATACOPY POP POP PUSH4 0x8c379a0 PUSH1 0x40 MSTORE PUSH1 0x20 PUSH1 0x60 MSTORE PUSH1 0x1f NOT PUSH1 0x1f PUSH1 0x80 MLOAD ADD AND PUSH1 0x44 ADD PUSH1 0x5c REVERT JUMPDEST JUMP JUMPDEST PUSH2 0x140 CALLDATASIZE PUSH1 0xe0 CALLDATACOPY PUSH1 0x4 SLOAD PUSH2 0x220 MSTORE PUSH1 0x40 MLOAD ISZERO PUSH2 0x1aad JUMPI TIMESTAMP PUSH1 0x80 MLOAD GT PUSH2 0x199e JUMPI PUSH0 PUSH2 0x19a6 JUMP JUMPDEST PUSH1 0x1 PUSH1 0x60 MLOAD SLT ISZERO JUMPDEST ISZERO PUSH2 0x19ee JUMPI PUSH1 0x60 MLOAD PUSH4 0x784ce00 DUP2 SDIV SWAP1 POP PUSH2 0x100 MSTORE PUSH2 0x100 MLOAD PUSH1 0x80 MLOAD TIMESTAMP DUP1 DUP3 SUB DUP3 DUP2 GT PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP DUP1 PUSH1 0x7f SHR PUSH2 0x240a JUMPI DUP1 DUP3 MUL DUP1 PUSH1 0xf SIGNEXTEND DUP2 XOR PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP PUSH1 0xe0 MSTORE JUMPDEST TIMESTAMP PUSH1 0xc0 MLOAD GT PUSH2 0x19fd JUMPI PUSH0 PUSH2 0x1a05 JUMP JUMPDEST PUSH1 0x1 PUSH1 0xa0 MLOAD SLT ISZERO JUMPDEST ISZERO PUSH2 0x1a4e JUMPI PUSH1 0xa0 MLOAD PUSH4 0x784ce00 DUP2 SDIV SWAP1 POP PUSH2 0x180 MSTORE PUSH2 0x180 MLOAD PUSH1 0xc0 MLOAD TIMESTAMP DUP1 DUP3 SUB DUP3 DUP2 GT PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP DUP1 PUSH1 0x7f SHR PUSH2 0x240a JUMPI DUP1 DUP3 MUL DUP1 PUSH1 0xf SIGNEXTEND DUP2 XOR PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP PUSH2 0x160 MSTORE JUMPDEST PUSH13 0x50c783eb9b5c85f2a80000007 PUSH1 0x80 MLOAD PUSH1 0x20 MSTORE PUSH0 MSTORE PUSH1 0x40 PUSH0 KECCAK SLOAD PUSH2 0x1e0 MSTORE PUSH1 0xc0 MLOAD ISZERO PUSH2 0x1aad JUMPI PUSH1 0x80 MLOAD PUSH1 0xc0 MLOAD XOR PUSH2 0x1a8d JUMPI PUSH2 0x1e0 MLOAD PUSH2 0x200 MSTORE PUSH2 0x1aad JUMP JUMPDEST PUSH13 0x50c783eb9b5c85f2a80000007 PUSH1 0xc0 MLOAD PUSH1 0x20 MSTORE PUSH0 MSTORE PUSH1 0x40 PUSH0 KECCAK SLOAD PUSH2 0x200 MSTORE JUMPDEST PUSH1 0x40 CALLDATASIZE PUSH2 0x240 CALLDATACOPY TIMESTAMP PUSH2 0x280 MSTORE NUMBER PUSH2 0x2a0 MSTORE PUSH2 0x220 MLOAD ISZERO PUSH2 0x1b08 JUMPI PUSH2 0x220 MLOAD PUSH13 0x1431e0fae6d7217ca9fffffff DUP2 GT PUSH2 0x240a JUMPI PUSH1 0x2 SHL PUSH1 0x5 ADD DUP1 SLOAD PUSH2 0x240 MSTORE PUSH1 0x1 DUP2 ADD SLOAD PUSH2 0x260 MSTORE PUSH1 0x2 DUP2 ADD SLOAD PUSH2 0x280 MSTORE PUSH1 0x3 DUP2 ADD SLOAD PUSH2 0x2a0 MSTORE POP JUMPDEST PUSH2 0x280 MLOAD PUSH2 0x2c0 MSTORE PUSH2 0x240 MLOAD PUSH2 0x2e0 MSTORE PUSH2 0x260 MLOAD PUSH2 0x300 MSTORE PUSH2 0x280 MLOAD PUSH2 0x320 MSTORE PUSH2 0x2a0 MLOAD PUSH2 0x340 MSTORE PUSH0 PUSH2 0x360 MSTORE PUSH2 0x280 MLOAD TIMESTAMP GT ISZERO PUSH2 0x1b96 JUMPI NUMBER PUSH2 0x2a0 MLOAD DUP1 DUP3 SUB DUP3 DUP2 GT PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP PUSH8 0xde0b6b3a7640000 DUP2 MUL DUP2 PUSH8 0xde0b6b3a7640000 DUP3 DIV XOR PUSH2 0x240a JUMPI SWAP1 POP TIMESTAMP PUSH2 0x280 MLOAD DUP1 DUP3 SUB DUP3 DUP2 GT PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP DUP1 ISZERO PUSH2 0x240a JUMPI DUP1 DUP3 DIV SWAP1 POP SWAP1 POP PUSH2 0x360 MSTORE JUMPDEST PUSH2 0x2c0 MLOAD PUSH3 0x93a80 DUP2 DIV SWAP1 POP PUSH3 0x93a80 DUP2 MUL DUP2 PUSH3 0x93a80 DUP3 DIV XOR PUSH2 0x240a JUMPI SWAP1 POP PUSH2 0x380 MSTORE PUSH0 PUSH1 0xff SWAP1 JUMPDEST DUP1 PUSH2 0x3a0 MSTORE PUSH2 0x380 MLOAD PUSH3 0x93a80 DUP2 ADD DUP2 DUP2 LT PUSH2 0x240a JUMPI SWAP1 POP PUSH2 0x380 MSTORE PUSH0 PUSH2 0x3c0 MSTORE TIMESTAMP PUSH2 0x380 MLOAD GT PUSH2 0x1c0f JUMPI PUSH13 0x50c783eb9b5c85f2a80000007 PUSH2 0x380 MLOAD PUSH1 0x20 MSTORE PUSH0 MSTORE PUSH1 0x40 PUSH0 KECCAK SLOAD PUSH2 0x3c0 MSTORE PUSH2 0x1c15 JUMP JUMPDEST TIMESTAMP PUSH2 0x380 MSTORE JUMPDEST PUSH2 0x240 MLOAD PUSH2 0x260 MLOAD PUSH2 0x380 MLOAD PUSH2 0x2c0 MLOAD DUP1 DUP3 SUB DUP3 DUP2 GT PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP DUP1 PUSH1 0x7f SHR PUSH2 0x240a JUMPI DUP1 DUP3 MUL DUP1 PUSH1 0xf SIGNEXTEND DUP2 XOR PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP DUP1 DUP3 SUB DUP1 PUSH1 0xf SIGNEXTEND DUP2 XOR PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP PUSH2 0x240 MSTORE PUSH2 0x260 MLOAD PUSH2 0x3c0 MLOAD DUP1 DUP3 ADD DUP1 PUSH1 0xf SIGNEXTEND DUP2 XOR PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP PUSH2 0x260 MSTORE PUSH32 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff PUSH2 0x240 MLOAD SGT PUSH2 0x1cae JUMPI PUSH0 PUSH2 0x240 MSTORE JUMPDEST PUSH32 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff PUSH2 0x260 MLOAD SGT PUSH2 0x1cde JUMPI PUSH0 PUSH2 0x260 MSTORE JUMPDEST PUSH2 0x380 MLOAD PUSH2 0x2c0 MSTORE PUSH2 0x380 MLOAD PUSH2 0x280 MSTORE PUSH2 0x340 MLOAD PUSH2 0x360 MLOAD PUSH2 0x380 MLOAD PUSH2 0x320 MLOAD DUP1 DUP3 SUB DUP3 DUP2 GT PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP DUP1 DUP3 MUL DUP2 ISZERO DUP4 DUP4 DUP4 DIV EQ OR ISZERO PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP PUSH8 0xde0b6b3a7640000 DUP2 DIV SWAP1 POP DUP1 DUP3 ADD DUP3 DUP2 LT PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP PUSH2 0x2a0 MSTORE PUSH2 0x220 MLOAD PUSH1 0x1 DUP2 ADD DUP2 DUP2 LT PUSH2 0x240a JUMPI SWAP1 POP PUSH2 0x220 MSTORE TIMESTAMP PUSH2 0x380 MLOAD XOR PUSH2 0x1d68 JUMPI NUMBER PUSH2 0x2a0 MSTORE PUSH2 0x1db3 JUMP JUMPDEST PUSH2 0x220 MLOAD PUSH13 0x1431e0fae6d7217ca9fffffff DUP2 GT PUSH2 0x240a JUMPI PUSH1 0x2 SHL PUSH1 0x5 ADD PUSH2 0x240 MLOAD DUP2 SSTORE PUSH2 0x260 MLOAD PUSH1 0x1 DUP3 ADD SSTORE PUSH2 0x280 MLOAD PUSH1 0x2 DUP3 ADD SSTORE PUSH2 0x2a0 MLOAD PUSH1 0x3 DUP3 ADD SSTORE POP PUSH1 0x1 ADD DUP2 DUP2 XOR PUSH2 0x1bbf JUMPI JUMPDEST POP POP PUSH2 0x220 MLOAD PUSH1 0x4 SSTORE PUSH1 0x40 MLOAD ISZERO PUSH2 0x1e87 JUMPI PUSH2 0x260 MLOAD PUSH2 0x180 MLOAD PUSH2 0x100 MLOAD DUP1 DUP3 SUB DUP1 PUSH1 0xf SIGNEXTEND DUP2 XOR PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP DUP1 DUP3 ADD DUP1 PUSH1 0xf SIGNEXTEND DUP2 XOR PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP PUSH2 0x260 MSTORE PUSH2 0x240 MLOAD PUSH2 0x160 MLOAD PUSH1 0xe0 MLOAD DUP1 DUP3 SUB DUP1 PUSH1 0xf SIGNEXTEND DUP2 XOR PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP DUP1 DUP3 ADD DUP1 PUSH1 0xf SIGNEXTEND DUP2 XOR PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP PUSH2 0x240 MSTORE PUSH32 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff PUSH2 0x260 MLOAD SGT PUSH2 0x1e57 JUMPI PUSH0 PUSH2 0x260 MSTORE JUMPDEST PUSH32 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff PUSH2 0x240 MLOAD SGT PUSH2 0x1e87 JUMPI PUSH0 PUSH2 0x240 MSTORE JUMPDEST PUSH2 0x220 MLOAD PUSH13 0x1431e0fae6d7217ca9fffffff DUP2 GT PUSH2 0x240a JUMPI PUSH1 0x2 SHL PUSH1 0x5 ADD PUSH2 0x240 MLOAD DUP2 SSTORE PUSH2 0x260 MLOAD PUSH1 0x1 DUP3 ADD SSTORE PUSH2 0x280 MLOAD PUSH1 0x2 DUP3 ADD SSTORE PUSH2 0x2a0 MLOAD PUSH1 0x3 DUP3 ADD SSTORE POP PUSH1 0x40 MLOAD ISZERO PUSH2 0x203a JUMPI TIMESTAMP PUSH1 0x80 MLOAD GT ISZERO PUSH2 0x1f3f JUMPI PUSH2 0x1e0 MLOAD PUSH2 0x100 MLOAD DUP1 DUP3 ADD DUP1 PUSH1 0xf SIGNEXTEND DUP2 XOR PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP PUSH2 0x1e0 MSTORE PUSH1 0x80 MLOAD PUSH1 0xc0 MLOAD XOR PUSH2 0x1f1f JUMPI PUSH2 0x1e0 MLOAD PUSH2 0x180 MLOAD DUP1 DUP3 SUB DUP1 PUSH1 0xf SIGNEXTEND DUP2 XOR PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP PUSH2 0x1e0 MSTORE JUMPDEST PUSH2 0x1e0 MLOAD PUSH13 0x50c783eb9b5c85f2a80000007 PUSH1 0x80 MLOAD PUSH1 0x20 MSTORE PUSH0 MSTORE PUSH1 0x40 PUSH0 KECCAK SSTORE JUMPDEST TIMESTAMP PUSH1 0xc0 MLOAD GT ISZERO PUSH2 0x1f92 JUMPI PUSH1 0x80 MLOAD PUSH1 0xc0 MLOAD GT ISZERO PUSH2 0x1f92 JUMPI PUSH2 0x200 MLOAD PUSH2 0x180 MLOAD DUP1 DUP3 SUB DUP1 PUSH1 0xf SIGNEXTEND DUP2 XOR PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP PUSH2 0x200 MSTORE PUSH2 0x200 MLOAD PUSH13 0x50c783eb9b5c85f2a80000007 PUSH1 0xc0 MLOAD PUSH1 0x20 MSTORE PUSH0 MSTORE PUSH1 0x40 PUSH0 KECCAK SSTORE JUMPDEST PUSH13 0x50c783eb9b5c85f2a80000006 PUSH1 0x40 MLOAD PUSH1 0x20 MSTORE PUSH0 MSTORE PUSH1 0x40 PUSH0 KECCAK SLOAD PUSH1 0x1 DUP2 ADD DUP2 DUP2 LT PUSH2 0x240a JUMPI SWAP1 POP PUSH2 0x3a0 MSTORE PUSH2 0x3a0 MLOAD PUSH13 0x50c783eb9b5c85f2a80000006 PUSH1 0x40 MLOAD PUSH1 0x20 MSTORE PUSH0 MSTORE PUSH1 0x40 PUSH0 KECCAK SSTORE TIMESTAMP PUSH2 0x1a0 MSTORE NUMBER PUSH2 0x1c0 MSTORE PUSH13 0x50c783eb9b5c85f2a80000005 PUSH1 0x40 MLOAD PUSH1 0x20 MSTORE PUSH0 MSTORE PUSH1 0x40 PUSH0 KECCAK PUSH2 0x3a0 MLOAD PUSH4 0x3b9ac9ff DUP2 GT PUSH2 0x240a JUMPI PUSH1 0x2 SHL DUP2 ADD SWAP1 POP PUSH2 0x160 MLOAD DUP2 SSTORE PUSH2 0x180 MLOAD PUSH1 0x1 DUP3 ADD SSTORE PUSH2 0x1a0 MLOAD PUSH1 0x2 DUP3 ADD SSTORE PUSH2 0x1c0 MLOAD PUSH1 0x3 DUP3 ADD SSTORE POP JUMPDEST JUMP JUMPDEST PUSH2 0x440 MLOAD PUSH2 0x4a0 MSTORE PUSH2 0x460 MLOAD PUSH2 0x4c0 MSTORE PUSH1 0x2 SLOAD PUSH2 0x4e0 MSTORE PUSH2 0x4e0 MLOAD PUSH2 0x400 MLOAD DUP1 DUP3 ADD DUP3 DUP2 LT PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP PUSH1 0x2 SSTORE PUSH2 0x4a0 MLOAD PUSH2 0x500 MSTORE PUSH2 0x4c0 MLOAD PUSH2 0x520 MSTORE PUSH2 0x4a0 MLOAD PUSH2 0x400 MLOAD DUP1 PUSH1 0x7f SHR PUSH2 0x240a JUMPI DUP1 DUP3 ADD DUP1 PUSH1 0xf SIGNEXTEND DUP2 XOR PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP PUSH2 0x4a0 MSTORE PUSH2 0x420 MLOAD ISZERO PUSH2 0x20b3 JUMPI PUSH2 0x420 MLOAD PUSH2 0x4c0 MSTORE JUMPDEST PUSH1 0x3 PUSH2 0x3e0 MLOAD PUSH1 0x20 MSTORE PUSH0 MSTORE PUSH1 0x40 PUSH0 KECCAK PUSH2 0x4a0 MLOAD DUP2 SSTORE PUSH2 0x4c0 MLOAD PUSH1 0x1 DUP3 ADD SSTORE POP PUSH2 0x3e0 MLOAD PUSH1 0x40 MSTORE PUSH2 0x500 MLOAD PUSH1 0x60 MSTORE PUSH2 0x520 MLOAD PUSH1 0x80 MSTORE PUSH2 0x4a0 MLOAD PUSH1 0xa0 MSTORE PUSH2 0x4c0 MLOAD PUSH1 0xc0 MSTORE PUSH2 0x20fd PUSH2 0x1979 JUMP JUMPDEST PUSH2 0x400 MLOAD ISZERO PUSH2 0x2165 JUMPI PUSH1 0x1 SLOAD PUSH4 0x23b872dd PUSH2 0x540 MSTORE PUSH2 0x3e0 MLOAD PUSH2 0x560 MSTORE ADDRESS PUSH2 0x580 MSTORE PUSH2 0x400 MLOAD PUSH2 0x5a0 MSTORE PUSH1 0x20 PUSH2 0x540 PUSH1 0x64 PUSH2 0x55c PUSH0 DUP6 GAS CALL PUSH2 0x2141 JUMPI RETURNDATASIZE PUSH0 PUSH0 RETURNDATACOPY RETURNDATASIZE PUSH0 REVERT JUMPDEST PUSH1 0x20 RETURNDATASIZE LT PUSH2 0x240a JUMPI PUSH2 0x540 MLOAD DUP1 PUSH1 0x1 SHR PUSH2 0x240a JUMPI PUSH2 0x5c0 MSTORE PUSH2 0x5c0 SWAP1 POP MLOAD ISZERO PUSH2 0x240a JUMPI JUMPDEST PUSH2 0x4c0 MLOAD PUSH2 0x3e0 MLOAD PUSH32 0x4566dfc29f6f11d13a418c26a02bef7c28bae749d4de47e4e6a7cddea6730d59 PUSH2 0x400 MLOAD PUSH2 0x540 MSTORE PUSH2 0x480 MLOAD PUSH2 0x560 MSTORE TIMESTAMP PUSH2 0x580 MSTORE PUSH1 0x60 PUSH2 0x540 LOG3 PUSH32 0x5e2aa66efd74cce82b21852e317e5490d9ecc9e6bb953ae24d90851258cc2f5c PUSH2 0x4e0 MLOAD PUSH2 0x540 MSTORE PUSH2 0x4e0 MLOAD PUSH2 0x400 MLOAD DUP1 DUP3 ADD DUP3 DUP2 LT PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP PUSH2 0x560 MSTORE PUSH1 0x40 PUSH2 0x540 LOG1 JUMP JUMPDEST PUSH0 PUSH1 0x80 MSTORE PUSH1 0x60 MLOAD PUSH1 0xa0 MSTORE PUSH0 PUSH1 0x80 SWAP1 JUMPDEST DUP1 PUSH1 0xc0 MSTORE PUSH1 0xa0 MLOAD PUSH1 0x80 MLOAD LT PUSH2 0x2217 JUMPI PUSH2 0x2298 JUMP JUMPDEST PUSH1 0x80 MLOAD PUSH1 0xa0 MLOAD DUP1 DUP3 ADD DUP3 DUP2 LT PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP PUSH1 0x1 DUP2 ADD DUP2 DUP2 LT PUSH2 0x240a JUMPI SWAP1 POP DUP1 PUSH1 0x1 SHR SWAP1 POP PUSH1 0xe0 MSTORE PUSH1 0x40 MLOAD PUSH1 0xe0 MLOAD PUSH13 0x1431e0fae6d7217ca9fffffff DUP2 GT PUSH2 0x240a JUMPI PUSH1 0x2 SHL PUSH1 0x5 ADD PUSH1 0x3 DUP2 ADD SWAP1 POP SLOAD GT ISZERO PUSH2 0x2286 JUMPI PUSH1 0xe0 MLOAD PUSH1 0x1 DUP2 SUB DUP2 DUP2 GT PUSH2 0x240a JUMPI SWAP1 POP PUSH1 0xa0 MSTORE PUSH2 0x228d JUMP JUMPDEST PUSH1 0xe0 MLOAD PUSH1 0x80 MSTORE JUMPDEST PUSH1 0x1 ADD DUP2 DUP2 XOR PUSH2 0x2203 JUMPI JUMPDEST POP POP PUSH1 0x80 MLOAD DUP2 MSTORE POP JUMP JUMPDEST PUSH1 0x40 MLOAD PUSH1 0xe0 MSTORE PUSH1 0x60 MLOAD PUSH2 0x100 MSTORE PUSH1 0x80 MLOAD PUSH2 0x120 MSTORE PUSH1 0xa0 MLOAD PUSH2 0x140 MSTORE PUSH2 0x120 MLOAD PUSH3 0x93a80 DUP2 DIV SWAP1 POP PUSH3 0x93a80 DUP2 MUL DUP2 PUSH3 0x93a80 DUP3 DIV XOR PUSH2 0x240a JUMPI SWAP1 POP PUSH2 0x160 MSTORE PUSH0 PUSH1 0xff SWAP1 JUMPDEST DUP1 PUSH2 0x180 MSTORE PUSH2 0x160 MLOAD PUSH3 0x93a80 DUP2 ADD DUP2 DUP2 LT PUSH2 0x240a JUMPI SWAP1 POP PUSH2 0x160 MSTORE PUSH0 PUSH2 0x1a0 MSTORE PUSH1 0xc0 MLOAD PUSH2 0x160 MLOAD GT PUSH2 0x2338 JUMPI PUSH13 0x50c783eb9b5c85f2a80000007 PUSH2 0x160 MLOAD PUSH1 0x20 MSTORE PUSH0 MSTORE PUSH1 0x40 PUSH0 KECCAK SLOAD PUSH2 0x1a0 MSTORE PUSH2 0x2340 JUMP JUMPDEST PUSH1 0xc0 MLOAD PUSH2 0x160 MSTORE JUMPDEST PUSH1 0xe0 MLOAD PUSH2 0x100 MLOAD PUSH2 0x160 MLOAD PUSH2 0x120 MLOAD DUP1 DUP3 SUB DUP3 DUP2 GT PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP DUP1 PUSH1 0x7f SHR PUSH2 0x240a JUMPI DUP1 DUP3 MUL DUP1 PUSH1 0xf SIGNEXTEND DUP2 XOR PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP DUP1 DUP3 SUB DUP1 PUSH1 0xf SIGNEXTEND DUP2 XOR PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP PUSH1 0xe0 MSTORE PUSH1 0xc0 MLOAD PUSH2 0x160 MLOAD XOR PUSH2 0x239b JUMPI PUSH2 0x23cb JUMP JUMPDEST PUSH2 0x100 MLOAD PUSH2 0x1a0 MLOAD DUP1 DUP3 ADD DUP1 PUSH1 0xf SIGNEXTEND DUP2 XOR PUSH2 0x240a JUMPI SWAP1 POP SWAP1 POP PUSH2 0x100 MSTORE PUSH2 0x160 MLOAD PUSH2 0x120 MSTORE PUSH1 0x1 ADD DUP2 DUP2 XOR PUSH2 0x22e6 JUMPI JUMPDEST POP POP PUSH32 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff PUSH1 0xe0 MLOAD SGT PUSH2 0x23fb JUMPI PUSH0 PUSH1 0xe0 MSTORE JUMPDEST PUSH1 0xe0 MLOAD PUSH0 DUP2 SLT PUSH2 0x240a JUMPI DUP2 MSTORE POP JUMP JUMPDEST PUSH0 DUP1 REVERT'

    Precompiles

    Precompiles are special contracts that are implemented using native code. We can devise a pattern to find their usage after looking at how the compiler calls them15.

  • 15 See ecadd implementation

    • PRECOMPILES = {
    "0x1": "ecrecover",
    "0x2": "sha256",
    "0x3": "ripemd160",
    "0x4": "identity",
    "0x5": "modexp",
    "0x6": "alt_bn128_add",
    "0x7": "alt_bn128_mul",
    "0x8": "alt_bn128_pairing_check",
    "0x9": "blake2f",
}
PRECOMPILE_REGEX = r"PUSH1 (0x[1-9]) GAS STATICCALL"


def get_precompiles(code):
    opcodes = disasm(code)
    extracted = re.findall(PRECOMPILE_REGEX, opcodes)
    return [PRECOMPILES.get(x, x) for x in extracted]


(
    vypers.with_columns(precompiles=pl.col("clean_code").apply(get_precompiles))
    .explode("precompiles")
    .groupby("precompiles")
    .agg(pl.count())
    .filter(pl.col("precompiles").is_not_null())
    .sort("count", descending=True)
)
    shape: (3, 2)
    precompiles count
    str u32
    "identity" 5690
    "ecrecover" 299
    "sha256" 2

    At this point we have full assurance that nobody has ever used Vyper for moon math.

    Opcodes

    Our pipeline has reached its full potential, and we can easily repeat the scan for opcodes in question16.

  • 16 See uint256_addmod and uint256_mulmod implementation

    • OPCODE_REGEX = r"ADDMOD|MULMOD"


def get_opcodes(code):
    opcodes = disasm(code)
    extracted = re.findall(OPCODE_REGEX, opcodes)
    return sorted(set(extracted))


(
    vypers.with_columns(opcodes=pl.col("clean_code").apply(get_opcodes))
    .filter(pl.col("opcodes").list.lengths() > 0)
    .with_columns(
        pl.col(pl.Binary).bin.encode("hex"), pl.col("opcodes").list.join(", ")
    )
    .select(["contract_address", "deployer", "opcodes"])
)
    shape: (7, 3)
    contract_address deployer opcodes
    str str str
    "53cc3e49418380e835fc8cacd5932482c586efea" "e6da683076b7ed6ce7ec972f21eb8f91e9137a17" "MULMOD"
    "66442b0c5260b92caa9c234ecf2408cbf6b19a6f" "e6da683076b7ed6ce7ec972f21eb8f91e9137a17" "MULMOD"
    "5fc124a161d888893529f67580ef94c2784e9233" "e6da683076b7ed6ce7ec972f21eb8f91e9137a17" "MULMOD"
    "ab595f0bf1d7787a0a39243074a820378afe1504" "bc210cc8c2bb0400c80196b6d47d6b2875cab3bd" "MULMOD"
    "c742904b04193d36b1f93255f98dc9ed2ca4c2aa" "bc210cc8c2bb0400c80196b6d47d6b2875cab3bd" "MULMOD"
    "80333bd8791fee04c4c3e1ca8a524cefa7c94737" "babe61887f1de2713c6f97e567623453d3c79f67" "MULMOD"
    "7624c0dd4f5d06d650ddff25ffec45d032501260" "babe61887f1de2713c6f97e567623453d3c79f67" "MULMOD"

    Resolution

    Good news, we have narrowed the results down to just 0.2% of our initial search, and it’s easy to assess by hand from there.

    Among several unverified contracts we find one Curve contract17 that uses uint256_mulmod. I promptly contact the devs and get a confirmation it’s a discarded test iteration and not a production contract. It wouldn’t have been vulnerable anyway since the issue only affects the order of evaluation of side effects and not the order of arguments themselves, which would’ve likely been caught by tests.

  • 17 It is always a good idea to add a natspec for @author

    • With this work done, we have established with absolute certainty that no production contract is affected and the devs can safely proceed with disclosing the bug.

    ]]>     vyper data https://banteg.xyz/posts/vyper-opcodes/index.html Fri, 01 Sep 2023 20:00:00 GMT     EIP-4626 Compatibility Study banteg https://banteg.xyz/posts/eip-4626/index.html

    Summary

    There are currently 566 contracts implementing EIP-4626 Tokenized Vaults standard on Ethereum mainnet.

    Of them, 69 contracts, including some notable ones like Savings DAI and Staked Yearn Ether, don’t emit a Transfer event on mint/deposit/burn/redeem.

    This could affect tokens being picked up by explorers and wallets, as well as require changes to data analytics pipelines to correctly account for all balance changes.

    The results can be found here (.csv).

    How it happened

    The EIP-4626 standard defines Deposit and Withdraw events that contain all the needed info. The Transfer event comes from ERC-20 Token Standard, which says:

    A token contract which creates new tokens SHOULD trigger a Transfer event with the _from address set to 0x0 when tokens are created.

    It doesn’t contain a strict requirement (and auditors agree) as it doesn’t say anything about burning, but every data analyst hates it when a token doesn’t follow an implicit convention of Transfer(0x, receiver, amount) on mint and Transfer(owner, 0x, amount) on burn.

    This problem can be traced to EIP-4626 example repo and most likely stems from it.

    The problem doesn’t exist in other implementation like Snekmate and Solady.

    What can be done

    If you operate an explorer or a wallet, you can do the following:

    1. For Deposit(sender, owner, assets, shares) event check if there is an adjacent Transfer(0x0, owner, shares) and if it’s missing, insert it.

    2. For Withdraw(sender, receiver, owner, assets, shares) check for Transfer(owner, 0x0, shares) and add it if it’s missing.

    Methodology

    To find all EIP-4626 compatible tokens you can start from all the Deposit events. As often happens with events, there would be collisions with unrelated contracts that happen to share the same selector. The code here uses Ape and some portions could be shortened or omitted for brevity.

    sdai = Contract('0x83F20F44975D03b1b09e64809B757c47f942BEeA')
log_filter = LogFilter.from_event(sdai.Deposit)
deposit_logs = list(chain.provider.get_contract_logs(log_filter))

    This would pull all Deposit events emitted by all addresses. Do the same for Withdraw events. Now we need to filter out the incompatible contracts. EIP-4626 doesn’t require implementing EIP-165 supportsInterface method, so let’s do this by comparing a contract interface against the reference ABI.

    abi = requests.get('https://raw.githubusercontent.com/fubuloubu/ERC4626/main/contracts/ERC4626.json').json()
erc4626 = ContractType.parse_obj({'abi': abi})

def is_erc4626(c: ContractType):
    events = all(e in c.events for e in erc4626.events)
    methods = all(m in c.methods for m in erc4626.methods)
    return events and methods

    Next up we pull all the Transfer logs for found contracts.

    log_filter = LogFilter.from_event(sdai.Transfer, addresses=erc4626_compatible_addrs)
transfer_logs = list(chain.provider.get_contract_logs(log_filter))

    The only remaining thing is to find whether there was a matching Transfer event for each Deposit and Withdraw event and annotate the results.

    def check_compat(addr):
    transfer_tuples = {tuple(log.event_arguments.values()) for log in transfer_logs_by_addr[addr]}

    try:    
        for log in deposit_logs_by_addr[addr]:
            assert len(log.event_arguments) == 4
            transfer_args = ZERO_ADDRESS, log['owner'], log['shares']
            assert transfer_args in transfer_tuples
        
        for log in withdraw_logs_by_addr[addr]:
            assert len(log.event_arguments) == 5
            transfer_args = log['owner'], ZERO_ADDRESS, log['shares']
            assert transfer_args in transfer_tuples
    except AssertionError:
        return False

    return True
    ]]>     ethereum data https://banteg.xyz/posts/eip-4626/index.html Mon, 28 Aug 2023 20:00:00 GMT     100x faster EVM traces with Python banteg https://banteg.xyz/posts/evm-trace/index.html An introduction to evm-trace, a fast and correct Python library to work with Ethereum Virtual Machine traces.

    There are two common trace formats, which we’ll refer to as Geth-style and Parity-style traces. Geth traces provide opcode-level resolution, while the most commonly used Parity trace format provides a call tree.

    Our goal today would be to make opcode-resolution traces 100x faster, making them from a little-known Parity trace format. We’ll also make them compatible with Geth traces so they can be used as a drop-in replacement.

    debug_traceTransaction

    Geth traces return frames containing the full state of the virtual machine at each step of the execution, including the program counter, opcode, remaining gas, gas cost of the operation, call depth, items on the stack, a snapshot of the memory, and a storage diff.

    Each subcall starts with a fresh and separate memory, stack, and storage changes.

    It’s a powerful but a bit unwieldy format, since you need to do extra work to know things like what’s the current contract being called or what’s the calldata.

    I started digging into this when I stumbled upon several transactions that crash Erigon if you request a debug trace. It appeared that they generated very large traces, and soon enough I was able to confirm why when Erigon re-enabled streaming for heavy RPC endpoints.

    In Geth format each frame contains the full copy of the EVM memory, which can lead to traces that don’t fit in the system memory. A contract expanding the memory to 100kb could generate traces as large as 70 GB.

    This can be addressed by streaming and iteratively decoding the response as you get it from the Ethereum client. This is what ape does by default with Geth traces when you call receipt.get_transaction_trace().

    If we look up the memory expansion gas cost formulas at evm.codes, it becomes apparent that EVM memory is not that expensive and we can possibly construct or find transactions with even larger traces.

    memory_cost = (memory_size_word ** 2) / 512 + (3 * memory_size_word)

    After sampling peak memory usage over 10,000 most recent blocks, we find even larger traces. For one of those, Erigon hangs up on us after 30 minutes, after returning 460 GB and 898,836 frames.

    We can patch Erigon to increase the write timeout, and learn that the full trace consists of 960,198 frames, takes up 524 GB and 34m7s to fetch, before deserialization or processing. We can calculate that we got this trace at 275 MB/s and 469 frames/s.

    Keep that number in mind, because with a method presented below, we can recompute the same trace using 137 MB of data (3916x less), which we can fetch in 5.6s, deserialize in 7.1s and replay in 4.6 seconds, with full processing taking 117x less time than just fetching a Geth trace.

    contracts with peak memory usage

    trace_replayTransaction

    Parity traces are quite different from Geth, the ad hoc traces come in three different flavors: trace, vmTrace, and stateDiff.

    Parity traces are supported in Erigon, Nethermind, Besu, Foundry. They are not supported in Geth, Hardhat, Ganache. Anything beyond trace type requires an archive node.

    trace

    The trace is the most widely used mode, it returns a call tree, similar to what you can see on ethtx.info (archived) or when calling receipt.show_trace() in ape. If you need a raw call tree, you can get it from chain.provider.get_call_tree(tx). You can also provide a custom display class and only display the parts you care about.

    Lido.executeVote as raw and decorated call tree

    stateDiff

    The stateDiff mode shows the changes of balance, code, nonce, and storage grouped by account.

    a raw stateDiff

    A more interesting problem here is how to map storage keys to readable names like balanceOf[account]. I’ve seen it solved in Tenderly, which is a proprietary tool.

    Maybe you, the reader, could be the one to tackle this problem and release it as an open source tool for everyone to use.

    a decoded stateDiff in tenderly

    vmTrace

    The vmTrace mode is one of the most enigmatic and rarely used, mainly because it was never really documented. This mode will be the main focus of this article and I’ll show you how you can make a drop-in replacement for Geth traces that requires 1000x less data and works 100x faster.

    vmTrace returns a nested structure of incremental updates which we can use to replay the transaction, while tracking stack, memory, storage at each step of the execution. Of course, the incremental format doesn’t come for free and requires some legwork.

    vmTrace struct

    Here is what we get in a vmTrace response:

    • VMTrace represents a call and contains all subcalls
      • code EVM bytecode to be executed
      • ops list of VMOperation to be executed
    • VMOperation represents a step of the execution
      • pc program counter
      • cost gas cost of the operation
      • ex the result of the execution, could be null if the operation has reverted
      • sub list of VMTrace subcalls
      • op opcode name
      • idx index in the call tree
    • VMExecutedOperation represents side effects of executing the operation
      • used incorrectly named, shows the remaining gas
      • push the items to be placed on the stack
      • mem the memory delta
      • store the storage delta
    • MemoryDiff represents a memory update
      • off memory offset where to write the data
      • data the bytes to write starting at the offset
    • StorageDiff represents a storage write
      • key storage key to write to
      • val value to write

    I defined this structure using msgspec to get fast deserialization and type validation.

    Missing pieces

    Now we need to replay the transaction, applying the incremental updates and untangling the nested structure into a flat execution order.

    I borrowed the real Stack and Memory implementations from py-evm, which is a great EVM reference itself.

    I wrote a small harness to do pairwise comparison of each frame of my synthetic trace with Geth trace frames, which exited after the first divergence in stack or memory. I learned that Geth sends frames after memory expansion but before anything from ex has been applied.

    Memory was no problem, but the stack was missing a few important pieces. We had push, but no info about the number of items popped from the stack by each opcode.

    Popcodes

    I’ve assembled this list by hand using this file from ethereumjs as a reference. These opcodes pop a fixed amount of items:

    1. EXTCODEHASH, ISZERO, NOT, BALANCE, CALLDATALOAD, EXTCODESIZE, BLOCKHASH, POP, MLOAD, SLOAD, JUMP, SELFDESTRUCT
    2. SHL, SHR, SAR, REVERT, ADD, MUL, SUB, DIV, SDIV, MOD, SMOD, EXP, SIGNEXTEND, LT, GT, SLT, SGT, EQ, AND, XOR, OR, BYTE, SHA3, MSTORE, MSTORE8, SSTORE, JUMPI, RETURN
    3. RETURNDATACOPY, ADDMOD, MULMOD, CALLDATACOPY, CODECOPY, CREATE
    4. CREATE2, EXTCODECOPY
    5. —
    6. STATICCALL, DELEGATECALL
    7. CALL, CALLCODE

    These opcodes can be expressed as a formula:

    • LOG0-LOG4 pops 2-6 items
    • SWAP1-SWAP16 pops¹ 2-17 items
    • DUP1-DUP16 pops¹ 1-16 items

    ¹ not really, this is only true for how the vmTrace format is served

    Opcode incognita

    Some transactions reconciled, but the stack still diverged, especially for large transactions. Using foundry’s debugger I found that the incremental updates have missed occasional pushes for several opcodes, namely SMOD, CHAINID, COINBASE. I fixed this in Erigon and the patch has already made it to 2022.07.03-alpha release.

    This finding has made me question a lot of things. Most people fully trust the data they get from the node, but Ethereum is a very complex system and bugs happen. It’s great having so many clients and references and different approaches to check on each other.

    Performance

    I’ve added full block tracing with opcode-level resolution and an option to return a memoryview of the memory bytearray instead of copying it for each frame. It works like a pointer and comes with a caveat that you must process the frame immediately after receiving it from the iterator, otherwise the value may be mutated. It should work for most streaming workflows with traces, since you are usually scanning for some specific frames and don’t look back.

    I’ve benchmarked evm-trace against the largest traces I could identify. Most of them were replayed in under 3 seconds, with no significant slowdown even when a lot of memory is allocated. I’ve also benchmarked it against 1000 most recent Ethereum mainnet blocks. It was pleasant seeing the needle has moved from seconds per trace to traces per second.

    evm-trace performance benchmark

    When dealing with full blocks, you can expect to fetch a median of 27.4 transactions per second from the node and replay 108.8 transactions per second at around 252,000 frames per second. When requesting traces of individual transactions, your client replays all transactions in the block up to the requested transaction index to get to the correct state and discards all other traces. To give you the intuition, here is how many frames you would usually encounter in a block:

    Give it a try

    This lightning-fast drop-in replacement for Geth-style traces is available in the latest evm-trace and soon will be integrated into ape, your new favorite Ethereum development and data science framework.

    References

    ]]>     ethereum ape https://banteg.xyz/posts/evm-trace/index.html Mon, 25 Jul 2022 20:00:00 GMT     Quest for a lost Event banteg https://banteg.xyz/posts/lost-event/index.html

    cover

    The last time I wrote about Ethereum logs was in 2018. This time we go deeper and try to recover a ghost event that devs have forgotten to add to the Yearn Vaults contract.

    log Fees(management_fee, performance_fee, strategist_fee)

    There are several methods to recover values from an internal view method or even add custom views to batch read private storage. One of the more interesting ones is a “state override” option of eth_call, which allows you to replace the code and storage for the context of the call.

    To my deep disappointment, you can’t just set a breakpoint on a line you want, start a debugger to capture the local variables, and call it a day. This may change soon with a Vyper interpreter being in the works.

    This post will describe a method based on capturing the values from a trace frame. The values we are interested in should appear on the stack or in the memory around this line.

    Obtain Vyper metadata

    The debug_traceTransaction method gives us trace frames with opcode-level resolution. To find the correct trace frame, we need to find the program counter around the end of _assessFees method execution. Maybe the metadata Vyper compiler generates could help us do that:

    vyper -f source_map contracts/Vault.vy > source_map.json

    The source map contains pc_jump_map and pc_pos_map, which looks promising. The jump map contains values of i, o, -, which seem to stand for jump in, jump out, and jump umm. Intuitively we want to find the jump out of the function, but it won’t be there since it’s the last internal method in the contract.

    The position map is formatted as start_line, start_col, end_line, end_col for each program counter. This could help us limit the search window to the desired function. The simplest way to find the line numbers is to just look at the source file, but there are a dozen of Vault releases, and we want to automate the search as much as possible. Getting more metadata from the compiler wouldn’t hurt:

    vyper -f ast contracts/Vault.vy > ast.json

    This format outputs the abstract syntax tree of the parsed contract, which looks the same as Python ast. We can find all the definitions in the ast body, and find the function by name:

    fn = next(item for item in ast["ast"]["body"] if item.get("name") == "_assessFees")

    The definition would contain lineno and end_lineno, which is exactly what we need to scale the search to all versions. Now we can output all the program counters which have originated from a line range in the source and exist in the jump table.

    They will also come in handy later when we need to deal with edge cases.

    Rewrite in Python

    After writing a script that checks out all Vault releases from git tags and compiles them, we have enough metadata to start the search. But we still don’t have the concrete values to match on. Luckily it’s easy to convert Vyper to Python. You just rename the file.

    Yearn Vaults also behave according to their apiVersion, so we can write a universal _assessFees function, which was an interesting enough exercise on its own. Even if it doesn’t handle all the edge cases yet, it works well enough to provide us with the calculated values to look for in a trace.

    Look at the trace

    Tip: If you often work with Ethereum traces in Python, consider looking at evm-trace, it can parse both Geth- (opcode-level) and Parity-style (call-level) traces, turn them into a call tree, and display them to your liking via a custom display class.

    A trace frame at the program counter we found contains all the values we need both on the stack and in memory, so I’ve hidden the memory part below and annotated the values I could identify on the stack.

    {
    'pc': 21139,
    'op': 'JUMP',
    'gas': 1749825,
    'gasCost': 8,
    'depth': 7,
    'stack': [
        '0xa1d9bafc',
        '0x70a08231',
        '0x564bf2844654f149821697cc56572ee4384c05f7',
        '0x4b6f40465bd258c16',  # gain
        '0x339c',
        '0x127504',             # duration
        '0x4bd8d4001a87b5afe',  # management fee
        '0x78b2007092ea279b',   # strategist fee
        '0x78b2007092ea279b',   # performance fee
        '0x4b6f40465bd258c16',  # total fee
        '0x47bdec03915b3ac1b',
        '0x409154699c6bb4e1a',
        '0x93a62da5a14c80f265dabc077fcee437b1a0efde',
        '0xfd0877d9095789caf24c98f7cce092fa8e120775',
        '0x5294',
        '0x4204'
    ],
    'memory': [
        ...
    ]
}

    Patch the compiler

    But how exactly have we found it, you may ask? After helplessly trying to write a scanner, staring into an endless stream of results, and talking to a few people about this problem, I heard something very promising from @big_tech_sux:

    The memory layout during the function execution is static.

    This means we can patch the compiler and output the positions in memory for each memory variable just by adding one line:

    print({sig.name: {name: varinfo.pos // 32 for varname, varinfo in context.vars.items()}})

    This will output something like this, which allows us to add a named memory view of pc → name → value

    {'_assessFees': {'#internal_0': 12, 'strategy': 10, 'gain': 11, 'duration': 13, 'management_fee': 14, 'strategist_fee': 15, 'performance_fee': 16, 'total_fee': 17}}

    Scanner 0.2

    Wiring it all together, we can build a much better scanner, and also come up with a concise way of mapping the values from the named memory layout.

    $ yearn-fees layout 0.3.1

    Even without the color coding marking the exact matches, you can clearly see the execution steps to grab the values from.

    layout = MemoryLayout(trace, version)
data = layout[16164]
data["management_fee"] = layout[15686]["governance_fee"]
data["performance_fee"] = layout[15697]["governance_fee"] - data["management_fee"]
data["duration"] = extract_from_stack(trace, 15475, 2)

    Old vaults work with the duration in place, so I repurposed the old scanner and matched multiple harvests on the literal value somewhere in the vicinity of the function.

    We also need to filter out the program counters which repeat more than once, since such matches could make the result undefined.

    Zoom into block

    After checking 13,000 harvests on mainnet, I’ve found a bunch of anomalies that my initial version couldn’t handle, namely, multiple harvests in the same transaction, and fee adjustments sandwiching the harvests, likely related to accounting fixes.

    If we read the state from a previous block, we’ll get an incorrect result from the calculation method, the duration for the second harvest in the same block would be zero, so no management fees would be applied. Luckily we can tell the order of events using log_index and only set the duration for the first harvest of the same vault (for <0.3.5) or the same strategy (<0.4.0). Since 0.4.0 harvesting the same strategy in the same block is not allowed.

    Another problem is getting the fee configuration if it was changed in the middle of the transaction. I came up with a tiny extension for dict which returns the closest previous value. Then I stored all the fee changes using (block_number, log_index) as an index.

    class AsofDict(dict):
    def __getitem__(self, key):
        return super().__getitem__(last(item for item in sorted(self) if item <= key))

    The third problem is the trace with multiple harvests is completely wrong, it has the same program counters repeating and it doesn’t say which contract we are currently in. You can either parse it into a call tree with evm-trace, or simply split on the JUMPDEST into a function and JUMP out of it, which is what I did.

    The 0.4.x series of vaults has demanded a more complex splitting logic since the function could exit early when there was no gain and the only value we could recover is duration.

    In the end, this didn’t work well either, and I changed the JUMP for a LOG2 where the StrategyReported event is fired. Since our frames have memory and stack parsed as integers, we need to convert the topic to int.

    decode_single('uint256', keccak(text=vault.StrategyReported.abi.selector))

    In the process I discovered a quirk with Vyper 0.2.8 which affects three of the oldest releases, it has the first and the last value in the pc_pos_map swapped. I fixed this by hand.

    Having two distinct implementations has helped immensely to make both of them more robust. I was mostly using the calculation implementation as a reference one, but in this example the traces method was correct. It turned out vaults before 0.3.5 have tracked lastReport at the vault level, not at per strategy level as newer vaults do.

    traces were right

    Index the data

    Note: some of what you see here is an aspirational api. If you want to repeat something, you may need some bunny patches for ape.

    Yearn Registry makes it trivial to find all Vault deployments and their corresponding versions:

    $ ape console --network :mainnet:geth
registry = Contract('v2.registry.ychad.eth')
vaults = groupby(attrgetter('api_version'), registry.NewVault)

    Similarly, it’s easy to find all the harvests:

    vault = Contract(address)
reports = list(vault.StrategyReported)

    We can find some more complex transactions to crush the remaining bugs using the new memory-viewing and frame-searching tools at our disposal:

    def txs_with_multiple_strategy_harvests():
    reports = get_reports()
    return valfilter(
        lambda logs: len(logs) >= 2,
        groupby(lambda log: (log.transaction_hash, log.strategy), reports),
    )

    Now we can parallelize with it and write the results in Postgres using pony, which is a nice Pythonic database library. For each report, we run both methods before writing to db and fail if the results don’t match perfectly, saving edge cases for further analysis.

    Optimize

    With traces being so giant (I’ve seen a 4GB one), we also need a caching system. Luckily traces compress really well, 50-100x even with gzip, so we modify diskcache to use it and not use pickletools.optimize, which is incredibly slow for large objects.

    If you port your pipeline to dask, you can run it in multiple worker processes, each running a thread pool, and even scale to multiple machines. It’s easy, since dask mostly consists of drop-in replacement for things you already know and love like pandas, numpy, and concurrent.futures. It would also automatically distribute the load and restart the crashed or memory-leaking workers for you.

    If you need another reason to try dask, it comes with an amazing dashboard, which shows resource usage and even a flamegraph of the execution profile, which is super handy when optimizing for speed. Let’s take a look at it.

    http://127.0.0.1:8787/profile

    You can clearly see that loading the data takes even more time than the request itself. The culprit is probably the attrdict middleware that converts dict responses and adds attribute access to them. This seems like a poor idea when dealing with traces, which can have hundreds of thousands of elements.

    %time web3.manager.request_blocking('debug_traceTransaction', tx)
Wall time: 33 s

web3.middleware_onion.remove('attrdict')

%time web3.manager.request_blocking('debug_traceTransaction', tx)
Wall time: 8.5 s

    Hopefully, traces will become faster when Erigon adds transaction-level state index. Currently it has to execute all previous transaction in the block, and most of this work goes to waste.

    I rewrote how we fetch and parse the traces and the performance has improved significantly. Now I can just sit back and finish up this article while the indexing is still going.

    $ yearn-fees index

    The holy grail

    Shortly after publishing the article I dared MEV big brains to tell me there is a better method and one person has actually suggested it:

    https://twitter.com/0xdapper_/status/1544315954515025920

    The way I implemented it is you have a source folder, where you can change or add any functionality to contracts. Then you fork at a previous block using anvil, disable auto-mining, recompile if there were any source changes, replace the code, and replay all the preceding transactions (you don’t need to do anything with impersonated accounts, just replay as is with the original signatures).

    Then you fetch a receipt and find your newly added logs there. This method is slow, on the order of minutes, but it has helped to resolve the stalemate between two other methods, which was related to Strategy.delegatedAssets which has changed mid-block and has lead to a slight error in the assess method.

    All the code related to this article can be found in this repo.

    Special thanks to @big_tech_sux, @flashfish0x, @wavey0x.

    ]]>     ethereum data https://banteg.xyz/posts/lost-event/index.html Wed, 13 Jul 2022 20:00:00 GMT     Deep dive into MakerDAO Governance banteg https://banteg.xyz/posts/makerdao-governance/index.html

    Today we’ll look into MakerDAO voting process and recover the complete state of the governance contract. There are two types of voting: governance and executive. Governance voting can be seen a simple yes/no poll. Executive voting is much more interesting and it will be the subject of this article.

    How voting works

    Executive voting is handled like approval voting:

    • Anyone can create a proposal;
    • Users can vote for one or more proposals;
    • A proposal with the most votes gets the superpowers and can modify the system parameters.

    Proposal contract

    A proposal comes in a form of smart contract. The winning proposal is given the authorization to tap into mom contract. A common pattern for these contracts is to use ds-spell, which performs a single action once.

    The proposal to reduce the stability fee from 2.5% to 0.5% can be seen below. It shows which contract it calls, the call data and whether is has already been executed.

    Reads “Decrease the stability fee to 0.5%”.

    We can verify the spell using a simple script that decodes the data using interface (ABI) of the target contract:

    The result would be: setFee(uint256 ray 1000000000158153903837946257)

    How is this 0.5%, you may ask. To figure this out, we need to understand the units which this number is expressed in. Maker uses a few different units with various degrees of precision: wad, ray and rad.

    The argument title suggests the value is in ray, a fixed point number with 27 decimals. So it expresses 1.000000000158153903837946257.

    Turns out that the unit is the fee multiplier per second, so if we exponentiate it to the number of seconds in a year, we should get 1.005 or 100.5%.

    1.000000000158153903837946257³¹⁵³⁶⁰⁰⁰ = 1.005

    The proposal checks out! Go vote for it and come back for more fun.

    Voting contract

    Now let’s take a look at the voting contract, ds-chief. To vote for a proposal, one must lock MKR in this contract in return for IOU tokens. Only the locked tokens count as votes.

    Users vote for sets of candidates, which are stored in a slates mapping. There are two ways to vote:

    • vote(bytes32 slate) vote for an existing set of candidates.
    • vote(address[] yays) vote by providing a set of candidates, which also saves them into a slate using etch(address[] yays).

    The contract tallies the weights and awards the leading proposal with a hat. Having the hat means having superpowers. Now anyone can cast the spell and modify the system parameters.

    The voters

    With that knowledge, we can find all the proposals and voters. The plan:

    1. Find all the slates by looking at Etch(bytes32 indexed slate) events.
    2. Look up the proposals in the slates mapping.
    3. Fetch all votes and remember the most recent ones.
    4. Combine them with deposits of each voter.

    First, we save unique slates from the Etch events. Then we read the values from each slate array starting with index 0 and continue until we are out of bounds.

    The vote calls use non-standard events fired by ds-note. It provides a note modifier, which stores the function calls as indexed logs. There is no need to define events for each function, ds-note handles that on a lower level.

    To isolate the two functions (vote slates and vote yays), we need to construct a correct log filter. If you specify a topic in a filter as a list, it works like logical OR, which is exactly what we need.

    The first topic is a 4 byte function signature encoded as bytes32. The log data will have what we need to recover the votes.

    The voting system is using a proxy contract, so we can’t just look up the sender in the from field of the logs. Luckily for us, ds-note stores msg.sender as the second topic.

    The “slates to yays” we got earlier comes in handy for looking up candidates each user has voted for. The last step here is providing everyone with a voting weight based on their deposit.

    Now we can combine everything to see the complete picture.

    The full script that also tries to decode the spells can be found here.

    Today was indeed a productive day, hope you learned something useful. Subscribe to crypto eli5.

    ]]>     ethereum https://banteg.xyz/posts/makerdao-governance/index.html Thu, 20 Dec 2018 20:00:00 GMT     Ethereum clients initial sync benchmark banteg https://banteg.xyz/posts/ethereum-sync/index.html Syncing Ethereum blockchain head-on by fetching every block and replaying every transaction is impractical. That’s why different full nodes utilize clever techniques to speed up the initial sync and get up to speed in a reasonable time.

    According to Ethernodes, Etherum mainnet is dominated by Geth (55.7%), Parity Ethereum (31.5%), so we’ll discuss these two. All tests are done in October 2018 on a $30/mo dedicated server with the following config:

    2.4 GHz CPU with 8 cores
    16 GB of RAM
    250 GB SSD
    1 Gbit network

    Geth

    Geth (also known as go-ethereum) is written in golang and uses Google’s LevelDB as a storage backend. The default sync mode is called fast, it downloads all the needed data in parallel:

    • Block headers (6,475,108 headers took 13 hours 25 minutes)
    • Transaction receipts (same amount, finished roughly at the same time)
    • State tries (syncing 227.8 million states took 1 day 10 hours)

    A few hours into the sync, a message saying “Database compacting, degraded performance” starts to appear. The first one is at 4 hours 13 minutes mark and it gets worse after that. Geth ends up spending 4 hours 19 minutes (¹⁄₈ of the total time) completely halted by LevelDB compaction. After headers and receipts have finished downloaded, state sync finished without interruptions.

    A few minutes after the last state entry was downloaded, the node appeared fully synced.

    The final time is 1 day 10 hours. The database size is 130.9 GB.

    Unfortunately, Geth’s eth_syncing command doesn’t provide enough meaningful info to calculate the remaining time. It would be great to know how many states are there to sync, but traversing the whole state trie is probably a very expensive operation.

    Parity Ethereum

    Parity Ethereum (formerly Parity) is written in Rust and uses Facebook’s RocksDB as a storage backend. It’s backwards compatible with LevelDB, and has a bunch of additional features.

    Parity syncs in warp mode by default, which works like this:

    • Pull a recent snapshot (2209 chunks took 2 hours 20 minutes)
    • Sync the few remaining blocks (4651 blocks took 1 hour 33 minutes)
    • Process older blocks in the background (6,500,000 blocks in 1 day 2 hours 39 minuts)

    This makes the node usable after about 4 hours. You can interact with the blockchain and query the recent state and blocks that came after the snapshot with the older blocks unavailable until they are processed.

    The final time is 1 day 6 hours 32 minutes. The database size is 125.6 GB.

    Parity’s eth_syncing reports the total number of warp chunks as well as the total number of blocks, which allows to estimate the remaining time. It doesn’t report the status of the third step, but it can be monitored with a simple script like this:

    from web3.auto import w3
    for n in range(0, w3.eth.blockNumber, 10000):
    while not w3.eth.getBlock(n):
        sleep(60)
    print(n)

    If you want to get a deeper understanding of these challenges, I recommend reading the TurboSync paper.

    Hope you learned something useful. Subscribe to crypto eli5.

    ]]>     ethereum https://banteg.xyz/posts/ethereum-sync/index.html Tue, 06 Nov 2018 20:00:00 GMT     Announcing Disperse banteg https://banteg.xyz/posts/disperse/index.html verb distribute ether or tokens to multiple addresses

    https://disperse.app/

    Open Protocols

    The real beauty of Web 3.0 ecosystem we are building are open protocols. Anyone can tap into dharma loan protocol or 0x protocol exchange contract and get into shared liquidity pool for free. You can mix and match these too, creating completely unique products and markets.

    A protocol for fungible tokens (ERC-20) is probably the most successful thus far. It secures about $13 billion across a thousand assets. This protocol is quite simple actually, it defines a transfer function which updates balances in token contract and emits a Transfer event.

    But what allows to tap into it is the concept of allowance. A user can approve another account to transfer some amount on her behalf. For example, an exchange calls transferFrom user wallet when the order is filled. It’s programmed not to transfer more than the signed amount even though the allowance is set to -1 (meaning infinity).

    Optimization

    Like a good Unix tool, Disperse contract does a simple job and does it well, that’s why we shaved off every single bit to optimize for gas costs. A naive implementation of Disperse function might look like this:

    disperseTokenSimple(token, recipients, values)

    However, it’s not an optimal solution because the aforementioned transferFrom updates allowance on each call in addition to balances. That’s an additional 5000 gas on each transfer.

    A better way would be to calculate the total, transferFrom it to the contract address and then distribute the tokens using transfer function. There is no risk of funds being stuck because transactions work in “all or nothing” manner and the state will revert if anything goes wrong.

    disperseToken(token, recipients, values)

    The cost also depends heavily on whether each recipient has previously had any balance. Zero balance is the worst case because storing a new state entry costs 20,000 gas as opposed to 5000 gas for changing the value.

    Gas costs as described in Ethereum yellow paper

    Benchmark

    Here are the benchmark results for this contract (outlined in red) compared to sending tokens to one recipient at a time (grey). One block can fit up to 218 token transfers, while Disperse transaction can fit 2.9x as much, up to 634 transfers.

    disperseEther(recipients, values)

    Same goes for ether, one block can accommodate 380 regular transfers while Disperse can fit 2.18x more, up to 830 transfers. However, distributing ether to uninitialized accounts costs more because contracts pay 25,000 gas for calls that result in creation of new accounts as opposed to a flat 21,000 gas cost of a regular transfer.

    If you are using Metamask, you are probably connected to Infura node. It limits the maximum transaction size to 32 KB. This anti-spam measure caps the amount of recipients you can specify. You can broadcast a larger transaction by connecting to to a local node like Geth or Parity Ethereum. Infura’s limit is shown with a dotted line on the charts.

    Disperse

    We believe this space needs more builders and less fraud. Therefore Disperse doesn’t incorporate any useless token, has no sale and takes no fees.

    It’s a useful dapp that’s available day one on nine networks:

    • Ethereum and its testnets Ropsten, Kovan, Rinkeby;
    • POA Network and its testnet Sokol;
    • xDAI Chain;
    • Ethereum Classic;
    • Callisto.

    Go try it out on disperse.app.

    Read the research paper.

    Let us know what you think on Telegram.

    Correction:

    • Benchmark results have been revised accounting for a transaction size limit of 32 KB on Infura which is the default RPC provider on Metamask. Example transactions have been added.
    ]]>     ethereum https://banteg.xyz/posts/disperse/index.html Tue, 23 Oct 2018 20:00:00 GMT     Deep dive into Ethereum logs banteg https://banteg.xyz/posts/ethereum-logs/index.html Hey kids, today we are going low level trying to understand how Ethereum events and logs work. Put web3 away for a while as it abstracts things and we’d like to get as bare as it gets.

    Smart contracts generate logs by firing events. Here’s a transaction receipt that contains one log entry.

    The log entry consists of one topic and a data field. The first topic refers to the specific event, but we don’t know which one yet. To decode the data we need to obtain ABI of the contract found in the address field.

    We are interested in items with the type event. Here’s a sample event.

    {
  "anonymous": false,
  "inputs": [
    {
      "indexed": false,
      "name": "from",
      "type": "address"
    },
    {
      "indexed": false,
      "name": "to",
      "type": "address"
    },
    {
      "indexed": false,
      "name": "tokenId",
      "type": "uint256"
    }
  ],
  "name": "Transfer",
  "type": "event"
}

    To find out which event the topic refers to we need to compute a signature of each event and find the matching one. Signature is a keccak hash of event name and input argument types, argument names are ignored. For event Hello(uint256 worldId) the signature will be keccak('Hello(uint256)').

    > 
keccak
('Pregnant(address,uint256,uint256,uint256)')
241ea03ca20251805084d27d4440371c34a0b85ff108f6bb5611248f73818b80
> 
keccak
('Transfer(address,address,uint256)')
ddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef
> 
keccak
('Approval(address,address,uint256)')
8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925
> 
keccak
('Birth(address,uint256,uint256,uint256,uint256)')
0a5311bd2a6608f08a180df2ee7c5946819a649b204b554bb8e39825b2c50ad5
> 
keccak
('ContractUpgrade(address)')
450db8da6efbe9c22f2347f7c2021231df1fc58d3ae9a2fa75d39fa446199305

    As we can see, the signature of Transfer event matches the first topic. Now we can decode the data.

    > types = [i['type'] for i in e['inputs']]
['address', 'address', 'uint256']
    > names = [i['name'] for i in e['inputs']]
['from', 'to', 'tokenId']
    > values = eth_abi.decode_abi(types, log['data'])
('0x0035fc5208ef989c28d47e552e92b0c507d2b318',
 '0x646985c36ad7bf4f3a91283f3ea6eda2af79fac6',
 107696)
    > dict(zip(names, values))
{'from': '0x0035fc5208ef989c28d47e552e92b0c507d2b318',
 'to': '0x646985c36ad7bf4f3a91283f3ea6eda2af79fac6',
 'tokenId': 107696}

    We can finally read the log. The message says:

    “Transfer from 0x0035… to 0x6469… of token 107696”.

    Indexed fields

    Each indexed field generates a new topic which is excluded from the data. This allows for efficient search but makes parsing a bit more complicated.

    Let’s look at another receipt:

    This one has three topic fields and a small data field. We can already tell that the first topic is Transfer(address,address,uint256) despite the different argument names in this contract.

    {
  "anonymous": false,
  "inputs": [
    {
      "indexed": true,
      "name": "from",
      "type": "address"
    },
    {
      "indexed": true,
      "name": "to",
      "type": "address"
    },
    {
      "indexed": false,
      "name": "value",
      "type": "uint256"
    }
  ],
  "name": "Transfer",
  "type": "event"
}

    The remaining two topics are simply indexed inputs. The only value in data is the remaining uint256.

    > types = [i['type'] for i in e['inputs'] if not i['indexed']]
['uint256']
    > names = [i['name'] for i in e['inputs'] if not i['indexed']]
['value']
    > values = eth_abi.decode_abi(types, log['data'])
(5000000000,)
    > indexed_types = [i['type'] for i in e['inputs'] if i['indexed']]
['address', 'address']
    > indexed_names = [i['name'] for i in e['inputs'] if i['indexed']]
['from', 'to']
    > indexed_values = [eth_abi.decode_single(t, v) for t, v in zip(indexed_types, log['topics'][1:])]
['0x00b46c2526e227482e2ebb8f4c69e4674d262e75',
 '0x54a2d42a40f51259dedd1978f6c118a0f0eff078']
    > dict(chain(zip(names, values), zip(indexed_names, indexed_values)))
{'from': '0x00b46c2526e227482e2ebb8f4c69e4674d262e75',
 'to': '0x54a2d42a40f51259dedd1978f6c118a0f0eff078',
 'value': 5000000000}

    Note that Ethereum always uses integers to represent numeric values, so we got the value in the minimal denomination. Move the decimal point left by decimals found in the contract, 3 in this case. The message reads:

    “Transfer from 0x00b4… to 0x54a2… of 5,000,000 tokens”.

    Querying

    Now you are ready to do some search. You can query the blockchain using json-rpc api which is provided by full nodes like geth or Parity or a service like Infura. Bloom filters allow you to scan the entire blockchain in seconds and find logs matching the specific topic.

    You can also specify search range with fromBlock and toBlock, limit the search to specific contract address and omit some of the topics with null which works like a wildcard. The full specification can be found here.

    Of course, everything described here is already implemented in web3 which allows you to conveniently query the events by name and decodes logs data automatically, but if you care about performance like I do, this approach could save you a lot of time.

    If you learned something new, clap and subscribe to crypto eli5.

    ]]>     ethereum https://banteg.xyz/posts/ethereum-logs/index.html Wed, 03 Jan 2018 20:00:00 GMT