CLASSIC engine: how meters build power

CLASSIC watches what your VM program actually does, not what you call it. A recognized action fills a meter, and the meter drains again when the action stops. Those meters give the knight limited attack, survival, and collection power. The knight must still fight and collect gems to earn EXP.

Attach CLASSIC to the model we already understand

We already have a pilot that selects actions, a VM that runs it, and a world that turns those actions into score. CLASSIC adds a side path. After each tick, it checks the VM's work, records named actions, and changes their meters.

Those meters can give the knight more power, but the knight's basic job stays the same. The pilot must still scan, move, and aim. The world must still defeat enemies and collect gems before EXP increases.

A chain is a named check of one or more VM behaviors. VECTOR, for example, checks a jump through an address loaded from memory. Each chain has one check and one meter. A family groups related chains. When the game sets a power limit, it counts both the active chains and their different families. So eight chains from one family give a lower limit than eight chains from four families.

What CLASSIC does each tick

A headerless upload selects CLASSIC. While the bot runs, the VM records its actions. When the VM stops for that tick, CLASSIC checks those records and changes the chain meters. The world then turns the meters into limited knight power before it handles attacks and gem pickups.

Keep the four jobs apart: the VM records, the host checks, the meter changes, and the world uses the result. One neat instruction trace does not instantly make the knight all-powerful. A successful tick gives only one meter point. The chain must keep passing for many ticks before its meter gives full power, and even then the world limits it.

Follow one VECTOR tick before learning all 41 chains

VECTOR is one CLASSIC chain: a jump whose address came from a memory load. A later section shows how to build that jump. For now, just follow one tick in the order the work happens. Along the way the bot also fills three proof cells. Think of them as a small challenge-and-answer game, not a secret way to edit EXP.

What those meter marks do in a real fight

The halfway mark is easy to miss. VECTOR's factor grows before its meter reaches 256, but the attack boost first reaches the knight at 256. The next figure shows one level-one knight facing one 14-HP spider at three points in that climb.

Assume that VECTOR is the only active chain, the spider is in range, and an attack is ready. The figure shows what one successful hit would do, not a complete match.

Blue knight

Spider · 14 HP

Gem · 3 EXP

FIRST PASS · 1/51212 damage

VECTOR's answer passed, but it does not count toward the attack limit yet. One ordinary hit leaves the spider at 2 HP; the knight still needs another hit.

HALFWAY · 256/51245 damage

VECTOR now counts. Its 1.25 attack factor produces 45 damage, which replaces the ordinary 12. One successful hit can defeat this spider. The full-circle attack is still locked.

FULL · 512/51290 damage · 81px radius

VECTOR's factor reaches 1.5. One successful hit can defeat the spider, and the attack can cover a capped circle around the knight. Range, timing, and enemy position still matter.

Defeating the spider only drops the 3-EXP gem. The score goes up when the knight collects it. The sprites are from the game. Their positions in this diagram are example positions.

Why does the result change so suddenly at 256? The host adds a chain to K only when its meter is at least 256. With VECTOR at 1, K = 0, so the knight keeps its ordinary 12-damage attack.

At 256, K = 1 and VECTOR's attack factor is 1.25, so the damage becomes 180 × (1.25 − 1) = 45. At 512, the same calculation gives 180 × (1.5 − 1) = 90. This calculated damage replaces the ordinary 12 damage; it is not an extra 45 or 90 on top.

A full-circle attack needs an attack factor of at least 1.4. That is why the 256-point version still uses the ordinary aimed shape.

Families describe kinds of machine understanding

The CLASSIC table has 41 chains, and each chain carries two labels. Its family names the kind of VM action the chain checks: jumps, stack work, changed instructions, or bytes with two uses.

Its reward type, which the code calls an axis, names the knight power it can increase: attack, survival, or collection. The family affects the power limit, while the axis selects which power receives the chain's factor.

Take VECTOR. It checks a jump, so it belongs to the control-flow family, and its factor increases attack. PIVOT, by contrast, checks stack movement and increases survival. One label tells you what the bot did; the other tells you which knight power can change.

The map shows every family-and-axis pair that exists in this release. Open a box to see its chains and build steps.

Notice that all eleven control-flow chains increase attack, while stack chains spread across all three powers. The game assigns these axes, so you cannot move VECTOR to another axis by changing its proof cells. And even an accepted chain adds one point only to its own meter. It does not give full power on its first accepted tick.

Sustained participation, not a permanent toggle

Each chain has a meter that keeps its value across ticks. A passing tick adds one point, and a tick without that chain removes three. The meter always stays between 0 and 512, so finding a behavior once cannot give a permanent full-strength bonus.

The meter sets the chain's current factor, and the engine multiplies factors separately for attack, survival, and collection. An absent chain has a factor of 1, which changes nothing. That is why ordinary bots behave the same way while CLASSIC is watching.

The engine also keeps two counts. K counts chains with meters of at least 256, and Fam counts the different families among those chains. The limit uses Keff = min(K, 2 × Fam), so chains from one family cannot raise the limit as far as a varied set can.

For example, eight qualifying chains from one family give Keff = 2, while eight from four families can give Keff = 8. This example starts after the host has accepted the chains; it does not show how to activate them.

Work one meter through time

Once the host has decided which chains passed this tick, the following code updates every meter. Watch how a chain gains or loses points on each tick.

        for i in 0..NCHAINS {
            let delta = if armed[i] { 1 } else { -DECAY };
            self.r[i] = (self.r[i] as i32 + delta).clamp(0, R_FULL as i32) as u16;
        }

        after each CLASSIC tick {
            for (each chain) {
                if (its full check passed) { raise its meter by one }
                else { let its meter fade by DECAY }
                keep the meter between zero and full
            }
        }

DECAY is 3, and R_FULL is 512. Starting from zero, 300 accepted ticks put the meter at 300. Twenty absent ticks then remove 60 points and leave 240, which is below the 256-point count threshold. At 60 ticks per second, those twenty ticks take only one third of a simulated second.

A full meter takes 512 continuously accepted ticks to build from zero, about 8.53 seconds at 60 ticks per second. Going the other way, 85 absent ticks take a full meter down to 257, and the next one leaves 254, below the count threshold. So the bot must keep doing the action, even after the chain has reached full strength once.

As the meter falls, the chain factor shrinks gradually. The family count is different, because it uses a cutoff at 256. Crossing that line can lower the maximum knight power all at once.

Convert a meter into an axis factor

Why this formula? A chain that passes only on some ticks should give less power than one that passes on every tick.

Let r be the meter value and F the factor at a full meter. First calculate tau = r / 512, the fraction of a full meter, and then calculate 1 + (F - 1) * tau.

The code stores these values as Q16.16 fixed-point integers, a format in which 16 bits hold the fractional part:

#[inline]
pub(crate) fn tau_fx(r: u16) -> i32 {
    ((r as i64 * ONE as i64) / R_FULL as i64) as i32
}
#[inline]
pub(crate) fn f_fx(f_ceiling: i32, tau: i32) -> i32 {
    ONE + fxmul(f_ceiling - ONE, tau)
}

fn tau_fx(r) {
    return this meter as a fraction of a full meter
}
fn f_fx(f_ceiling, tau) {
    grow the reward from 1× toward the chain's ceiling
}

The engine multiplies this factor into the chain's assigned axis, but it counts family breadth only once the meter reaches 256. If other chains already allow a boost, this factor can therefore help even before its own meter reaches 256.

Work family breadth through the cap rule

For each chain at 256 or more, the code sets a family bit. It counts those bits to get Fam, then calculates Keff:

            if self.r[i] >= R_HALF {
                k += 1;
                fam_mask |= 1 << CHAIN_FAMILY[i];
            }
        }
        let fam = fam_mask.count_ones();
        let keff = k.min(2 * fam) as i32;

            combine sustained chains {
                count chains whose meters reached at least half
                count the different families represented by those chains
                effective count cannot exceed twice the family count
            }

Eight counted chains in one family give K=8, Fam=1, and Keff=2. Spread the same eight across four families and Keff=8. Same chain count, very different room for power. That is why the CLASSIC apex's eight chains from four families matter.

Three axes with different jobs

Attack, which the code calls throughput, changes damage, attack area, hit passes, and attack timing. Survival changes armor, invulnerability time, and movement. Collection, called harvest in the code, changes gem pickup reach and pull speed. None of the three multiplies EXP directly.

Attack can defeat enemies faster and make more gems, but a dead knight collects none of them. Survival keeps the knight alive, yet it cannot make a missed attack hit. Collection helps only after gems appear. Power has to survive the whole trip from hit to pickup, since the score rises only when the knight collects a gem.

Hard caps are part of the game design

