Ah, forgot the reply to your last questions about why another canister is present.
It’s the storage canister here. How it’s working is :
Icrc7 ledger manage 2 types of subcanisters, the icrc3 archive canisters and the storage canister.
Internally, both of this library use this library : dfinity-rust-libraries/src/subcanister_manager at master · BitySA/dfinity-rust-libraries · GitHub to scale (create new canisters) and manage subcanisters cycles.
In fact, icrc3 lib dfinity-rust-libraries/src/icrc3 at master · BitySA/dfinity-rust-libraries · GitHub is used to manage transaction stuff/security stuff arround transactions. THats also why at start, the collection deployement will burn some cycles as it’ll pop one canister here to archive the transactions to a subcanister via icrc3
In same veins, you can choose to use IPFS, even s3 (.. 
) or storage canister. The idea here, is the collection canister act as a proxy (assets are exposed on https endpoint, using last dfinity library for that : ic_asset_certification - Rust), meaning you can access the assets via https://xea2t-daaaa-aaaaj-qnp2a-cai.raw.icp0.io/e17e265548a90d803975b95a9d32c158c213dd267b24826d71062f207a57319a.json in your case, which will redirect to the wanvb-2aaaa-aaaaj-qnp4a-cai canister, which is a storage canister controlled by your collection canister : https://dashboard.internetcomputer.org/canister/wanvb-2aaaa-aaaaj-qnp4a-cai
If for any reason you want to store more than “stable memory limits”, or you can not store anymore on your storage canister, it will automaticly create a new canister on another subnet to handle infinite scaling.
Advanced info about how storage canister is working :
Storage canister use stable memory to store assets. BUT, the ic-asset-certification library need assets to be served in heap. (note that currently, asset canister from dfinity store asset in heap.. 
)
So, what i did here, is i use heap as a cache. So if https calls fail, i have to mutate some stuff in state, so i use a update calls : ic-storage-canister/canister/src/queries/http_request.rs at master · BitySA/ic-storage-canister · GitHub
If the first RO call fail, that mean the asset is not mapped to heap. So i change to an update call and i start to look for the file, and if not available i return an error. If present, then i map the file to the heap and serve the asset to the client. note that, if no heap left are available, i use a first in first out mecanism to free heap usage. With wasm64 we will have soon ~6gb available in heap.
Does it help you to understand ?
Edit : Note that we will also start to work on encrypted assets, to have “private assets” only visible for nft owner. No timeline yet, will depend on human ressources.