Contract storage layout

In the swayswap exchange contract, the TOKEN_ID_KEY is 0x0000000000000000000000000000000000000000000000000000000000000001.

the token reserve can be read from storagewith the key.

// To get the reserve of the token
fn get_current_reserve(token_id: b256) -> u64 {
    get::<u64>(token_id)
}
let token_reserve = get_current_reserve(get::<b256>(TOKEN_ID_KEY));

What does the fuel contract storage layout look like?
Why can the eth reserve and the other token’s reserve be read from the 0x00 and the0x01 storage slot? I thought the first storage slot stores the lp_token_supply
And what is the storage key of the lp_token_supply?

storage {
    lp_token_supply: u64 = 0,
    deposits: StorageMap<(Address, ContractId), u64> = StorageMap {},
}

The SwaySwap AMM implementation pre-dates many features of the storage API, and uses low-level storage get and store methods.

For a more up-to-date and fully featured AMM implementation, I recommend you check out the version in the Sway Applications repo here.

2 Likes

The storage keys used by the compiler are all hashes of strings that start with "storage_" which means collision with 0x00.000 is unlikely. There will be a document in the future that will explain exactly how storage slots are selected based on the typed of the data being stored.

3 Likes

looking forward to it!

This topic was automatically closed 20 days after the last reply. New replies are no longer allowed.