Upgrade dev genesis accounts to SRC9-compatible account class

[kariy]

Summary

The pre-deployed genesis accounts in Katana dev mode use a legacy OpenZeppelin account class that does not implement the SNIP-9 (SRC9) outside execution interface (execute_from_outside_v2). This prevents dev accounts from participating in flows that rely on outside execution, most notably the VRF (Verifiable Random Function) integration.

Motivation

VRF requires SRC9

The Cartridge VRF flow works by wrapping user transactions inside execute_from_outside_v2 calls on the user's account:

Relayer → Forwarder → VRF Account.execute_from_outside_v2([
    submit_random(...),
    PlayerAccount.execute_from_outside_v2([
        request_random(...),
        game_action(...)
    ])
])

Because the player account is called with execute_from_outside_v2, it must implement the SRC9 interface. The current genesis accounts return ENTRYPOINT_NOT_FOUND when this is attempted.

Discovered during e2e testing

This gap was found while building an e2e test for the VRF flow with real paymaster and VRF sidecar services. The workaround was to deploy a separate CartridgeVrfAccount instance as the player — but this defeats the purpose of having ready-to-use dev accounts.

Broader ecosystem alignment

SRC9 (outside execution) is a standard part of the Starknet account abstraction ecosystem:

• Cartridge Controller accounts implement SRC9
• OpenZeppelin Contracts for Cairo v2.0.0 ships an SRC9Component that can be composed into any account
• Paymaster-sponsored transactions and gasless UX patterns rely on outside execution

Dev accounts should match the capabilities that real-world accounts have, so that local development and testing accurately reflects production behavior.

Proposal

Replace the dev genesis account class with one that includes the SRC9Component (outside execution support). This could be:

1. The existing AccountMock pattern from the VRF contracts — an OZ AccountComponent + SRC9Component composition (see crates/contracts/contracts/vrf/src/mocks/account_mock.cairo)
2. A new katana_account contract that adds SRC9Component to the current account class
3. Use CartridgeVrfAccount as the dev account class (already available in the contracts crate)

Option 2 is likely the cleanest — minimal change to the existing account, just adding the SRC9 component.

Migration consideration

Changing the genesis account class hash will change the pre-computed genesis account addresses (since the address depends on the class hash). This is a breaking change for any tooling or tests that hardcode genesis addresses. A migration path should be considered (e.g., updating test fixtures with make fixtures).

Related

• VRF server: https://github.com/cartridge-gg/vrf
• SNIP-9 spec: https://github.com/starknet-io/SNIPs/blob/main/SNIPS/snip-9.md
• OpenZeppelin SRC9Component: openzeppelin_account::extensions::src9