bobcat-proxy

Crates.iobobcat-proxy
lib.rsbobcat-proxy
version0.7.19
created_at2025-10-13 07:53:15.378043+00
updated_at2026-01-23 10:08:48.472144+00
descriptionbobcat-sdk utilities for creating proxy code on Arbitrum Stylus.
homepagehttps://bobcat.so
repositoryhttps://github.com/stylus-developers-guild/bobcat-sdk
max_upload_size
id1880141
size22,421
Bayge (af-afk)

documentation

README

bobcat-proxy

Notes on use

Be sure to enforce access control on upgrade and migration functions properly! Be careful not to accidentally burn your access here!

The proxies

bobcat-proxy contains several proxies that fulfill different functions. These include:

  1. beacon-proxy-no-slot.huff: Creates a "beacon proxy" that asks a hardcoded beacon for its implementation address. In bobcat-sdk, it can be used with a custom function signature, making a multiple contract implementation possible. This is useful for a normal contract deployment situation with many addressess.
flowchart LR
    BeaconProxy[Beacon proxy]
    -->|Calls| Beacon
    -->|Delegatecalls| BeaconImpl[Beacon implementation]

  1. beacon-proxy.huff: Creates a "beacon proxy" that asks a beacon address at the beacon storage slot for an implementation location. Useful for upgradeable beacons.

  2. eip1967.huff: A very small proxy that literally just forwards calldata all the time to the location provided in the implementation storage slot. This is useful for deployments that won't see multiple copies of the same contract.

flowchart LR
    Proxy -->|Delegatecalls| Implementation

  1. multi3-proxy.huff: A weird proxy that does delegatecall to an implementation chosen based on the calldata given to its invocation. This is useful for a contract split across multiple implementations that does not need upgrade features.

  2. sel-beacon-proxy.huff: A proxy that asks a beacon for its implementation address based on the selector given. This is useful for upgradeability when a contract needs to be split across multiple contract locations.

  3. metamorphic-on-fn.huff: A proxy that performs a metamorphic upgrade to a hardcoded address when a specific selector is invoked. This is useful for optional super infrequent upgrade migrations, perhaps in a limited account abstraction context. This might be useful for situations where contract change includes a strictly additive method of feature release. An approach might be to have a transparent upgradeable proxy in front of the factory that deployed this, and having that as the hardcoded upgrade slot, but then having the factory's implementation itself set as the slot that this calls. This should massively reduce the amount of deployments on-chain of the contracts.

flowchart LR
    Proxy --> IsMigrationFunction{Is migration function?}
    -->|Yes: delegatecall deployer| Deployer
    IsMigrationFunction -->|No: delegatecall slot| ImplSlot[Implementation slot]
Commit count: 389

cargo fmt