Orderly Network security record

The report gives no description here.

The report gives no description here.

The report gives no description here.

The report gives no description here.

The report gives no description here.

The report gives no description here.

The function `new_account_approved`, updates an approval request dependent on the number of approvals. Further, an approval request will only be successfully approved if the new role account and a sufficient number of approvers agree to the request. However consider the following case where the approval request will not be completed. Assume the following: 1. There are 10 approvers 2. The number of approvals required is 6 = 10/2+1 3. The "SetOwner" request is in progress. There is no maximum limit on the number of approvers allowed to approve a request. Therefore the `approved_by' field can be larger then the sufficient amount. If the `approved_by` is strictly larger then the sufficient amount then the `request.approved_by.is_set_enough()` function will return false. The new "owner" account will never be successfully approved. And another new `SetOwner` request cannot be created because of that stuck request.

The `user_request_withdraw()` function requires users to deposit 1 yoctoNear to withdraw assets, however, the function itself is not marked as `payable`.

Near provides two methods either by manual byte math or using the SDK environment. The manual method is difficult and requires manual gas measurements. On the other hand, checking [`env.storage_usage()`](https://docs.near.org/concepts/storage/storage-staking#calculate-costs-for-your-own-contract) is a more accessible method. In the codebase, a user's storage cost is calculated based on the manual byte math. We provide the user registration example to show that the method used in the codebase contains an inaccuracy. When registering a new user in the `asset manager` contract, the types `AccountId` and `AccountV2` data will be saved on the chain. The const variable `INIT_ACCOUNT_WITH_ONE_KEY_STORAGE`, whose value is 358 bytes, denotes the initial size of the above two data types and also the minimum attached deposit for registering a new user. Actually, the storage usage denoted by `INIT_ACCOUNT_WITH_ONE_KEY_STORAGE` is inaccurate. The following test code's output shows that the value of `INIT_ACCOUNT_WITH_ONE_KEY_STORAGE` is smaller than the real storage usage for registering a user. In this case, the contract itself needs to pay for a part of the users' storage usage. [`Test Code`]: ```rust // As needed, we change the scope of the `AccountV2`'s function `from_user` and field `keys` from `public(crate)` to `public` use asset_manager::{account_deposit::*, types::*}; fn main() { let initial_storage = env::storage_usage() as u128; let alice = AccountId::try_from("alice.near".to_string()).unwrap(); let mut user_record = AccountV2::from_user(&alice); let orderly_key: PublicKey = "ed25519:6E8sCci9badyRkXb3JoRpBj5p8C6Tw41ELDZoiihKEtp".parse().unwrap(); user_record.keys.insert(&orderly_key, &TradingKey::default()); let mut user_ledger: UnorderedMap<AccountId, VAccount> = UnorderedMap::new(StorageKey::CurrentUsers); user_ledger.insert(&alice, &VAccount::V2(user_record)); let current_storage = env::storage_usage() as u128; let storage_diff = current_storage - initial_storage; println!("Calculating new user storage cost by calling SDK:"); println!("initial storage: {}, current storage: {}, storage cost: {}", initial_storage, current_storage, storage_diff); println!("Calculating new user storage cost by manual byte math:"); println!("storage cost: {}", INIT_ACCOUNT_WITH_ONE_KEY_STORAGE); } ``` [`Output`]: Calculating new user storage cost by calling SDK: initial storage: 307200, current storage: 307966, storage cost: 766 Calculating new user storage cost by manual byte math: storage cost: 358

If the owner or an approver creates an approval request, it will cause an error if they try to process it more than once in the following functions: 1. `approve_approver_request_persmission` 2. `approve_symbol_listing` 3. `approve_symbol_delisting` 4. `approve_withdraw_verify_key` 5. `approve_trade_verify_key` 6. `approve_autorized_access` 7. `new_account_approved` 8. `token_action_approve` The error message instructs the user to create a new request. However, if a new request is created then these functions will panic as there is already such request type in existance. ```rust=365 pub(crate) fn create_approver_request( &mut self, request_type: ApproveRequestType, request: ApproveRequest, ) { if self.approve_requests.contains_key(&request_type) { env::panic_str("This type of request is already in progress"); } self.approve_requests.insert(&request_type, &request); } ```