Scrypto Checklist

Release: Version 1.0

#	Item	Description
1	Bucket resource address validation	All buckets in a smart contract must be validated to have the correct resource address.
2	Permission control	All permissions and roles in the smart contracts must be validated including upgradability. It is important to check enable_method_auth! Macro in a smart contract.
3	Proof resource address validation	All proofs should be checked for correct resource address
4	Duplicates in data structures validation	All data structures like Vec Set Map should be checked for possible duplicates like in the case of Bucket - two buckets with the same resource address. It's a mistake to assume that by using Set of Buckets all of them must be unique but it's not and can be multiple Buckets of the same resource in any data structure.
5	Bucket NFT count validation	In buckets with NFT there can be more than one NFT in the bucket. It should be validated that smart contracts are correctly handling such cases.
6	Bucket burn addition validation	Bucket burn is one of the most dangerous functions and should be validated that only the correct resource and amount of it can be burned.
7	Resource permissions validation	All resources permissions defined by resource manager should be carefully validated including upgradability of permissions. It also applies to default permission for all kinds of operations (withdraw deposit lock burn freeze etc).
8	Transient tokens reentrancy validation	Whenever a smart contract creates a transient resource (a resource that must be burned in the same transaction) it should be validated that there is no logic in a smart contract that can be abused somehow between the emission and burning of this kind of token. It creates an issue similar to reentrancy.
9	Asset-oriented approach validation	Ensure the smart contract follows an asset-oriented design avoiding the use of user account addresses for identification. Instead the contract should issue tokens that users can use for verification. Data related to user participation should be represented by tokens or NFTs rather than stored directly in the contract. For instance instead of assigning pool shares directly to users issue POOL tokens to represent their share with ownership determined by the tokens they hold in relation to the total supply.
10	Smart contract interactions	All interactions with external smart contracts must be thoroughly validated particularly when the source code is provided by a third party. If an interaction fails the entire transaction could fail leading to potential Denial of Service (DoS) risks. When external interactions return data especially if they return buckets the data must be carefully validated. Excessive interactions with non-native contracts can also be problematic due to high execution costs making complex transactions too expensive to carry out effectively.
11	Objects removal and update validation	In Scrypto initialized objects such as smart contracts vaults key-value stores and resource managers cannot be removed or transferred to other contracts. Auditors must validate that no operations attempt to remove or transfer these objects. Additionally updates to data structures involving these objects must be carefully checked. For example a previously inserted Vault in a HashMap<u32 Vault> cannot be overwritten as this would require deletion which is not allowed.
12	Decimal validation	All decimals should be validated for cases such as negative numbers provided by the user numerical errors and rounding errors.
13	Correct component initialization validation	It should be validated if components or objects are correctly stored and interactions with them are correct. It means checking if objects are using Own<> or Global<> and are correctly initialized with instantiate prepare_to_globalize globalize and other related functions.
14	Third-party resources validation	If a smart contract supports third-party resources it should be validated if it correctly handles different configurations of them like different precision and non-typical configurations like blocking withdraws deposits freezing assets or even recalling tokens from the smart contract.