fold_levers combines the factors and applies maximum values. More active chains can raise those maximums, but the effects always stay limited. More chains also increase HEAT, so the knight faces more danger as its power grows.

A1 is this release's balance change. It multiplies CLASSIC's bonus limits by 13/20 but leaves the older VM behavior checks unchanged. CLASSIC still accepts the same chain actions; its maximum power simply sits below the later ABYSS steps.

The score does not necessarily fall by exactly 13/20. A smaller attack circle can miss enemies that used to be in range. Lower damage can require another attack, and a later level increase can delay a heal that saved the run. Each change then affects the ticks after it. That is why the release notes warn against guessing scores between measured points.

Why the factor product is not a score multiplier

Suppose two active attack chains give factors 1.2 and 1.5, for a product of 1.8. The game uses 1.8 to calculate limited combat values; it does not multiply final EXP by 1.8. Hits, deaths, and gem pickups still follow their own rules.

A spider with 14 HP needs two hits when each hit does 12 damage. It still needs two at 13 damage, and only at 14 does one hit suffice. Even then, EXP increases only after a gem pickup. Other thresholds jump in the same way. An attack can suddenly reach another enemy, armor can stop a hit, or one gem can cause a level increase.

So you cannot multiply an old score by the A1 limit to predict a new one. The new limits change where the knight moves and which enemies it hits. Those changes alter later healing and gem supply, so CLASSIC power and pilot movement must be studied together.

Follow one accepted chain into a picked-up gem

Here is a complete payout example. It starts after VECTOR has reached a full meter; a later section shows how to make it pass on each tick. All other chain meters are zero. The knight is level one, and an early 14-HP spider is in attack range. Follow the result from attack power all the way to EXP.

