Public

SMART CONTRACT AUDIT REPORT
forStablecoin Contract

Prepared By: Xiaomi Huang
PeckShield
May 10, 2023

1/16

PeckShield Audit Report #: 2023-087

Public

Document Properties
ClientTitle
TargetVersionAuthor
Auditors
Reviewed byApproved byClassification

FD121 LIMITED
Smart Contract Audit Report
Stablecoin Contract
1.0
Patrick Lou
Patrick Lou, Xuxian Jiang
Xiaomi Huang
Xuxian Jiang
PublicVersion InfoVersion
1.0
1.0

Date
May 10, 2023
April 19, 2023

AuthorPatrick Lou
Patrick Lou

Description
Final Release (Amended #1)
Final Release

Contact
For more information about this document and its contents, please contact PeckShield Inc.

NamePhone
Email2/16

Xiaomi Huang+86 183 5897 7782
contact@peckshield.com

PeckShield Audit Report #: 2023-087

Public

Contents

1 Introduction

4

1.1

About Stablecoin Contract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

1.2

About PeckShield . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

51.3

Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

51.4Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

72 Findings

82.1

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

82.2

Key Findings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

93 ERC20/BEP20 Compliance Checks

104 Detailed Results

13

4.1

Trust Issue Of Admin Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

5 Conclusion

15References

16

3/16

PeckShield Audit Report #: 2023-087

Public

1 | Introduction
Given the opportunity to review the design document and related source code of the FD121 LIMITED
Stablecoin token contract, we outline in the report our systematic method to evaluate potential

security issues in the smart contract implementation, expose possible semantic inconsistency between
smart contract code and the documentation, and provide additional suggestions or recommendations
for improvement. Our results show that the given version of the smart contract can be further
improved due to the presence of certain issues related to either security or performance. This
document outlines our audit results.

1.1

About Stablecoin Contract

Stablecoin is the token issued by FD121 LIMITED. It is upgradeable ERC20 token which the owner canmint and burn tokens, pause the contract and freeze the specific user action.
The basic information of the audited Stablecoin token is as follows:
Table 1.1: Basic Information Of Stablecoin Contract
ItemName
TypePlatform
Audit Method
Audit Completion Date

Description
FD121 LIMITEDERC20 Token Contract
Solidity
Whitebox
May 10, 2023

In the following, we show the Git repository of reviewed files and the commit hash value used inthis audit.
• https://github.com/FD-121/fd-stablecoin/blob/main/src/Stablecoin.sol (ec35f7c)

4/16

PeckShield Audit Report #: 2023-087

Public1.2

About PeckShield

PeckShield Inc. [4] is a leading blockchain security company with the goal of elevating the security,privacy, and usability of current blockchain ecosystem by offering top-notch, industry-leading services and products (including the service of smart contract auditing). We are reachable at Telegram(https://t.me/peckshield), Twitter (http://twitter.com/peckshield), or Email (contact@peckshield.com).

1.3

Methodology

To standardize the evaluation, we define the following terminology based on OWASP Risk Rating
Methodology [3]:• Likelihood represents how likely a particular vulnerability is to be uncovered and exploited inthe wild;• Impact measures the technical loss and business damage of a successful attack;• Severity demonstrates the overall criticality of the risk;
Likelihood and impact are categorized into three ratings: H, M and L, i.e., high, medium andlow respectively. Severity is determined by likelihood and impact and can be classified into four
categories accordingly, i.e., Critical, High, Medium, Low shown in Table 1.2.

ImpactTable 1.2: Vulnerability Severity Classification
High

CriticalHigh

MediumMediumHigh

MediumLow

Low

Medium

Low

Low

High

MediumLow

Likelihood

We perform the audit according to the following procedures:• Basic Coding Bugs: We first statically analyze given smart contracts with our proprietary static
code analyzer for known coding bugs, and then manually verify (reject or confirm) all the issues
found by our tool.

5/16

PeckShield Audit Report #: 2023-087

Public• ERC20 Compliance Checks: We then manually check whether the implementation logic of theaudited smart contract(s) follows the standard ERC20 specification and other best practices.
• Additional Recommendations: We also provide additional suggestions regarding the coding anddevelopment of smart contracts from the perspective of proven programming practices.
Table 1.3: The Full List of Check Items
Category

Basic Coding Bugs

ERC20 Compliance Checks

Additional Recommendations

Check Item
Constructor Mismatch
Ownership Takeover
Redundant Fallback Function
Overflows & Underflows
Reentrancy
Money-Giving Bug
Blackhole
Unauthorized Self-Destruct
Revert DoS
Unchecked External Call
Gasless Send
Send Instead of Transfer
Costly Loop
(Unsafe) Use of Untrusted Libraries(Unsafe) Use of Predictable Variables
Transaction Ordering Dependence
Deprecated Uses
Approve / TransferFrom Race Condition
Compliance Checks (Section 3)
Avoiding Use of Variadic Byte Array
Using Fixed Compiler Version
Making Visibility Level Explicit
Making Type Inference Explicit
Adhering To Function Declaration Strictly
Following Other Best Practices

To evaluate the risk, we go through a list of check items and each would be labeled with a severity
category. For one check item, if our tool does not identify any issue, the contract is considered safe
regarding the check item. For any discovered issue, we might further deploy contracts on our private
testnet and run tests to confirm the findings. If necessary, we would additionally build a PoC todemonstrate the possibility of exploitation. The concrete list of check items is shown in Table 1.3.

6/16

PeckShield Audit Report #: 2023-087

Public

1.4

Disclaimer

Note that this security audit is not designed to replace functional tests required before any software
release, and does not give any warranties on finding all possible security issues of the given smart
contract(s) or blockchain software, i.e., the evaluation result does not guarantee the nonexistenceof any further findings of security issues. As one audit-based assessment cannot be considered
comprehensive, we always recommend proceeding with several independent audits and a public bug
bounty program to ensure the security of smart contract(s). Last but not least, this security audit
should not be used as investment advice.

7/16

PeckShield Audit Report #: 2023-087

Public

2 | Findings

2.1

Summary

Here is a summary of our findings after analyzing the Stablecoin token contract. During the firstphase of our audit, we study the smart contract source code and run our in-house static code analyzer through the codebase. The purpose here is to statically identify known coding bugs, and thenmanually verify (reject or confirm) issues reported by our tool. We further manually review business logics, examine system operations, and place ERC20-related aspects under scrutiny to uncoverpossible pitfalls and/or bugs.

Severity# of Findings

Critical0

High0Medium1Low

0

Informational0

Total

1

Moreover, we explicitly evaluate whether the given contracts follow the standard ERC20 specification and other known best practices, and validate its compatibility with other similar ERC20 tokens
and current DeFi protocols. The detailed ERC20 compliance checks are reported in Section 3. After
that, we examine a few identified issues of varying severities that need to be brought up and paid
more attention to. (The findings are categorized in the above table.) Additional information can befound in the next subsection, and the detailed discussions are in Section 4.

8/16

PeckShield Audit Report #: 2023-087

Public2.2

Key Findings

Overall, no ERC20 compliance issue was found, and our detailed checklist can be found in Section 3.
Also, though current smart contracts are well-designed and engineered, the implementation anddeployment can be further improved by resolving the identified issue (shown in Table 2.1), including
1 medium-severity vulnerability.

Table 2.1: Key Stablecoin Contract Audit Findings
ID
PVE-001

SeverityMediumTitle
Trust Issue Of Admin Keys

Category
Security Features

StatusMitigated

Beside the identified issue, we emphasize that for any user-facing applications and services, it isalways important to develop necessary risk-control mechanisms and make contingency plans, which
may need to be exercised before the mainnet deployment. The risk-control mechanisms should kickin at the very moment when the contracts are being deployed on mainnet. Please refer to Section 4for details.

9/16

PeckShield Audit Report #: 2023-087

Public

3 | ERC20/BEP20 Compliance
ChecksThe ERC20 specification defines a list of API functions (and relevant events) that each token contract
is expected to implement (and emit). The failure to meet these requirements means the token
contract cannot be considered to be ERC20-compliant. Naturally, as the first step of our audit, we
examine the list of API functions defined by the ERC20 specification and validate whether there
exist any inconsistency or incompatibility in the implementation or the inherent business logic of theaudited contract(s).
Table 3.1: Basic View-Only Functions Defined in The ERC20 Specification
Item
name()
symbol()decimals()

totalSupply()balanceOf()

allowance()

Description
Is declared as a public view function
Returns a string, for example “Tether USD”
Is declared as a public view function
Returns the symbol by which the token contract should be known, forexample “USDT”. It is usually 3 or 4 characters in length
Is declared as a public view function
Returns decimals, which refers to how divisible a token can be, from 0(not at all divisible) to 18 (pretty much continuous) and even higher if
requiredIs declared as a public view function
Returns the number of total supplied tokens, including the total mintedtokens (minus the total burned tokens) ever since the deployment
Is declared as a public view function
Anyone can query any address’ balance, as all data on the blockchain ispublic
Is declared as a public view function
Returns the amount which the spender is still allowed to withdraw fromthe ownerStatus✓✓✓✓✓✓✓✓✓✓✓✓

Our analysis shows that there is no ERC20 inconsistency or incompatibility issue found in the10/16

PeckShield Audit Report #: 2023-087

Public

Table 3.2: Key State-Changing Functions Defined in The ERC20 Specification
Itemtransfer()transferFrom()

approve()

Transfer() event
Approval() event

11/16

Description
Is declared as a public function
Returns a boolean value which accurately reflects the token transfer status
Reverts if the caller does not have enough tokens to spend
Allows zero amount transfers
Emits Transfer() event when tokens are transferred successfully (include 0amount transfers)
Reverts while transferring to zero address
Is declared as a public function
Returns a boolean value which accurately reflects the token transfer status
Reverts if the spender does not have enough token allowances to spend
Updates the spender’s token allowances when tokens are transferred successfully
Reverts if the from address does not have enough tokens to spend
Allows zero amount transfers
Emits Transfer() event when tokens are transferred successfully (include 0amount transfers)
Reverts while transferring from zero address
Reverts while transferring to zero address
Is declared as a public function
Returns a boolean value which accurately reflects the token approval status
Emits Approval() event when tokens are approved successfully
Reverts while approving to zero address
Is emitted when tokens are transferred, including zero value transfers
Is emitted with the from address set to 𝑎𝑑𝑑𝑟𝑒𝑠𝑠(0𝑥0) when new tokens
are generated
Is emitted on any successful call to approve()Status✓✓✓✓✓PeckShield Audit Report #: 2023-087

✓
✓✓
✓✓✓
✓✓✓✓
✓✓✓✓✓✓✓

Publicaudited Stablecoin Contract. In the surrounding two tables, we outline the respective list of basic
view-only functions (Table 3.1) and key state-changing functions (Table 3.2) according to the widely-adopted ERC20 specification. In addition, we perform a further examination on certain features thatare permitted by the ERC20 specification or even further extended in follow-up refinements andenhancements (e.g., ERC777/ERC2222), but not required for implementation. These features are
generally helpful, but may also impact or bring certain incompatibility with current DeFi protocols.
Therefore, we consider it is important to highlight them as well. This list is shown in Table 3.3.
Table 3.3: Additional Opt-in Features Examined in Our Audit
FeatureDeflationary
Rebasing
Pausable
Blacklistable

Mintable
Burnable

12/16

Description
Part of the tokens are burned or transferred as fee while on transfer()/transferFrom() calls
The balanceOf() function returns a re-based balance instead of the actual
stored amount of tokens owned by the specific addressThe token contract allows the owner or privileged users to pause the token
transfers and other operations
The token contract allows the owner or privileged users to blacklist aspecific address such that token transfers and other operations related tothat address are prohibited
The token contract allows the owner or privileged users to mint tokens toa specific address
The token contract allows the owner or privileged users to burn tokens ofa specific address

Opt-in——✓✓✓✓PeckShield Audit Report #: 2023-087

Public

4 | Detailed Results
4.1

Trust Issue Of Admin Keys

• ID: PVE-001• Target: Stablecoin• Severity: Medium• Category: Security Features [2]• Likelihood: Low• CWE subcategory: CWE-287 [1]• Impact: HighDescription
In the Stablecoin token contract, there is a privileged account, i.e., owner, which plays a criticalrole in governing and regulating the token-related operations. In particular, it has the privilege tomint additional tokens into circulation, burn the tokens, blacklist a specific address and pause thetoken transfers and other operations. Our analysis shows that the privileged account needs to bescrutinized. In the following, we examine the privileged owner account and its related privileged accessin current contract.
404142434445464748495051525354555657

function mint ( uint256 amount ) external onlyOwner returns ( bool ) {_mint ( _msgSender () , amount ) ;emit Mint ( _msgSender () , _msgSender () , amount ) ;return true ;}/* ** @dev See { ERC20 - _burn }.
* @param amount Burn amount* @return True if successful* Can only be called by the current owner .
*/function burn ( uint256 amount ) external onlyOwner returns ( bool ) {_burn ( _msgSender () , amount ) ;emit Burn ( _msgSender () , _msgSender () , amount ) ;return true ;}13/16

PeckShield Audit Report #: 2023-087

Public
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82

/* *
* @dev Adds account to frozen state .
* Can only be called by the current owner .
*/function freeze ( address account ) external onlyOwner {frozen [ account ] = true ;emit Freeze ( _msgSender () , account ) ;}/* ** @dev Removes account from frozen state .
* Can only be called by the current owner .
*/function unfreeze ( address account ) external onlyOwner {delete frozen [ account ];emit Unfreeze ( _msgSender () , account ) ;}/* ** @dev Triggers stopped state .
* Can only be called by the current owner .
*/function pause () external onlyOwner {_pause () ;}Listing 4.1:

Stablecoin::Multiple Functions

To elaborate, we show above the related sensitive operation that is related to owner. We understand the need of the privileged functions for contract maintenance, but it is worrisome if theprivileged owner account is a plain EOA account. Note that a multi-sig account could greatly alleviate
this concern, though it is still far from perfect. Specifically, a better approach is to eliminate theadministration key concern by transferring the role to a community-governed DAO.
Recommendation

Promptly transfer the privileges of the owner to the intended governancecontract. And activate the normal on-chain community-based governance life-cycle and ensure theintended trustless nature and high-quality distributed governance.
Status This issue has been mitigated, the team confirms that multi-sig account will be used.

14/16

PeckShield Audit Report #: 2023-087

Public

5 | Conclusion
In this security audit, we have examined the design and implementation of the Stablecoin token
contract. During our audit, we first checked all respects related to the compatibility of the ERC20
specification and other known ERC20 pitfalls/vulnerabilities. We then proceeded to examine otherareas such as coding practices and business logics. Overall, although no critical or high level vulnerabilities were discovered, we identified one issue of medium severity. In the meantime, as disclaimed inSection 1.4, we appreciate any constructive feedbacks or suggestions about our findings, procedures,audit scope, etc.

15/16

PeckShield Audit Report #: 2023-087

PublicReferences[1] MITRE. CWE-287: Improper Authentication. https://cwe.mitre.org/data/definitions/287.html.
[2] MITRE. CWE CATEGORY: 7PK - Security Features. https://cwe.mitre.org/data/definitions/254.html.
[3] OWASP. Risk Rating Methodology. https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology.
[4] PeckShield. PeckShield Inc. https://www.peckshield.com.

16/16

PeckShield Audit Report #: 2023-087