ETH_xEuro_report.md

xEuro Token Audit Report.

1. Summary

This document is a security audit report performed by RideSolo, where xEuro Token has been reviewed.

2. In scope

• xEuro Contract.

3. Findings

7 issues were reported:

• 2 medium severity issues.
• 5 low severity issues.

3.1. Tokens Buy Back

Severity: medium

Description

Token that are sent back to the contract address are logged and an event is emitted to the UI to process the exchange from tokens to fiat offchain, if the payment does not succeed the tokens should be at least sent back to the user however no function is intended to reimburse the users (fiat payment may not succeed for different reasons), only the success case is treated since the tokens can be burned later on using burnTokens with fiatOutPaymentId that should represent the payment made offchain to the user.

Code snippet

https://gist.github.com/RideSolo/cd69639424c60572fe5e0f3cb3596418#file-xeuro-sol-L262

3.2. Token Minting and Transfer

Severity: medium

Description

To mint token using mintTokens function a fiatInPaymentId should be added as input parameters meaning that an external fiat payment was received by the team and the equivalent tokens should be given to a specific address that belongs to the person that made the fiat payment.

Only specific addresses allowed through canMint can mint tokens, and only addresses allowed through canTransferFromContract can call transferFrom to transfer the minted tokens to their benificiary by setting the from address to the contract address and the _to address to the destination address.

• an address that is in both canMint and canTransferFromContract will be able to mint and transfer tokens to the receiver.
• an address that is only in canMint will only be able to mint tokens (please note that the minted tokens are address to the contract address balance at first.)
• an address that is in canTransferFromContract will be able to transfer any tokens that are allocated to the contract address to any address even if the minted tokens where minted to be transfered to a specific address, if the developers have taken this into account they should bear all the responsability if any added address take all the contract address balance, if this issue was not intended then it should be fixed asap.

Code snippet

https://gist.github.com/RideSolo/cd69639424c60572fe5e0f3cb3596418#file-xeuro-sol-L589

https://gist.github.com/RideSolo/cd69639424c60572fe5e0f3cb3596418#file-xeuro-sol-L602

https://gist.github.com/RideSolo/cd69639424c60572fe5e0f3cb3596418#file-xeuro-sol-L256

Recommendation

As soon as mintTokens is used the tokens should be assigned to the person that made the fiat payment offline and not to the contract address, this two steps mechanism make every one at risk.

3.3. Missing Events

Severity: low

Description

Transfer event should be emitted when mintTokens is used, the event can show a transfer event from address(0) to the contract address for this case. When tokens are burned using burnTokens a Transfer event should be emitted from the contract address to address(0). This is required by dapps that track users balances.

Code Snippet

https://gist.github.com/RideSolo/cd69639424c60572fe5e0f3cb3596418#file-xeuro-sol-L587

https://gist.github.com/RideSolo/cd69639424c60572fe5e0f3cb3596418#file-xeuro-sol-L722

3.4. Owner Privileges

Severity: owner privileges

Description

• Token minting using mintTokens does not guarantee any real investment since the payment are made offchain, meaning that is an address receive enough privileges it will be able to mint without real payment.
• Token minting is not capped, this present more risks to investors especialy knowing that minting fiatInPaymentId that is supposed to be made offchain is not guaranteed by anyway.
• Tokens sent back to the contract address to be exchanged are burned once the supposed payment is done to the user, however nothing guarantee the payment except the team.

Code snippet

https://gist.github.com/RideSolo/cd69639424c60572fe5e0f3cb3596418#file-xeuro-sol-L587

https://gist.github.com/RideSolo/cd69639424c60572fe5e0f3cb3596418#file-xeuro-sol-L105#L120

3.5 Administrators Addresses Managment

Severity: owner privileges

Description

Any admin address added through addAdmin will be able to remove all other admins addresses, addAdmin and removeAdmin function execution should be allowed for execution to a different group than admin group.

Code snippet

https://gist.github.com/RideSolo/cd69639424c60572fe5e0f3cb3596418#file-xeuro-sol-L365

https://gist.github.com/RideSolo/cd69639424c60572fe5e0f3cb3596418#file-xeuro-sol-L391

3.6. Token Approval

Severity: low

Description

Using the overloaded approval function do not solve the double withdrawal attack since the ERC20 requirement do not state such function and is not implemented in most Dapps.

Code snippet

https://gist.github.com/RideSolo/cd69639424c60572fe5e0f3cb3596418#file-xeuro-sol-L227

3.7. Known vulnerabilities of ERC-20 token

Severity: low

Description

1. It is possible to double withdrawal attack. More details here
2. Lack of transaction handling mechanism issue. WARNING! This is a very common issue and it already caused millions of dollars losses for lots of token users! More details here

Conclusion

The audited contract need many interactions from the different managment groups, when it can be simplified for better user trust. Dapp should be trustless by nature if to implement such a centralized application, ethereum blockchain is not required. Fiat payment can be simulated by updating the ETH/USD price using oraclize service or any other trusted third party so investors won't have issues when it comes to trusting this Dapp.

All the raised issues should be fixed before deployment.