In the contract `Ownable`, the role `_owner` has authority over the following functions:
- renounceOwnership
- transferOwnership

In the contract `PlenaWallet`, the role `signers` has authority over the following functions:
- updateSignerStatus
- execute

In the contract `PlenaRegistry`, the role `_owner` has authority over the following functions:
- withdraw
- updateFeeRecipient

Any compromise to these accounts may allow a hacker to take advantage of this authority.

Centralization Related Risks

The contract has unlocked compiler version. An unlocked compiler version in the source code of the contract permits the user to compile it at or above a particular version. This, in turn, leads to differences in the generated bytecode between compilations due to differing compiler version numbers. This can lead to an ambiguity when debugging as compiler specific bugs may occur in the codebase that would be hard to identify over a span of multiple compiler versions rather than a specific one.

Unlocked Compiler Version

Function `registry()` is not implemented in contract `PlenaWallet`. Please make sure whether this fits your design.

Function `registry()` Not Implemented

The following inputs are missing zero address validation:
- `_registry` and `_owner` of function `initialize` in contract `PlenaWallet`
- `_feeRecipient` and `_implementation` of constructor in contract `PlenaRegistry`
- `_feeRecipient` of function `updateFeeRecipient` in contract `PlenaRegistry`

Missing Zero Address Validation

The `implementation` of `PlenaRegistry` is unchangeable, which will cause the wallet contract unable to upgrade. Please make sure whether this fits your design.

Unchangeable `implementation`

The `feeRecipient` is never used in the contract.

Unused `feeRecipient`

There is no `targets.length == datas.length` validation in function `execute`.

Missing Validation for Array Length

DelegateCall, as the name implies, is a calling mechanism of how caller contract calls target contract function but when target contract executed its logic, the context is not on the user who executes caller contract but on caller contract. So all developers should be aware of the risk that the `target` address may do harm to the current contract.
In addition, it may also cause function clashing. Refer to https://forum.openzeppelin.com/t/beware-of-the-proxy-learn-how-to-exploit-function-clashing/1070.

Potential Risk of `delegatecall`

If an attacker spoofs the signature from the signer, he is able to call the authorized function (e.g. `updateSignerStatus`, `execute`) by function `executeMetaTransaction`. If the `execute` function is called and the plenaWallet is the owner of the `target` address, the attacker is able to call the ownable functions in the `target` address. So we need to remind you that it should be very careful when signing.

Potential Risk of `executeMetaTransaction`

The function `universalDecimals` will return 18 directly, if the input ERC20 token does not have a standard function to get decimals. But it may not be 18 actually, which may lead to unpredictable problems.

Arbitrary Returned Decimals 

Plena Finance Registry

wallet

interfaces

PlenaFinanceRegistry

IERC20.sol

utils

IRegistry.sol

libs

registry

PlenaWallet.sol

UniversalERC20.sol

contracts

Clones.sol

IWallet.sol

SafeMath.sol

Ownable.sol

PlenaRegistry.sol

The amount of `250,000,000` tokens that are minted to the centralized address `owner`,  may raise the community's concerns about the centralization issue.

Token Minted To Centralized Address

Literals with many digits are difficult to read and review.

Too Many Digits

The linked variables are assigned only once, either during their contract-level declaration or during the `constructor`'s execution.

Plena Finance

Highlights & Alerts

This is just a placeholder

highlight placeholder lorem Ipsum...

highlight lorem

This is a alert demo

Alert demo

Code Audit History

10

0

7

0

3