OKX Marketplace of Solana

All the instructions that update the protocol configurations forward their logic to the helper function `update_protocol_config_account`. This function modifies the data of the global protocol configuration (`ProtocolConfig` account). It can change the protocol's: - Status: if the status is `false`, the program is frozen, this means that all the marketplace instructions are not callable - Fee base points - Fee recipient - Manager The mentioned helper function checks if the caller is signing the transaction but it doesn't check if the caller is the `protocol_manager` saved on the global protocol configuration (`ProtocolConfig` account). This means that the instructions using this helper function can be called by anyone, not only by the `protocol_manager`.

The native function `find_program_address` allows to find the address of an account deterministically in base to input seeds (list of values like address, text, or numbers). This address is used by PDAs (Program Derivates Address) accounts. PDAs are managed by the program itself and nobody else. These addresses don't have a private key associated with their address (public key); therefore, no external actors (users or clients) can sign transactions by those addresses. This ensures that only the program owner of the PDA can sign transactions by this account. Finding an address in base to the input seeds that doesn't have a private key is not deterministically and requires a considerable amount of computing power by the on-chain program. The pointed `find_wsol_vault_address` statement is executed always in the successful calls of the instruction `cancel_order`. However, it is useless in the case of a sale order (`order_info.is_buy = false`) because the seller doesn't have a `wsol_vault` account. This leads to unnecessary extra computing units used by the instruction when a sale order is cancelled.

The instruction `close_order` contains two mutually exclusive consecutive `if` statements, this means the if the first one is activated the second one is not activated and the opposite situation. This is less efficient than using a `if else` logic.

The account `rent` is not validated on the instructions `make_order` and `update_price` before calling the `initialize_mint` instruction of the `spl_token` program. This could lead to transactions that fail without a specific error if the rent account is incorrect. The `initialize_mint` instruction on the used version `3.2.0` of the `spl_token` program, doesn't validate that the `rent` account address is correct, but it directly uses a hardcoded value of this address. Therefore, if the passed `rent` account is incorrect, the transaction will fail without a specific error due to a required account (the official `rent` account address) not being passed to the instruction.

The Native Mint account with the name `native_mint_account` is not validated in multiple instructions by comparing with the official Native Mint address. ```rust native_mint_account.key == &spl_token::native_mint::id() ```

In the `update_price` instruction, for buying orders (`order_info.is_buy = true`) the new payment stored on the wrapped SOL account is updated but the delegated amount is not updated. This means that the Vault account (used as the program's wallet) is allowed to manage only the first declared payment calculated using the price defined during the calling of the `make_order` instruction.

Some of the packages used on the project are outdated. For example, the `mpl-token-metadata` is on version `1.2.5` but the version `1.3.1` is available, that version improves the deserialization of the Metadata account what is used by this program. The usage of [yanked](https://doc.rust-lang.org/cargo/commands/cargo-yank.html), outdated or vulnerable packages can lead to dangers not visualized on this audit because those packages could insert vulnerabilities on the codebase that were out of the scope, therefore not found.

The System Program account with the name `system_account` is not validated in multiple instructions by comparing with the official System Program ID. ```rust system_account.key == &solana_program::system_program::id() ```

There are typos in multiple files, they are ordered by file and location: - On `instructions.rs` - `accout` should be `account` - `udpate` should be `update` - `expeected` should be `expected` - `Accouts` should be `Accounts` - `protocl` should be `protocol` - On `processor.rs` - `Updata` should be `Update` or `Transfer` to be consistent with the instruction name - `remainning` should be `remaining` - `caclculate` should be `calculate` - `tranfer` should be `transfer` - `exclued` should be `excluded` - `transfered` should be `transferred` - `initilized` should be `initialized` - `Protocl` should be `Protocol` (2) - On `utils.rs` - `Protocl` should be `Protocol` - `dervided` should be `derived` (2) - On `errors.rs` - `Protocl` should be `Protocol`