The fold_levers code sets exactly these limited attack values. Notice the two separate checks. First R_thr must reach the level that enables the circle attack, and then Keff and A1 limit the circle radius.

        let disc_cap = a1_cap((120 + 5 * keff).min(160));
        let swings = (1 + keff / 2).min(6);
        let armor_cap = a1_cap((8 + 5 * keff).min(48));
        if k > 0 {
            let committed = r_thr >= THR_DISC_UNLOCK_FX;
            self.hero.disc_committed = committed;
            self.hero.disc_radius = if committed {
                (floor_scale(THR_DISC_COEF, r_thr - ONE) + 60).clamp(1, disc_cap)
            } else {
                0
            };
            self.hero.extra_swings = ((r_thr >> 16) - 1).max(0).min(swings - 1) as u32;
            self.hero.swing_cd_shave = floor_scale(THR_CD_COEF, r_thr - ONE).min(a1_cap(28));
            self.hero.bonus_dmg =
                floor_scale(THR_DMG_COEF, r_thr - ONE).min(a1_cap(DMG_INJECT_CAP));

        turn CLASSIC reward into combat numbers {
            cap the attack disc's size and number of swings
            if throughput is strong enough { enable the attack disc }
            turn more throughput into extra swings, shorter cooldown,
                and bonus damage, each with its own limit

If an attack reaches the spider, 90 damage defeats its 14 HP in one hit. To decide whether it reaches, CLASSIC compares the enemy's distance with the circle radius plus the enemy radius. It therefore cannot hit an enemy elsewhere on the map:

            } else {
                let query = radius + from_int(60);
                let enemies = &self.enemies;
                grid.for_each_near(px, py, query, |i| {
                    let e = enemies[i];
                    if !e.alive {
                        return;
                    }
                    let d = fx_dist(px, py, e.x, e.y);
                    if d <= radius + e.radius {
                        has_reach = true;
                        targets.push(i);
                    }
                });

            when the CLASSIC attack disc swings {
                search enemies near its limited radius
                ignore dead enemies
                if an enemy overlaps the disc { add it to the hit list }
            }
            the disc is a local area attack, not a map-wide hit

The spider's death can create a gem worth 3 EXP. The knight still has to move close enough to collect it. Only then does total EXP rise by 3, which might cause a level change that heals the knight.

If the attack misses, the gem pool is full, or the knight never collects the gem, this example adds zero EXP. VECTOR improves a local fight; only a collected gem increases the score.

Why the instrumentation is separate

While the VM runs the bot, it records selected actions without changing any of the bot's calculations. CLASSIC reads those records only after the VM slice ends. This keeps the VM's instruction behavior separate from the game's reward checks.

For an ordinary compiled bot, CLASSIC's record system should therefore not change normal VM behavior. The repository tests this by comparing recorded runs of selected ordinary bots byte for byte. The claim applies to those tested bots.

The 41 chains, grouped by machine idea

The host checks each chain after the VM's work for a tick. Keep three things separate: what the VM noticed, whether the host accepted the chain, and the meter that remembers it across ticks. In this guide, an “exploit” means a recognized guest-VM action. It never writes directly to host memory or EXP.

Read the hand-off before the catalogue

After the VM runs, it hands CLASSIC a copy of its records. CLASSIC never reads the VM's private record buffers. A new or stopped VM reports false and zero for every record, so it cannot pass a chain by accident. Here is the hand-off:

    pub fn pwn_latches(&self) -> PwnLatches {
        let (aulos_word, aulos_high) = self.pack_sp_peaks();
        PwnLatches {
            computed_jump: self.computed_jump,
            smc_exec: self.smc_exec,
            smc_addr: self.smc_addr,
            smc_orig: self.smc_orig,
            overlap_fired: self.overlap_fired,
            overlap_witness: self.overlap_witness,
            sp_marshal: self.sp_marshal,
            saw_raw_op: self.saw_raw_op,
            exec_off_image: self.exec_off_image,
            cfi_violation: self.cfi_violation,
            ret_gadget_depth: self.ret_gadget_depth,
            dispatch_max: self.dispatch_max,
            jit_dispatch: self.jit_dispatch,

    fn pwn_latches() {
        let (aulos_word, aulos_high) = pack this tick's stack peaks
        return PwnLatches {
            computed jumps, changed code, code overlap,
            stack and host-call observations,
            off-image execution and branch destinations,
            plus the other recorded VM facts

In that copy, computed_jump: self.computed_jump carries the VM's yes-or-no jump record to CLASSIC. CLASSIC simply reads this value; it does not run the bot again to check the jump. The record type starts every field at false or zero:

#[derive(Clone, Copy, Default)]
pub struct PwnLatches {
    pub computed_jump: bool,
    pub smc_exec: bool,
    pub smc_addr: u32,
    pub smc_orig: u8,
    pub overlap_fired: bool,
    pub overlap_witness: u32,

fresh observation record {
    every trick flag starts false
    every count starts zero
    only behavior actually seen by this VM run changes them

You have seen what a full meter can do. That raises the next question: how does a chain earn a single point? The 41 cards below give the checks for each chain, and you do not need to read them in order.

Pick one and ask three questions. What must the bot do? Which values must it write? Can it repeat both steps next tick? A VM record alone is only the first step.

The three locks on a CLASSIC chain

The host adds one chain point only when all three conditions are true in the same tick:

1. Run the VM action named on the card.
2. Put the chain's four-byte magic number at its specified address. Guest memory keeps this value across ticks, so an earlier write can still count.
3. Read this tick's challenge from bot memory, calculate the answer, and write it to the specified address. Last tick's answer will usually fail.

The usual answer is econ_hash(challenge XOR ECHO), where each chain has a fixed ECHO value and the host changes the challenge every tick. A few chains put the answer somewhere else, and their cards explain where.

Try VECTOR as a concrete example. Before the bot runs, the host writes a new word at 0xFE8C. The bot must then jump to a loaded address, put VECT at 0xFE94, and put the new answer at 0xFE90. Change one option at a time below, and the three checks show exactly why the tick passes or fails.

This board starts VECTOR's meter at 4 so that you can see a three-point loss. In a new match the meter starts at zero, and a failed check there leaves it at zero.

The sample challenge words are invented, but the answer calculation and the three host checks follow the real code. The options show the cell values at check time; they do not simulate each memory write.

pub(crate) fn econ_hash(x: u32) -> u32 {
    let mut h = x as i32;
    h ^= h >> 16;
    h = h.wrapping_mul(0x7FEB_352Du32 as i32);
    h ^= h >> 15;
    h = h.wrapping_mul(0x846C_A68Bu32 as i32);
    h ^= h >> 16;
    h as u32
}

fn econ_hash(challenge) {
    mix the challenge's bits several times
    keep each result inside a 32-bit word
    return the answer for this tick
}

The bot does not need the secret KEY_SEED that makes the challenge. It can read the new challenge straight from memory. A fixed answer might pass one test tick and then fail on the next.

Put the proof in a loop alongside movement and aim. When its 10,000 instructions run out, the VM keeps its position and memory and continues on the next game tick. A HALT instead stops it permanently. CLASSIC clears the VM records every tick, so the bot must repeat both the action and the answer.

How to invent VECTOR from the code

During the CTF, the handout did not include the raw assembler or this source code. A player could still compare small compiled bots to learn their instruction bytes. Next, inspect the runner for VM instructions that the compiler never emits. Those findings were enough to build a raw .bin file by hand.

Now that the repository shows the implementation, we can check each step of that reasoning. We will build VECTOR in three passes. First make the VM record a jump, then satisfy the host proof, then repeat both without stopping the bot.

Start with the host's VECTOR check, which requires computed_jump, the VECTOR magic number, and this tick's answer. Then search the VM code for the line that sets computed_jump. Ask one small question: which jump makes that value true?

The answer lies in a taint flag that the VM keeps beside each stack value. A tainted value came from a memory load or a calculation, while a literal PUSH value is clean.

JMP_ABS and CALL_ABS check that flag when they take an address from the stack. The smallest VECTOR action is simple: store an ordinary label address in memory, load it back, and jump to it. The destination can be normal code, because VECTOR checks where the address came from, not where it leads.

Pass 1: make one computed jump

Before you read any bytes, try the two paths below. Both jump to the same address 18. Only the path through LOAD tags the address as computed, so only that path sets computed_jump. Neither path writes the host's magic or answer yet.

Now encode the loaded path as a complete 19-byte image. PUSH is byte 01 followed by a four-byte little-endian number, while STORE, LOAD, JMP_ABS, and HALT take one byte each. The target is offset 18, where HALT sits. Scratch address 0x0204 lies safely outside this image, and the longer loop later uses 0x0200 for its hash value.

Write these bytes to a raw .bin file. In a VM with record output, check that execution reaches offset 18 with computed_jump = true. If it does not, correct the bytes or the stack order before you add the answer calculation.

The released grader does not show this internal flag, so a player would compare program variants through the full host check instead. Note that this one-tick image does not earn VECTOR: it has no magic or answer, and HALT stops the bot.

    pub const PUSH_ZERO: u8 = 0x03;
    pub const POP: u8 = 0x04;
    pub const LOAD_REL: u8 = 0x05;
    pub const STORE_REL: u8 = 0x06;
    pub const LOAD: u8 = 0x07;
    pub const STORE: u8 = 0x08;
    pub const JMP_REL: u8 = 0x10;
    pub const JMP_ABS: u8 = 0x11;
    pub const CALL_REL: u8 = 0x12;
    pub const CALL_ABS: u8 = 0x13;
    pub const SKIP_IF: u8 = 0x14;
    pub const RET: u8 = 0x15;
    pub const SYSCALL: u8 = 0x20;
    pub const GATECALL: u8 = 0x21;
    pub const ADD: u8 = 0x30;
    pub const SUB: u8 = 0x31;
    pub const MUL: u8 = 0x32;
    pub const DIV_U: u8 = 0x33;
    pub const REM_U: u8 = 0x34;

    instruction bytes used by CLASSIC examples {
        PUSH adds a number to the stack
        LOAD and STORE touch VM memory
        JMP_ABS takes a destination from the stack
        arithmetic instructions calculate new values
        0x21 is GATECALL only in ABYSS
    }

    fn push_imm(code: &mut Vec<u8>, v: u32) {
        code.push(op::PUSH);
        code.extend_from_slice(&v.to_le_bytes());
    }

    fn push_imm(code, v) {
        append the PUSH instruction byte
        append v as four little-endian bytes
    }

                op::LOAD => {
                    let a = self.pop();
                    self.note_arena_load(a);
                    self.note_read_own_code(a);
                    let v = self.mem.load_u32(a);
                    self.push_tagged(v, true);
                }
                op::STORE => {
                    let a = self.pop();
                    let v = self.pop();
                    self.note_arena_store(a);
                    self.note_code_store(a, v);
                    self.mem.store_u32(a, v);

                when LOAD runs {
                    read a value from VM memory
                    mark the value as computed
                }
                when STORE runs {
                    write a value into VM memory

                op::JMP_ABS => {
                    let t = self.pop();
                    let s = ((self.sp & ADDR_MASK) >> 2) as usize;
                    let tainted = self.taint[s >> 3] & (1u8 << (s & 7)) != 0;
                    if tainted {
                        self.computed_jump = true;
                        if self.is_interior_addr(t) {
                            self.note_hydra(ip_op, t);
                        }
                    }
                    self.note_indirect_target(ip_op, t, false);
                    self.clear_jit();
                    self.ip = t;
                }

                when JMP_ABS runs {
                    take the destination from the stack
                    if (it came from a load or calculation) {
                        record a computed jump
                    }
                    continue at that destination
                }

The two lines to compare are push_tagged(v, true) in LOAD and if tainted { self.computed_jump = true; } in JMP_ABS. First LOAD marks the stack value, and later the jump reads that mark. Together, those two actions are the whole VECTOR VM record.

The repository also has a one-tick test of the complete check. It writes the magic, a calculated answer, and a HALT address in scratch memory. That test uses 0x0200 for scratch. Our longer loop needs 0x0200 for its hash value, so it keeps the jump address at 0x0204.

The choice of scratch address does not set the taint flag; the loaded jump does. The VM takes the tagged jump, the host accepts the test, and r[0] becomes 1.

Read this test as the smallest complete example, not a scoring bot. The test can call the host's private challenge function and then stop. A competitor bot cannot do either: it must read the live challenge and keep running.

    fn build_vector_poc(tick: u32) -> Vec<u8> {
        const SCRATCH: u32 = 0x0200;
        const HALT_ADDR: u32 = 40;
        let mut code = Vec::new();
        push_imm(&mut code, VEC_MAGIC);
        push_imm(&mut code, VEC_MAGIC_ADDR);
        code.push(op::STORE);
        push_imm(&mut code, vec_response(vec_challenge(tick)));
        push_imm(&mut code, VEC_RESP_ADDR);
        code.push(op::STORE);
        push_imm(&mut code, HALT_ADDR);
        push_imm(&mut code, SCRATCH);
        code.push(op::STORE);
        push_imm(&mut code, SCRATCH);
        code.push(op::LOAD);
        code.push(op::JMP_ABS);
        assert_eq!(
            code.len() as u32,
            HALT_ADDR,
            "HALT must land at the precomputed target"
        );
        code.push(op::HALT);
        code
    }

    fn build_vector_poc(tick) {
        let code = empty byte list
        append: write VECT magic to its proof cell
        append: write the correct answer for tick to its proof cell
        append: save the HALT address in scratch memory
        append: load that address back, then JMP_ABS through it
        check HALT really begins at the planned address
        append HALT; return code
    }

    #[test]
    fn vector_full_poc_arms_the_meter_through_the_vm() {
        let mut w = World::new(0x1234_5678, true);
        w.begin_tick();
        assert_eq!(
            w.tick, 1,
            "begin_tick sets tick to 1, matching the PoC's response"
        );
        let code = build_vector_poc(w.tick);
        let mut vm = Vm::new(&code);
        w.arm_vec_challenge(&mut vm.mem);
        vm.run_tick(&mut w);
        let l = vm.pwn_latches();
        w.apply_exploit_staging(&mut vm.mem, l);
        assert!(
            vm.computed_jump,
            "the LOAD-tainted JMP_ABS target trips the computed-jump detector"
        );
        assert_eq!(
            w.r[0], 1,
            "the raw-bytecode VECTOR PoC arms the VECTOR sustain meter +1 end-to-end"
        );
        assert_eq!(
            w.econ_k, 0,
            "a single armed tick is not yet a sustained chain"
        );

    fn vector_full_poc_arms_the_meter_through_the_vm() {
        let world = a new test match; begin its first tick
        let code = build_vector_poc(world.tick)
        let vm = a VM loaded with code
        write this tick's challenge; run one VM tick
        give the VM's recorded actions to the CLASSIC scorer
        check the jump was marked computed
        check VECTOR's meter rose by one
        check the short one-tick test has not unlocked attack power

In a live run, the host writes VECTOR's new challenge at 0xFE8C. Your bot writes its answer at 0xFE90 and the VECT magic (0x56454354) at 0xFE94. The ECHO value (0x56656331) belongs in the calculation, not in a proof cell. If you swap ECHO and magic, the host rejects VECTOR even when the jump itself passes.

Pass 2: make the host accept the jump

Keep the jump through the loaded scratch value, and add the proof around it. Read the current word at 0xFE8C, XOR it with 0x56656331, and run econ_hash on the result. Then store that answer at 0xFE90 and store 0x56454354 at 0xFE94.

The host checks all three conditions after the VM slice ends. You can write the magic before or after the jump. All three conditions just have to be true when the host checks this tick.

An indirect jump alone is therefore only a candidate. The host accepts VECTOR, and adds a meter point, only when the VM record and the memory proof agree.

pub const VEC_CHAL_ADDR: u32 = 0xFE8C;
pub const VEC_RESP_ADDR: u32 = 0xFE90;
pub const VEC_MAGIC_ADDR: u32 = 0xFE94;
pub const VEC_MAGIC: u32 = 0x5645_4354;
pub const VEC_ECHO: u32 = 0x5665_6331;
pub const VEC_DMG_CAP: i32 = 40;
pub const K_VECTOR: u64 = 0x5645_4354_0000_0005;

VECTOR's guest-memory slots {
    challenge lives at 0xFE8C
    write this tick's answer at 0xFE90
    write the VECT magic word at 0xFE94
}
the scorer also sets VECTOR's damage cap

Before the long assembly block, here is one worked answer for the invented challenge 0x12345678. The bot first calculates 0x12345678 XOR 0x56656331 = 0x44513549 and then runs the five hash steps below. The final word, 0x535FD5C0, goes into 0xFE90 for this tick only, because the host writes a new challenge next tick.

Signed right-shift keeps the sign bit as it moves bits right. Keeping 32 bits means that overflow wraps instead of making a larger number. Your bot must follow both rules exactly, or its answer will not match the host's.

Pass 3: turn the one-shot proof into a live loop

The assembly below repeats four tasks. It writes the magic, reads and answers the current challenge, then stores and reloads the loop address. Finally it jumps through that loaded address. Each repeated push 0x0200; ld pair just reads the current hash value back from scratch memory.

This is a VECTOR proof core, not a complete scoring bot. A full pilot must also scan, aim, and move. If your larger image uses 0x0200 for code, pick another safe scratch address.

loop:
    push 0x56454354
    push 0xFE94
    st
    push 0xFE8C
    ld
    push 0x56656331
    xor
    push 0x0200
    st
    push 0x0200
    ld
    push 0x0200
    ld
    push 16
    shrs
    xor
    push 0x0200
    st
    push 0x0200
    ld
    push 0x7FEB352D
    mul
    push 0x0200
    st
    push 0x0200
    ld
    push 0x0200
    ld
    push 15
    shrs
    xor
    push 0x0200
    st
    push 0x0200
    ld
    push 0x846CA68B
    mul
    push 0x0200
    st
    push 0x0200
    ld
    push 0x0200
    ld
    push 16
    shrs
    xor
    push 0xFE90
    st
    push loop
    push 0x0204
    st
    push 0x0204
    ld
    jmpa

loop {
    write VECTOR's magic word
    read this tick's challenge
    calculate and store its answer
    load the loop address from memory
    jump through that loaded address
}

The last ld is the key difference from a plain push loop; jmpa. Notice also that the live loop has no HALT. At the next tick, the VM resumes at its current instruction address, possibly halfway through the hash. For that reason, keep the proof cycle short enough to finish at least once in every 10,000-instruction slice.

Watch r[0] for several ticks. A steady +1 means the loop both triggers the behavior and writes the proof. A −3 tick means one part went missing. Once this works, you can add other chains to the same loop. Each one still needs its own VM behavior, magic value, and current challenge.

    fn vector_armed(&self, mem: &Mem, l: PwnLatches) -> bool {
        if !l.computed_jump || mem.load_u32(VEC_MAGIC_ADDR) != VEC_MAGIC {
            return false;
        }
        let r = mem.load_u32(VEC_RESP_ADDR);
        r != 0 && r == vec_response(vec_challenge(self.tick))
    }

    fn vector_armed(self, mem, l) {
        if (no computed jump or VECT magic is wrong) { return false }
        let r = read VECTOR's answer cell
        return r is nonzero and matches this tick's challenge
    }

Use the same build method for the other 40

Each card gives the VM action and memory proof for one chain. To build one yourself, follow the same passes as VECTOR:

1. Read the host check. Find every && condition in the embedded code. Note the magic and response cells, plus any address or count the check compares.
2. Find what sets each VM note. Search the VM code for the note's field name to see which instruction or event sets it. Typical causes are LOAD, jumps, STORE, fetches, and stack moves. A value that merely looks right does not set the note.
3. Build a small one-shot image. Trigger only the required VM note first. If the check needs a count, use distinct addresses or destinations and confirm the exact threshold. Make sure the run reaches the host check.
4. Write the current proof. Use this tick's challenge, answer, magic, and any witness cells. Most chains use the usual hash rule. A few put the answer in stack state or a saved instruction address.
5. Repeat every tick. Add the behavior and proof to the live pilot loop, then test several ticks. One accepted tick adds only 1 to a meter that can reach 512.

The cards spell out the actions and numbers, so you do not have to invent them from the chain names. For a complex chain, build and test its smaller parts first. Make DISPATCH work before ROSETTA, for example, and PACKER before BASILISK. Each card also includes the exact host check, so you can compare your bot with the code.

If 41 chains feel like a lot, take a short tour of four first. VECTOR asks where a jump address came from, and NULLARBOR asks what unsigned arithmetic did at an edge case. PHOENIX asks whether changed code actually ran. JANUS asks whether a byte served first as data and later as an instruction.

All four use the same three-part proof; only the required VM behavior changes.

Control flow: where execution goes

For each jump, the VM can answer four separate questions, and different chains check different answers. Where did the target value come from, and which jump instruction used it? Did the target lie outside the uploaded program, and was it the start of an original instruction?

    pub computed_jump: bool,
    pub smc_exec: bool,
    pub smc_addr: u32,
    pub smc_orig: u8,
    pub overlap_fired: bool,
    pub overlap_witness: u32,
    pub sp_marshal: u32,
    pub saw_raw_op: bool,
    pub exec_off_image: bool,
    pub cfi_violation: bool,
    pub ret_gadget_depth: u32,
    pub dispatch_max: u32,
    pub jit_dispatch: bool,
    pub sp_lo: u32,
    pub pivot_depth: u32,

    VM observations for control flow {
        record computed jumps, changed-code execution, and overlap
        record jumps beyond the original upload
        record jumps into unexpected instruction positions
        count return-route depth and dispatch choices
        keep these as separate facts for separate chains
    }

Three tiny jumps, three different VM notes

These are three separate one-tick test programs, not three steps to paste into one bot. Each answers a different question about a jump. VECTOR checks where the jump target came from. GADGET checks whether the target was an original instruction start. TRAMPOLINE checks whether the VM actually fetched an instruction beyond the uploaded image, and one jump can set more than one of these notes.

VECTOR probe: Save the ordinary continuation address 18 in scratch memory, LOAD it, and then use JMP_ABS. Address 18 starts a valid instruction in this image, so the destination itself is unremarkable. What matters is that the VM marks the loaded value as computed and therefore sets computed_jump.

GADGET probe: The repository's VM test starts with PUSH 0x0000FF00, whose five bytes are 01 00 FF 00 00: opcode 01 at offset 0, then four value bytes. The original decoder therefore sees one instruction starting at 0. The byte FF at offset 2 is just part of its value.

The test then runs PUSH 2; JMP_ABS, and the VM reads that FF at offset 2 as HALT. Offset 2 was not an original instruction start, so the branch-target check sets cfi_violation, even though offset 2 is still inside the uploaded image:

        let mut a = Asm::new();
        a.push(0x0000_FF00);
        a.push(2);
        a.op(op::JMP_ABS);
        let code = a.finish();
        let mut vm = Vm::new(&code);
        vm.run_tick(&mut NopHost);

        build a tiny GADGET test {
            hide a HALT byte inside the value of a PUSH instruction
            push address 2, the location of that hidden byte
            jump to address 2 so the VM reads it as an instruction
        }

    fn note_indirect_target(&mut self, site: u32, t: u32, is_call: bool) {
        if t >= self.code_end || !self.is_instr_start(t) {
            self.cfi_violation = true;
        }

    fn note_indirect_target(site, target, is_call) {
        if (target is beyond the upload
            or target was not an original instruction start) {
            record cfi_violation for the GADGET check
        }

The direct PUSH 2 target does not count as computed for VECTOR. Because it also stays inside the image, it does not trigger TRAMPOLINE either. The interior fetch can, however, set byte-overlap notes, so “GADGET happened” does not mean that only GADGET happened.

TRAMPOLINE probe: Another VM test writes FF to guest address 0xD000, pushes 0xD000, and jumps there. The uploaded image ends well before that address. Because the jump target is outside the image, the GADGET boundary check also records cfi_violation. Then, when the VM fetches the FF at 0xD000, it sets exec_off_image for TRAMPOLINE. Writing the byte without fetching it would not set that note:

        let mut a = Asm::new();
        a.push(0xFF);
        a.push(0xD000);
        a.op(op::STORE);
        a.push(0xD000);
        a.op(op::JMP_ABS);
        let code = a.finish();
        let mut vm = Vm::new(&code);
        vm.run_tick(&mut NopHost);

        build a tiny TRAMPOLINE test {
            store a HALT byte in guest memory at 0xD000
            jump to that address, beyond the uploaded program
            run the VM until it reads that byte as an instruction
        }

                if (a as u32) >= self.code_end {
                    self.exec_off_image = true;
                }

                whenever the VM reads its next instruction {
                    if (that address is beyond the uploaded program) {
                        record off-image execution for TRAMPOLINE
                    }
                }

These tests end with HALT and never write a chain's magic value or current answer. They show how VM notes arise, not how to score over hundreds of ticks. To earn meter marks, add the chain's proof cells, then repeat the behavior in a live loop.

DISPATCH asks a fourth question: how many distinct destinations did one jump instruction reach in the same tick? Its card below builds eight stubs that all return to one shared jump instruction.

    fn vector_armed(&self, mem: &Mem, l: PwnLatches) -> bool {
        if !l.computed_jump || mem.load_u32(VEC_MAGIC_ADDR) != VEC_MAGIC {
            return false;
        }
        let r = mem.load_u32(VEC_RESP_ADDR);
        r != 0 && r == vec_response(vec_challenge(self.tick))
    }

    fn vector_armed(self, mem, l) {
        if (no computed jump or VECT magic is wrong) { return false }
        let r = read VECTOR's answer cell
        return r is nonzero and matches this tick's challenge
    }

    fn crown_armed(&self, mem: &Mem, l: PwnLatches) -> bool {
        if !(l.smc_exec
            && l.overlap_fired
            && l.computed_jump
            && l.sp_marshal >= SP_PIVOT_ARENA_LO
            && l.sp_marshal < VM_MEM_SIZE as u32
            && l.saw_raw_op)
            || mem.load_u32(CAP_MAGIC_ADDR) != CAP_MAGIC
        {
            return false;
        }
        let r = mem.load_u32(CAP_RESP_ADDR);
        r != 0 && r == cap_response(cap_challenge(self.tick))
    }

    fn crown_armed(self, mem, l) {
        if (changed code did not run, no overlapping decode,
            no computed jump, no high call frame, no raw opcode,
            or CROWN magic is wrong) { return false }
        let r = read CROWN's answer cell
        return r is nonzero and matches this tick's challenge
    }

    fn crown_negatives_leave_the_meter_idle() {
        let droppers: [(&str, fn(&mut PwnLatches)); 5] = [
            ("smc_exec", |l| l.smc_exec = false),
            ("overlap_fired", |l| l.overlap_fired = false),
            ("computed_jump", |l| l.computed_jump = false),
            ("sp_marshal", |l| l.sp_marshal = SP_PIVOT_ARENA_LO - 1),
            ("saw_raw_op", |l| l.saw_raw_op = false),
        ];
        for (name, drop) in droppers {
            let (mut w, mut mem) = armed();
            mem.store_u32(CAP_MAGIC_ADDR, CAP_MAGIC);
            mem.store_u32(CAP_RESP_ADDR, cap_response(cap_challenge(w.tick)));
            let mut l = crown_latches();
            drop(&mut l);
            w.apply_exploit_staging(&mut mem, l);
            assert_eq!(w.r[4], 0, "CROWN missing {name} ⇒ never armed");
        }

    fn crown_negatives_leave_the_meter_idle() {
        let droppers = [remove each of the five VM notes, one at a time]
        for (name, drop) in droppers {
            let (mut w, mut mem) = a fresh host and memory
            put valid CROWN magic in memory
            put this tick's correct answer in memory
            let mut l = all five CROWN notes present
            drop(&mut l)
            let host check the altered notes
            assert CROWN's meter is still zero
        }

    fn trampoline_armed(&self, mem: &Mem, l: PwnLatches) -> bool {
        if !l.exec_off_image || mem.load_u32(TRAMP_MAGIC_ADDR) != TRAMP_MAGIC {
            return false;
        }
        let r = mem.load_u32(TRAMP_RESP_ADDR);
        r != 0 && r == tramp_response(tramp_challenge(self.tick))
    }

    fn trampoline_armed(self, mem, l) {
        if (no instruction ran beyond the upload or magic is wrong) {
            return false
        }
        let r = read TRAMPOLINE's answer cell
        return r is nonzero and matches this tick's challenge
    }

    fn gadget_armed(&self, mem: &Mem, l: PwnLatches) -> bool {
        if !l.cfi_violation || mem.load_u32(GDGT_MAGIC_ADDR) != GDGT_MAGIC {
            return false;
        }
        let r = mem.load_u32(GDGT_RESP_ADDR);
        r != 0 && r == gdgt_response(gdgt_challenge(self.tick))
    }

    fn gadget_armed(self, mem, l) {
        if (no jump broke the original instruction map or magic is wrong) {
            return false
        }
        let r = read GADGET's answer cell
        return r is nonzero and matches this tick's challenge
    }

    fn dispatch_armed(&self, mem: &Mem, l: PwnLatches) -> bool {
        if l.dispatch_max < 8 || mem.load_u32(DISP_MAGIC_ADDR) != DISP_MAGIC {
            return false;
        }
        let r = mem.load_u32(DISP_RESP_ADDR);
        r != 0 && r == disp_response(disp_challenge(self.tick))
    }

    fn dispatch_armed(self, mem, l) {
        if (one jump site reached fewer than eight targets or magic is wrong) {
            return false
        }
        let r = read DISPATCH's answer cell
        return r is nonzero and matches this tick's challenge
    }

    fn rampart_armed(&self, mem: &Mem, l: PwnLatches) -> bool {
        if l.ret_gadget_depth < 8 || mem.load_u32(RMPT_MAGIC_ADDR) != RMPT_MAGIC {
            return false;
        }
        let r = mem.load_u32(RMPT_RESP_ADDR);
        r != 0 && r == rmpt_response(rmpt_challenge(self.tick))
    }

    fn rampart_armed(self, mem, l) {
        if (fewer than eight off-image return targets or magic is wrong) {
            return false
        }
        let r = read RAMPART's answer cell
        return r is nonzero and matches this tick's challenge
    }

    fn gantry_armed(&self, mem: &Mem, l: PwnLatches) -> bool {
        if !l.jit_dispatch || mem.load_u32(GNTR_MAGIC_ADDR) != GNTR_MAGIC {
            return false;
        }
        let r = mem.load_u32(GNTR_RESP_ADDR);
        r != 0 && r == gntr_response(gntr_challenge(self.tick))
    }

    fn gantry_armed(self, mem, l) {
        if (the shared call site did not reach four off-image targets
            or magic is wrong) { return false }
        let r = read GANTRY's answer cell
        return r is nonzero and matches this tick's challenge
    }

    fn wyrm_armed(&self, mem: &Mem, l: PwnLatches) -> bool {
        let sp_hi_in_arena = l.pivot_depth >= (SP_PIVOT_ARENA_LO - SP_INIT)
            && l.pivot_depth < (VM_MEM_SIZE as u32 - SP_INIT);
        if !(l.ret_gadget_depth >= WYRM_RET_MIN
            && l.dispatch_max >= WYRM_DISPATCH_MIN
            && l.overlap_density >= WYRM_OVERLAP_MIN
            && (l.marshal_alias || l.raw_argc_wide)
            && sp_hi_in_arena)
            || mem.load_u32(WYRM_MAGIC_ADDR) != WYRM_MAGIC
        {
            return false;
        }
        let r = mem.load_u32(WYRM_RESP_ADDR);
        r != 0 && r == wyrm_response(wyrm_challenge(self.tick))
    }

    fn wyrm_armed(self, mem, l) {
        let sp_hi_in_arena = stack's high point is inside 0xD000..0xFFFF
        if (returns too shallow, too few dispatch targets or overlaps,
            no unusual call frame, stack not in arena, or magic wrong) {
            return false
        }
        let r = read WYRM's answer cell
        return r is nonzero and matches this tick's challenge
    }

    fn rosetta_armed(&self, mem: &Mem, l: PwnLatches) -> bool {
        if !(l.dispatch_max >= ROSETTA_DISPATCH_MIN && l.computed_jump)
            || mem.load_u32(ROSETTA_MAGIC_ADDR) != ROSETTA_MAGIC
        {
            return false;
        }
        let r = mem.load_u32(ROSETTA_RESP_ADDR);
        r != 0 && r == rosetta_response(rosetta_challenge(self.tick))
    }

    fn rosetta_armed(self, mem, l) {
        if (fewer than sixteen dispatch targets, no computed jump,
            or ROSETTA magic is wrong) { return false }
        let r = read ROSETTA's answer cell
        return r is nonzero and matches this tick's challenge
    }

    fn metronome_armed(&self, mem: &Mem, l: PwnLatches) -> bool {
        if !l.exec_off_image || mem.load_u32(METRO_MAGIC_ADDR) != METRO_MAGIC {
            return false;
        }
        l.resume_ip != 0 && l.resume_ip == metro_park(metro_challenge(self.tick))
    }

    fn metronome_armed(self, mem, l) {
        if (no off-image execution or METRONOME magic is wrong) {
            return false
        }
        return saved resume address is nonzero and equals
            the address predicted by this tick's challenge
    }

    fn hydra_armed(&self, mem: &Mem, l: PwnLatches) -> bool {
        if l.hydra_phase < HYDRA_PHASE_MIN || mem.load_u32(HYDRA_MAGIC_ADDR) != HYDRA_MAGIC {
            return false;
        }
        let r = mem.load_u32(HYDRA_RESP_ADDR);
        r != 0 && r == hydra_response(hydra_challenge(self.tick))
    }

    fn hydra_armed(self, mem, l) {
        if (too few interior re-entry positions or magic is wrong) {
            return false
        }
        let r = read HYDRA's answer cell
        return r is nonzero and matches this tick's challenge
    }

Stack: which storage role a word occupies

The VM uses one flat memory array for operands, call frames, host-call arguments, and code. Its stack notes record where a word sat and how it was used, not merely that a number was large.

    pub arena_frames: u32,
    pub frames_verified: u32,
    pub marshal_alias: bool,
    pub raw_argc_wide: bool,
    pub syscall_reentrant: bool,
    pub divzero_u: bool,
    pub shift_annihilate_u: bool,
    pub signedness_split: bool,
    pub split_count: u32,
    pub wrap_carry: bool,
    pub code_patched: bool,

    VM observations for stack and arithmetic {
        count frames placed in the upper arena
        count frame positions written and later read
        note aliased host-call frames and wide argument counts
        note divide-by-zero, oversized shifts, and signed/unsigned splits
        keep these facts for their matching CLASSIC chains
    }

Worked machine trace: one array, several roles

Think about a function call that stores a local value and makes a host request. Within one 64 KiB array, arithmetic values, a return frame, and host-call arguments each take a different role.

A deep stack, several related call frames, and host-call arguments overlapping other data are three different behaviors. The CLASSIC chain named ABYSS is about the stack, and it is separate from the ABYSS engine.

    fn pivot_armed(&self, mem: &Mem, l: PwnLatches) -> bool {
        if !(l.sp_marshal >= SP_PIVOT_ARENA_LO && l.sp_marshal < VM_MEM_SIZE as u32)
            || !l.saw_raw_op
            || mem.load_u32(PIV_MAGIC_ADDR) != PIV_MAGIC
        {
            return false;
        }
        let r = mem.load_u32(PIV_RESP_ADDR);
        r != 0 && r == piv_response(piv_challenge(self.tick))
    }

    fn pivot_armed(self, mem, l) {
        if (host-call frame not in 0xD000..0xFFFF,
            no raw opcode, or PIVOT magic wrong) { return false }
        let r = read PIVOT's answer cell
        return r is nonzero and matches this tick's challenge
    }

    fn abyss_armed(&self, mem: &Mem, l: PwnLatches) -> bool {
        if (l.sp_lo as i32) >= 0 || mem.load_u32(ABYS_MAGIC_ADDR) != ABYS_MAGIC {
            return false;
        }
        let r = mem.load_u32(ABYS_RESP_ADDR);
        r != 0 && r == abys_response(abys_challenge(self.tick))
    }

    fn abyss_armed(self, mem, l) {
        if (stack never went below its start or ABYSS-chain magic wrong) {
            return false
        }
        let r = read this CLASSIC chain's answer cell
        return r is nonzero and matches this tick's challenge
    }

    fn plumb_armed(&self, mem: &Mem, l: PwnLatches) -> bool {
        if l.pivot_depth < PLUMB_DEPTH_MIN || mem.load_u32(PLMB_MAGIC_ADDR) != PLMB_MAGIC {
            return false;
        }
        let r = mem.load_u32(PLMB_RESP_ADDR);
        r != 0 && r == plmb_response(plmb_challenge(self.tick))
    }

    fn plumb_armed(self, mem, l) {
        if (stack did not climb at least 0x1000 or PLUMB magic wrong) {
            return false
        }
        let r = read PLUMB's answer cell
        return r is nonzero and matches this tick's challenge
    }

    fn locksmith_armed(&self, mem: &Mem, l: PwnLatches) -> bool {
        if !l.marshal_alias || mem.load_u32(LOCK_MAGIC_ADDR) != LOCK_MAGIC {
            return false;
        }
        let r = mem.load_u32(LOCK_RESP_ADDR);
        r != 0 && r == lock_response(lock_challenge(self.tick))
    }

    fn locksmith_armed(mem, latches) {
        if (no unusual host-call frame or wrong magic word) { return false }
        read the stored answer
        return answer is nonzero and matches this tick's challenge
    }

    fn mirage_armed(&self, mem: &Mem, l: PwnLatches) -> bool {
        if !l.raw_argc_wide || mem.load_u32(MIRG_MAGIC_ADDR) != MIRG_MAGIC {
            return false;
        }
        let r = mem.load_u32(MIRG_RESP_ADDR);
        r != 0 && r == mirg_response(mirg_challenge(self.tick))
    }

    fn mirage_armed(self, mem, l) {
        if (no raw host-call count above eight or MIRAGE magic wrong) {
            return false
        }
        let r = read MIRAGE's answer cell
        return r is nonzero and matches this tick's challenge
    }

    fn ossuary_armed(&self, mem: &Mem, l: PwnLatches) -> bool {
        if l.arena_frames < ARENA_FRAMES_MIN || mem.load_u32(OSSU_MAGIC_ADDR) != OSSU_MAGIC {
            return false;
        }
        let r = mem.load_u32(OSSU_RESP_ADDR);
        r != 0 && r == ossu_response(ossu_challenge(self.tick))
    }

    fn ossuary_armed(self, mem, l) {
        if (fewer than four upper-arena call frames or magic wrong) {
            return false
        }
        let r = read OSSUARY's answer cell
        return r is nonzero and matches this tick's challenge
    }

    fn sextant_armed(&self, mem: &Mem, l: PwnLatches) -> bool {
        if l.frames_verified < FRAMES_VERIFIED_MIN || mem.load_u32(SEXT_MAGIC_ADDR) != SEXT_MAGIC {
            return false;
        }
        let r = mem.load_u32(SEXT_RESP_ADDR);
        r != 0 && r == sext_response(sext_challenge(self.tick))
    }

    fn sextant_armed(self, mem, l) {
        if (fewer than eight arena slots were both written and read
            or SEXTANT magic wrong) { return false }
        let r = read SEXTANT's answer cell
        return r is nonzero and matches this tick's challenge
    }

    fn catenary_armed(&self, mem: &Mem, l: PwnLatches) -> bool {
        if !l.syscall_reentrant || mem.load_u32(CATN_MAGIC_ADDR) != CATN_MAGIC {
            return false;
        }
        let r = mem.load_u32(CATN_RESP_ADDR);
        r != 0 && r == catn_response(catn_challenge(self.tick))
    }

    fn catenary_armed(self, mem, l) {
        if (no host call while a prior return was still live
            or CATENARY magic wrong) { return false }
        let r = read CATENARY's answer cell
        return r is nonzero and matches this tick's challenge
    }

    fn nullarbor_armed(&self, mem: &Mem, l: PwnLatches) -> bool {
        if !l.divzero_u || mem.load_u32(NULL_MAGIC_ADDR) != NULL_MAGIC {
            return false;
        }
        let r = mem.load_u32(NULL_RESP_ADDR);
        r != 0 && r == null_response(null_challenge(self.tick))
    }

    fn nullarbor_armed(self, mem, l) {
        if (no unsigned divide/remainder by zero or NULLARBOR magic wrong) {
            return false
        }
        let r = read NULLARBOR's answer cell
        return r is nonzero and matches this tick's challenge
    }

                0x30..=0x45 => {
                    let b = self.pop();
                    let a = self.pop();
                    self.note_alu_faults(opcode, a, b);
                    self.push_tagged(alu_bin(opcode, a, b), true);
                }

                0x30..=0x45 => {
                    let b = pop the top word;
                    let a = pop the next word;
                    note any special case this operation hit;
                    push the calculated result;
                }

            op::DIV_U | op::REM_U => {
                if b == 0 {
                    self.divzero_u = true;
                }
            }

            op::DIV_U | op::REM_U => {
                if b == 0 {
                    self.divzero_u = true;
                }
            }

        op::DIV_U => {
            if b == 0 {
                0
            } else {
                a / b
            }
        }

        op::DIV_U => {
            if b == 0 {
                0
            } else {
                a divided by b
            }
        }

    fn tithonus_armed(&self, mem: &Mem, l: PwnLatches) -> bool {
        if !l.shift_annihilate_u || mem.load_u32(TITH_MAGIC_ADDR) != TITH_MAGIC {
            return false;
        }
        let r = mem.load_u32(TITH_RESP_ADDR);
        r != 0 && r == tith_response(tith_challenge(self.tick))
    }

    fn tithonus_armed(self, mem, l) {
        if (no unsigned right shift by 32 or more, or magic wrong) {
            return false
        }
        let r = read TITHONUS's answer cell
        return r is nonzero and matches this tick's challenge
    }

    fn amberhorn_armed(&self, mem: &Mem, l: PwnLatches) -> bool {
        if !(l.signedness_split || l.wrap_carry) || mem.load_u32(AMBR_MAGIC_ADDR) != AMBR_MAGIC {
            return false;
        }
        let r = mem.load_u32(AMBR_RESP_ADDR);
        r != 0 && r == ambr_response(ambr_challenge(self.tick))
    }

    fn amberhorn_armed(self, mem, l) {
        if (neither signedness split nor wrap-carry happened,
            or AMBERHORN magic wrong) { return false }
        let r = read AMBERHORN's answer cell
        return r is nonzero and matches this tick's challenge
    }

    fn styx_armed(&self, mem: &Mem, l: PwnLatches) -> bool {
        let sp_hi = l.pivot_depth as i64 + SP_INIT as i64;
        let sp_lo_abs = SP_INIT as i64 + (l.sp_lo as i32) as i64;
        let span = sp_hi - sp_lo_abs;
        if !((l.sp_lo as i32) < 0
            && l.pivot_depth >= (SP_PIVOT_ARENA_LO - SP_INIT)
            && span >= STYX_SPAN_MIN
            && l.arena_frames >= ARENA_FRAMES_MIN
            && l.frames_verified >= FRAMES_VERIFIED_MIN)
            || mem.load_u32(STYX_MAGIC_ADDR) != STYX_MAGIC
        {
            return false;
        }
        let r = mem.load_u32(STYX_RESP_ADDR);
        r != 0 && r == styx_response(styx_challenge(self.tick))
    }

    fn styx_armed(self, mem, l) {
        let sp_hi = highest stack point
        let sp_lo_abs = lowest stack point
        let span = sp_hi minus sp_lo_abs
        if (no underflow, no high pivot, span too short,
            too few arena call frames or verified frame slots,
            or STYX magic wrong) { return false }
        let r = read STYX's answer cell
        return r is nonzero and matches this tick's challenge
    }

    fn jormungand_armed(&self, mem: &Mem, l: PwnLatches) -> bool {
        if !(l.divzero_u
            && l.shift_annihilate_u
            && l.signedness_split
            && l.wrap_carry
            && l.saw_raw_op)
            || mem.load_u32(JORM_MAGIC_ADDR) != JORM_MAGIC
        {
            return false;
        }
        let r = mem.load_u32(JORM_RESP_ADDR);
        r != 0 && r == jorm_response(jorm_challenge(self.tick))
    }

    fn jormungand_armed(self, mem, l) {
        if (no unsigned divide-by-zero, no oversized shift,
            no signedness split, no wrap-carry, no raw opcode,
            or JORMUNGAND magic wrong) { return false }
        let r = read JORMUNGAND's answer cell
        return r is nonzero and matches this tick's challenge
    }

    fn aulos_armed(&self, mem: &Mem, l: PwnLatches) -> bool {
        if !l.aulos_high || mem.load_u32(AULOS_MAGIC_ADDR) != AULOS_MAGIC {
            return false;
        }
        l.aulos_word == aulos_response(aulos_challenge(self.tick))
    }

    fn aulos_armed(self, mem, l) {
        if (eight qualifying stack peaks are missing or magic wrong) {
            return false
        }
        return the word packed from those peaks matches
            this tick's challenge answer
    }

    fn hourglass_armed(&self, mem: &Mem, l: PwnLatches) -> bool {
        if !l.sled_straddle || mem.load_u32(HOUR_MAGIC_ADDR) != HOUR_MAGIC {
            return false;
        }
        let r = mem.load_u32(HOUR_RESP_ADDR);
        r != 0 && r == hour_response(hour_challenge(self.tick))
    }

    fn hourglass_armed(self, mem, l) {
        if (the off-image stream did not keep moving across ticks
            or HOURGLASS magic wrong) { return false }
        let r = read HOURGLASS's answer cell
        return r is nonzero and matches this tick's challenge
    }

Self-modification: what bytes are actually fetched

Changing a code byte, fetching that changed byte, and counting how many changed addresses were fetched are three different events.

    pub packer_count: u32,
    pub metamorphic: bool,
    pub metamorphic_addr: u32,
    pub straight_line_jit: bool,
    pub read_own_code: bool,
    pub read_own_code_cov: u32,
    pub overlap_density: u32,

    VM observations for changed and overlapping code {
        count changed code addresses that were later executed
        note a fetched byte that was both changed and an old immediate
        note straight-line execution through changed code
        count code bytes read as data and interior bytes run as opcodes
        preserve a word describing where computed values reached the arena
    }

Worked machine trace: writing is not executing

Start with a code byte X in the uploaded image. During one tick, the bot writes a different value Y there. Keep these three events apart:

LOOM, PHOENIX, PACKER, and OUROBOROS each check a different part of this process. The host still checks each chain's proof before it adds a meter mark.

The VM's tested PACKER idea changes eight bytes. This teaching probe extends it to sixteen bytes for BASILISK, using the same operations. The VM counts distinct changed addresses that it later fetches. The probe runs once and does not score.

The repository's eight-byte VM test is the source for this construction. It uses two stores and starts its sealed strip at address 28. Our sixteen-byte version adds two more stores, which moves the strip to address 50. Here is the test code:

        const BASE: u32 = 28;
        let mut code = Vec::new();
        for w in 0..2u32 {
            pimm(&mut code, 0x5050_5050);
            pimm(&mut code, BASE + w * 4);
            code.push(op::STORE);
        }
        pimm(&mut code, BASE);
        code.push(op::JMP_ABS);
        assert_eq!(code.len() as u32, BASE, "setup ends exactly at BASE");
        for _ in 0..8 {
            code.push(op::HALT);
        }
        code.push(op::HALT);

        const BASE = 28;
        let mut code = an empty byte image;
        for w in 0..2u32 {
            pimm(&mut code, four NOT opcodes);
            pimm(&mut code, BASE + w * 4);
            code.push(STORE);
        }
        pimm(&mut code, BASE);
        code.push(JMP_ABS);
        assert_eq!(setup length, BASE);
        for _ in 0..8 {
            code.push(HALT as an original sealed byte);
        }
        code.push(HALT after the changed block);

    fn phoenix_armed(&self, mem: &Mem, l: PwnLatches) -> bool {
        if !l.smc_exec
            || l.smc_orig != SMC_SEAL_BYTE
            || l.smc_addr != (mem.load_u32(SMC_RUNE_ADDR) & ADDR_MASK)
            || mem.load_u32(SMC_MAGIC_ADDR) != SMC_MAGIC
        {
            return false;
        }
        let r = mem.load_u32(SMC_RESP_ADDR);
        r != 0 && r == smc_response(smc_challenge(self.tick))
    }

    fn phoenix_armed(self, mem, l) {
        if (changed original code did not execute,
            old byte is not the seal, address is not the saved rune,
            or PHOENIX magic wrong) { return false }
        let r = read PHOENIX's answer cell
        return r is nonzero and matches this tick's challenge
    }

    fn packer_armed(&self, mem: &Mem, l: PwnLatches) -> bool {
        if l.packer_count < PACKER_COUNT_MIN || mem.load_u32(PACK_MAGIC_ADDR) != PACK_MAGIC {
            return false;
        }
        let r = mem.load_u32(PACK_RESP_ADDR);
        r != 0 && r == pack_response(pack_challenge(self.tick))
    }

    fn packer_armed(self, mem, l) {
        if (too few distinct changed code bytes ran or magic wrong) {
            return false
        }
        let r = read PACKER's answer cell
        return r is nonzero and matches this tick's challenge
    }

    fn loom_armed(&self, mem: &Mem, l: PwnLatches) -> bool {
        if !l.code_patched || mem.load_u32(LOOM_MAGIC_ADDR) != LOOM_MAGIC {
            return false;
        }
        let r = mem.load_u32(LOOM_RESP_ADDR);
        r != 0 && r == loom_response(loom_challenge(self.tick))
    }

    fn loom_armed(self, mem, l) {
        if (no original code byte was changed or LOOM magic wrong) {
            return false
        }
        let r = read LOOM's answer cell
        return r is nonzero and matches this tick's challenge
    }

    fn basilisk_armed(&self, mem: &Mem, l: PwnLatches) -> bool {
        if l.packer_count < BASILISK_COUNT_MIN || mem.load_u32(BASL_MAGIC_ADDR) != BASL_MAGIC {
            return false;
        }
        let r = mem.load_u32(BASL_RESP_ADDR);
        r != 0 && r == basl_response(basl_challenge(self.tick))
    }

    fn basilisk_armed(self, mem, l) {
        if (too few distinct changed code bytes ran or magic wrong) {
            return false
        }
        let r = read BASILISK's answer cell
        return r is nonzero and matches this tick's challenge
    }

    fn ouroboros_armed(&self, mem: &Mem, l: PwnLatches) -> bool {
        if !l.straight_line_jit || mem.load_u32(OURO_MAGIC_ADDR) != OURO_MAGIC {
            return false;
        }
        let r = mem.load_u32(OURO_RESP_ADDR);
        r != 0 && r == ouro_response(ouro_challenge(self.tick))
    }

    fn ouroboros_armed(self, mem, l) {
        if (no straight-line run fetched newly changed code
            or OUROBOROS magic wrong) { return false }
        let r = read OUROBOROS's answer cell
        return r is nonzero and matches this tick's challenge
    }

    fn proteus_armed(&self, mem: &Mem, l: PwnLatches) -> bool {
        if !l.metamorphic || mem.load_u32(PROT_MAGIC_ADDR) != PROT_MAGIC {
            return false;
        }
        let r = mem.load_u32(PROT_RESP_ADDR);
        r != 0 && r == prot_response(prot_challenge(self.tick))
    }

    fn proteus_armed(self, mem, l) {
        if (no changed code byte was also an old PUSH input
            or PROTEUS magic wrong) { return false }
        let r = read PROTEUS's answer cell
        return r is nonzero and matches this tick's challenge
    }

    fn scrivener_armed(&self, mem: &Mem, l: PwnLatches) -> bool {
        if !(l.host_code_patched && l.smc_exec) || mem.load_u32(SCRIV_MAGIC_ADDR) != SCRIV_MAGIC {
            return false;
        }
        let r = mem.load_u32(SCRIV_RESP_ADDR);
        r != 0 && r == scriv_response(scriv_challenge(self.tick))
    }

    fn scrivener_armed(self, mem, l) {
        if (host did not change code, bot did not run changed code,
            or SCRIVENER magic wrong) { return false }
        let r = read SCRIVENER's answer cell
        return r is nonzero and matches this tick's challenge
    }

Reinterpretation: when one representation has several roles

A byte can first be instruction data and later become an instruction. A bot can also read its own code as data. The VM records the context that makes each second use meaningful.

    pub g_word: u32,
    pub resume_ip: u32,
    pub sled_straddle: bool,
    pub aulos_word: u32,
    pub aulos_high: bool,
    pub host_code_patched: bool,
    pub hydra_phase: u32,
}

impl Vm {

    g_word = whether the arena anchor was tainted
    resume_ip = VM instruction address when the tick ran out of budget
    sled_straddle = whether an off-image run crossed more than one tick
    aulos_word = packed low digits from recent stack peaks
    aulos_high = whether enough of those peaks were high in memory
    host_code_patched = whether a host write changed original code
    hydra_phase = distinct interior offsets revisited this tick
    }
    impl Vm {

Worked machine trace: bytes do not have one permanent role

An opcode can use the following bytes as an immediate value. A jump can then make the VM start decoding at one of those bytes. The byte does not move; only the starting point changes. Reading code as data is a separate event again.

This family is about relationships among interpretations, so a single straight disassembly or one read cannot establish every named behavior.

    fn janus_armed(&self, mem: &Mem, l: PwnLatches) -> bool {
        if !l.overlap_fired
            || l.overlap_witness == 0
            || mem.load_u32(OVL_WITNESS_ADDR) != l.overlap_witness
            || mem.load_u32(OVL_MAGIC_ADDR) != OVL_MAGIC
        {
            return false;
        }
        let r = mem.load_u32(OVL_RESP_ADDR);
        r != 0 && r == ovl_response(ovl_challenge(self.tick))
    }

    fn janus_armed(self, mem, l) {
        if (no overlapping instruction ran, witness missing or mismatched,
            or JANUS magic wrong) { return false }
        let r = read JANUS's answer cell
        return r is nonzero and matches this tick's challenge
    }

    fn polyglot_armed(&self, mem: &Mem, l: PwnLatches) -> bool {
        if l.overlap_density < OVERLAP_DENSITY_MIN || mem.load_u32(POLY_MAGIC_ADDR) != POLY_MAGIC {
            return false;
        }
        let r = mem.load_u32(POLY_RESP_ADDR);
        r != 0 && r == poly_response(poly_challenge(self.tick))
    }

    fn polyglot_armed(self, mem, l) {
        if (too few distinct inside-instruction bytes ran as opcodes
            or POLYGLOT magic wrong) { return false }
        let r = read POLYGLOT's answer cell
        return r is nonzero and matches this tick's challenge
    }

One byte walk that reaches both overlap thresholds

This example is the missing bridge between “jump into a PUSH” and “count twelve different bytes.” It is a one-tick teaching program. It reaches the VM counter, but it writes neither chain's magic value nor answer, so it does not score.

All addresses and byte values in the diagram are hexadecimal. The small labels are addresses, and the large values are the bytes stored there. Byte 04 means POP, and 11 means JMP_ABS.

On the first pass, these are only part of a PUSH value, but the jump to 0x01 makes the VM read them as instructions. The bytes stay exactly the same; only the point where decoding begins moves.

Build the 49-byte route:

1. Put 01 04 04 04 11 at 0x00, 0x05, and 0x0A. This makes three aligned PUSH instructions. Each value hides three POP instructions and one JMP_ABS.
2. Put 04 04 04 at 0x0F. These POP instructions remove the three values left by the aligned PUSH instructions. Build the jump stack from bottom to top: 0x30, 0, 0, 0, 0x0B, 0, 0, 0, 0x06, 0, 0, 0, 0x01. Use PUSH for addresses and PUSH_ZERO for each zero.
3. Put JMP_ABS at 0x2F and HALT at 0x30. The first jump uses 0x01. Each hidden group removes three zeros and jumps to the next group. The last group jumps to HALT.

The later PUSH instructions also mark their own value bytes as interior, but nothing jumps into those, so they add zero to the count. The VM remembers fetched addresses, not repeat visits, so twelve jumps to 0x01 still count as one address. The VM does the bookkeeping here:

                    if is_interior {
                        self.overlap_fired = true;
                        self.overlap_witness = ipa;
                        if self.fetched_interior[a >> 3] & (1u8 << (a & 7)) == 0 {
                            self.fetched_interior[a >> 3] |= 1u8 << (a & 7);
                            self.overlap_density = self.overlap_density.saturating_add(1);
                        }
                    }

                    if is_interior {
                        self.overlap_fired = true;
                        self.overlap_witness = this address;
                        if this address was not counted earlier this tick {
                            mark this address as counted;
                            self.overlap_density += 1;
                        }
                    }

One boundary is worth keeping straight. The twelve-address walk proves the VM behavior, but it does not by itself arm POLYGLOT or KALEIDOSCOPE. The host also checks each chain's magic value and current answer. For JANUS, the final interior address fetched here is 0x0E. Write 0x0E to its witness cell if you also want JANUS in that tick.

    fn kaleidoscope_armed(&self, mem: &Mem, l: PwnLatches) -> bool {
        if l.overlap_density < KALEIDOSCOPE_DENSITY_MIN
            || mem.load_u32(KALE_MAGIC_ADDR) != KALE_MAGIC
        {
            return false;
        }
        let r = mem.load_u32(KALE_RESP_ADDR);
        r != 0 && r == kale_response(kale_challenge(self.tick))
    }

    fn kaleidoscope_armed(self, mem, l) {
        if (the higher inside-instruction count was not reached
            or KALEIDOSCOPE magic wrong) { return false }
        let r = read KALEIDOSCOPE's answer cell
        return r is nonzero and matches this tick's challenge
    }