New protocol design #2: Refactor of safe and whitelisting #86
Conversation
sources/utils/utils.move
Outdated
| /// Witness is a type always in form "struct Witness has drop {}" | ||
| /// | ||
| /// They must be from the same module for this assertion to be ok. | ||
| public fun assert_same_package_as_witness<OneTimeWitness, Witness>() { |
There was a problem hiding this comment.
This should be assert_same_module_as_witness, as we also check module.
|
|
||
| // NFT object with an option to hold `D`ata object | ||
| struct Nft<phantom T, D: store> has key, store { | ||
| struct NFT<phantom C> has key, store { |
There was a problem hiding this comment.
I like NFT better than Nft, but I think if we name the struct the same name of the module but in Caps, it will make it a OTW. Perhaps we keep it Nft?
There was a problem hiding this comment.
I believe an OTW must have drop only and no fields.
| /// Remove an NFT from the `Safe` and give it back to the logical owner. | ||
| public entry fun withdraw_nft<T, D: store>( | ||
| nft_id: ID, | ||
| owner_cap: &OwnerCap, | ||
| safe: &mut Safe, | ||
| ) { | ||
| assert_owner_cap(owner_cap, safe); | ||
| assert_contains_nft(&nft_id, safe); | ||
|
|
||
| let (_, ref) = vec_map::remove(&mut safe.refs, &nft_id); | ||
| // an exlusively listed NFT must first have its transfer cap burned | ||
| // via fun burn_transfer_cap | ||
| assert_not_exlusively_listed(&ref); | ||
|
|
||
| let nft = object_bag::remove<ID, Nft<T, D>>(&mut safe.nfts, nft_id); | ||
| nft::transfer_to_owner(nft); | ||
| } | ||
|
|
There was a problem hiding this comment.
Is the intention to add back this function later?
There was a problem hiding this comment.
We don't want to allow the user to freely take an NFT out of a safe at the current design stage, which is what this function was for.
sources/safe/royalties.move
Outdated
| /// Only the designated witness can access the balance. | ||
| /// | ||
| /// Typically, this would be a witness exported from the collection contract | ||
| /// and it would access the balance to calculate the royalty in its custom | ||
| /// implementation. | ||
| public fun balance_mut<C, W: drop, FT>( | ||
| _witness: W, | ||
| payment: &mut TradePayment<C, W, FT>, | ||
| ): &mut Balance<FT> { | ||
| &mut payment.amount | ||
| } |
There was a problem hiding this comment.
Is it needed &mut balance for calculating the royalty in its custom implementation, or should &balance suffice?
There was a problem hiding this comment.
Isn't this only needed when transferring the funds to the beneficiary?
There was a problem hiding this comment.
You need access to &mut balance to be able to actually charge the royalty. Ie. you calculate it from this balance and then you take your cut out of it.
Safe + whitelisting
No description provided.