Read the findings of the 2022 Web3 Security Report

The `PayoutListAccount#authority` accounts have exclusive privilege over the following functions:
- `add_payout_list_item`
- `clear_payout_list`
- `lock_payout_list`

The `PayoutAccount#authority` account have exclusive privilege over the following function:
- `set_payment_switch_threshold`

Any compromise to the `PayoutAccount#authority` or the `PayoutListAccount#authority` accounts may allow a hacker to take advantage of this authority and, e.g.,:

- add arbitrary destination addresses to the payout list;
- clear the payout list before list locking;
- arbitrarily lock the list of payout;
- arbitrarily change the payment threshold.

Centralization Related Risks

The project does not specify a compiler version.

Is highly recommended to specify the toolchain used to compiles the packages.

Otherwise:

* users compiling using different toolchain, have higher change of getting differently behaving final build,
* if compiler bug/vulnerability will be discovered in future, without tracking which version was used for build it's harder to make a judgement of impact, check if issue applies to this build and if mitigation/upgrade are needed.

Unlocked Compiler Version

The missing validation of the `per_myriad` parameter can lead to unexpected distribution.

Missing Input Validation of `per_myriad`

It's not ensured in `pay_dividend` and `create_dividend` that `payout_list` is `locked` during payout, that may lead to list modifications using `add_payout_list_item` in the middle of payout (which happens in multiple calls).

List not locked when paying dividends may be modified in the middle of payouts

The `pay_before_threshold_public_key` field in the `PayoutAccount` is set in the program initialization but never used for any check. \
In fact, in function `pay_before_threshold`, the address to be payed is taken from the list of declared accounts (Line 115) and no check is enforced on it. Since the `pay_before_threshold` can be called by ANY account, due to the fact that there is not any check on the `authority` account field, ANY account can call the function and grab the payment amount in place of the designated one.

Missing payout addresses check

In this program, storage is implemented through two unique accounts generated as Program Derived Addresses (PDA) and with data layout represented by the `PayoutAccount` and the `PayoutListAccount` structs. As they are initialized and required to be unique, the program should check that the accessed storage accounts are exactly the one expected. \
This is suggested for functions:

-  `add_payout_list_item`
-  `lock_payout_list`
-  `pay_before_threshold`
-  `set_payment_switch_threshold`
-  `create_dividend`

that use only one of the two storages with write access, but it is strongly recommended for functions:

- `clear_payout_list`
- `pay_dividend`

that access both storage accounts, reading one and writing on the other. In fact a malicious user or authority could tailor an account with a certain storage data compatible with the `PayoutAccount` and the `PayoutListAccount` structs and then use them to trigger actions that the program was not supposed to do, e.g.
- for `clear_payout_list` clearing a payout list when `PayoutAccount#dividend_in_progress` is `true`
- for `pay_dividend` pay dividend to a different account list.

Missing Program Derived Address verification

* `Rent::get()` has Time of Check (ToC) in `create_dividend`, where it's used to computed and split into rent and `dividend_in_progress`.
* `Rent::get()` has Time of Use (ToU) in multiple `pay_dividend` calls, for each payout. It may change in mean time, preventing some or all payouts, or if earlier overestimated leaving gas.

Rent can change between read and check [ToCToU]

Functions that set parameters of smartcontract, have potential to set parameters to unexpected values that lead to unexpected behaviour. 

Validate input parameters

It is a good practice to document why an `AccountInfo` type is used in place of an `Account`. This practice is also enforced at compile time starting from Anchor v0.22.0

Missing unsafe AccounInfo documentation + upgrade to newer Anchor

Check `payout_account.dividend_index as usize > payout_account_max_index` is repeated twice in the same `if` construct with a `||` concatenation.

Duplicated check

Variable `payout_account_info` initialized in line 153 is reassigned to the same value in line 164 but no change happened in the middle of the two assignments. \
Variable `payout_account_max_index` in line 197 and variable `max_payment_list_array_index` are initialized to the same value that is never changed.

Redundant variable definitions

The calculation for the space required by the `PayoutListAccount` struct seems to report 4 exceeding byte for the `locked` field and the `authority` field. \
This results in a greater payment for rent (or rent-exempt deposit).

Unnecessary space reservation

The function that affects the status of sensitive variables and/or privileged operations should be able to emit events as notifications to users.

- `add_payout_list_item`
- `clear_payout_list`
- `lock_payout_list`
- `set_payment_switch_threshold`
- `create_dividend`

External applications integrating with Solana and this program, may like to monitor those important events and react accordingly.

Missing Emit Events

Instead of performing operations on payout_list, one entry at a time, there is possibility to batch, and perform multiple at one call:

* `add_payout_list_item`
* `pay_divident`

For:

* optimization of gas 
* and processing multiple entries with same Rent price (which may change between calls)

Batch payout operations

Program makes access to array but does not check earlier if index is within range:

```rust=211
 payout_list_account.per_myriads[payout_account.dividend_index as usize];
```

Index not checked before accessing array

is `u16` sufficient for `capacity` in `space()` in the `lib.rs`? 


is `u16` sufficient for `capacity` in `space()`

Here myriads are examples, that 1 percent is represented by value 100 myriad, and 100 percent is 10'000 myriad.

Document that 1 percent is 100 of myriad 

The anchor version fixed in the `Cargo.toml` and `Cargo.lock` files is `0.21.0`, while the `README.md` indicates to use the `0.19.0`.

Documented anchor version

Augmentors

lib.rs

utils.rs

3.7 Trillion SHIB Moved to Exchanges This Week as SHIB Game Soars to Top 20 in App Store

Game On: Buried treasure games of 2022

Mega Matrix discontinues Mano game, alSpace platform due to regulatory issues

Hasbro Is 'Killing its Golden Goose' Card Game. BofA Downgrades To Sell.

Expert says the Patriot missiles are 'not a game changer.' Hear why

Crypto’s Game Plan After FTX’s Collapse

After Logan Paul's CryptoZoo game failed to let players

Robocallers have upped their scam game and they’re after your crypto

The SEC Chair Issued A Game-Changing Ethereum Warning—Sparking A Major Price Crash

Shiba Eternity Game: Australia Might Be "Last Test Location," Says SHIB Lead Dev

Game Space Invest $3 Million in KEY3.id, a Permanently Free DID Protocol

MetaMask Launches Bridge Aggregator to Move Tokens Across Blockchains – Game Changer?

The Fool's Game Of Annual Crypto Price Predictions

Rally in Crypto Game Axie's AXS Token Faces Skepticism From Derivative Traders

BC.GAME is Hosting A Huge Lottery Event to Celebrate Argentina's Historic Win

Why crypto fraud is a game of whack-a-mole

first game from Shrike Tabletop is a tactical, ANTIFA-pu

Gala Games Buys Walking Dead Empires Game Studio, Token Surges 17%

Shiba Eternity Game Devs Now Accept Ideas from Users: Details

This CEO Claims SHIB Is Pyramid Scheme, John Deaton Shares Why SEC Is Wrong About XRP Status, Shiba Eternity Game Gets Upgrade: Crypto News Digest by U.Today

Augmentors

Highlights & Alerts

This is just a placeholder

highlight placeholder lorem Ipsum...

highlight lorem

This is a alert demo

Alert demo

Code Audit History

18

0

6

1

11