JPYC contest - peritoflores's results

World-leading Japanese Yen Stablecoin.

General Information

Platform: Code4rena

Start Date: 24/02/2022

Pot Size: $30,000 USDC

Total HM: 0

Participants: 28

Period: 3 days

Judge: Jack the Pug

Id: 95

League: ETH

JPYC

Findings Distribution

Researcher Performance

Rank: 10/28

Findings: 2

Award: $913.22

🌟 Selected for report: 0

🚀 Solo Findings: 0

Awards

873.3805 USDC - $873.38

Labels

bug
QA (Quality Assurance)
resolved

External Links

QA (Low and NC) report to JPYC by PeritoFlores

Transfer Ownership pattern incomplete implementation

In function _transferOwnership#Ownable.sol

function _transferOwnership(address newOwner) internal virtual { @audit using transfer ownership address oldOwner = _owner; _owner = newOwner; emit OwnershipTransferred(oldOwner, newOwner); }

It seems that you tried to implement two-step ownership transfer to make it safer. It is a good idea to add the function acceptOwnership() to complete the pattern.

Rescuer uninialitized at FiatTokenV2

In the function initialize()#FiatTokenV2.sol rescuer in never initialized so it is zero at deployment time.

Consider calling updateRescuer() inside initialize()

Lack emit event after rescueERC20()

In rescuer.sol the function rescueERC20() lacks an event emit.

function rescueERC20( IERC20 tokenContract, address to, uint256 amount ) external onlyRescuer { tokenContract.safeTransfer(to, amount); @audit emit event }

Consider adding it

Typo error

At EIP3009.sol#L227 there is a typo error

`"FEIP3009: authorization is not yet valid" `

It says "FEIP" instead of "EIP"

Consider using inheritance when using upgradeable contracts

When using upgradeable contracts it is recommended that the new version inherits from previous. One of the reason for that is that you avoid storage collision. A minimum error in the order of parameters on the new version could break the protocol.

Maybe you can consider for the next version something like

contract FiatTokenV3 is FiatTokenV2

#0 - retocrooman

2022-03-02T03:34:53Z

Lack emit event after rescueERC20()

There is no problem because the Transfer Event of the specified ERC20 fires.

Typo error

Thank you for noticing the typo!

Consider using inheritance when using upgradeable contracts

We agree. We also think that if it can be inherited, and it should be inherited. For this time, the reason why we did not inherit FiatTokenV1 in FiatTokenV2 is because we want to add the "whitelist" check into the existing functions.

#1 - thurendous

2022-03-29T02:57:03Z

At EIP3009.sol#L227 there is a typo error

Typo fixed and thanks!

Final change can be viewed here.

Findings Information

Awards

39.8369 USDC - $39.84

Labels

bug
G (Gas Optimization)

External Links

Gas Optimization for JPYC by PeritoFlores

Unnecessary initialization of some variables

The following variables are initialized to zero. Consider removing .

https://github.com/code-423n4/2022-02-jpyc/blob/cfc018384dd1d71febaa57f0576cb51f5d9c7e07/contracts/v1/Pausable.sol#L49

https://github.com/code-423n4/2022-02-jpyc/blob/cfc018384dd1d71febaa57f0576cb51f5d9c7e07/contracts/v1/FiatTokenV1.sol#L58

https://github.com/code-423n4/2022-02-jpyc/blob/cfc018384dd1d71febaa57f0576cb51f5d9c7e07/contracts/v2/FiatTokenV2.sol#L58

Use "delete" keyword instead to assigning to zero

minterAllowed[minter] = 0; FiatTokenV2.sol#L361

Replace for

delete(minterAllowed[minter]);

Same issue at FiatTokenV1#L350

#0 - retocrooman

2022-03-02T02:50:38Z

Unnecessary initialization of some variables

Duplicate of #2

Use "delete" keyword instead to assigning to zero

We need to check if these are ture. If they are true we will fix them.

AuditHub

A portfolio for auditors, a security profile for protocols, a hub for web3 security.

Built bymalatrax © 2024

Auditors

Browse

Contests

Browse

Get in touch

ContactTwitter