The Great Interface Migration

The problem

The Cairo community has been experiencing a huge lack of consistency across projects, interfaces, and coding styles (1, 2, 3, 4, 5, …?).

A solution

The consensus was to follow snake_case since that was the final choice made by Cairo 1.0. Now, the hard part:

This is the migration plan for OpenZeppelin Contracts for Cairo. Users of the library are encouraged to follow along a two-step process consisting of three stages:

  • Stage 0: current situation
  • Stage 1: support both interfaces
  • Stage 2: phase out camelCase, snakes all over

Although this migration plan is for OpenZeppelin Contracts, we strongly encourage the wider StarkNet ecosystem to follow along with non-OpenZeppelin interfaces as well.

Stage 0: snaMel or penguin_Case

This is were we’re at today. Most contracts are Cairo 0.x and they will have to keep up with regenesis, either by upgrading or through alternative migration paths.

These forced updates are the perfect wave for this migration to ride.

Stage 1: dual interfaces

Leveraging the forced migration, OpenZeppelin Contracts for Cairo will provide a library that:

  • exposes both snake_case and camelCase interfaces
  • calls both snake_case and camelCase functions on other contracts

The latter would be done by attempting the snake_case function first (incentivizing optimizoors to favor the preferred casing), and try with camelCase before finally reverting. Such fallback mechanism should also be available as a module for other contracts to call (e.g. call ERC20::transfer_from() and let the dispatcher resolve the right casing, similar to Solidity’s SafeERC20).

This way, contracts will be compatible with old and new interfaces. Users are encouraged to deploy Stage 1 contracts before regenesis in preparation for Stage 2.

Stage 2: snakes all over

After a TBD period of time, most probably after regenesis, the library will drop camelCase:

  • exposing only snake_case interfaces
  • calling only snake_case functions on other contracts

Since Stage 1 provided full compatibility with both interfaces, there’s no need or rush to upgrade or migrate existing contracts to this version. It’s up to users to evaluate case by case whether it’s safe to do so.

We expect the community to eventually phase out of using camelCase at its own pace.

Opening up the discussion

This is a forum topic and not a blog post because we’re interested in your thoughts and ideas. Does this work for you? how can we make this as seamless and easy as possible?

I think we should just move to stage 2 directly, SithSwap will use snake_case only in the Cairo1 deployment

I don’t think that’s possible, projects won’t upgrade at the same time, not even if they somehow do it in the same block. We need to maximize stability and interoperability.