Skip to main content

Differences from the EVM Version

1. Book Id​

  • EVM Version: Uses the keccak256 hash and then takes 192 bits of the result for the Book Id.
  • Cairo Version: Uses the Poseidon hash function and then takes 187 bits for the Book Id.

By relying on Poseidon Hash in Cairo, the Book Id format adjusts from 192 bits down to 187 bits to align with felt252-based operations in Starknet.

2. Order Id​

  • EVM Version: Combines BookId, tick, and index into a single uint256.
  • Cairo Version: Since the BookId itself consumes 187 bits, Order Ids are encoded as felt252 values.

Storing the Order Id in felt252 format is more gas-efficient on Starknet, which favors felt-based storage.

3. FeePolicy​

  • The Cairo implementation encodes FeePolicy differently than the EVM version. For detailed information on how it’s encoded, see the fee_policy.cairo file.

4. Hooks​

  • EVM Version: When multiple hooks exist, they are stored using tstore in Solidity.
  • Cairo Version: Since using the same pattern isn’t feasible, a dedicated storage mechanism is introduced in hooks_list.cairo.

This design shift allows multiple hooks to be effectively handled within Cairo’s storage constraints.

5. BookManager​

  • EVM Version: The function getCurrencyDelta returns an int256.
  • Cairo Version: Because Cairo does not natively support int256, an i257 library is used. Consequently, get_currency_delta returns an i257 type.

This approach ensures that operations requiring signed arithmetic can still be performed, despite the differences in native integer representation.

6. SegmentedSegmentTree & TotalClaimableMap​

  • Gas Optimization: In the EVM version, values are stored as uint256. In Cairo, to minimize gas costs, these values are stored as felt252.
  • Implementation: For this packed representation, the project uses packed_felt252.cairo.

By using felt252 instead of uint256, the contracts take advantage of Cairo’s native field element storage to reduce gas costs.

7. Controller​

  • Starknet’s MultiCall: In Starknet, MultiCall functionality is natively available, so the Controller design only supports single-action calls.
  • Removed ERC20 & ERC721 Permit: For the same reason, ERC20 and ERC721 Permit functionalities have been removed entirely.

With Starknet’s built-in MultiCall, the need to batch multiple actions in a single contract call is less critical, simplifying the Controller’s logic and removing the permit requirement.