Smart Contract
Security Audit Report

Prepared for Fusionist
Prepared by Supremacy

August 26, 2024

1

Contents

1 Introduction ............................................................................................................................ 3
1.1 About Client ...................................................................................................................... 4
1.2 Audit Scope ....................................................................................................................... 4
1.3 Changelogs ....................................................................................................................... 4
1.4 About Us ............................................................................................................................ 5
1.5 Terminology ...................................................................................................................... 5
2 Findings ................................................................................................................................... 6
2.1 Medium ............................................................................................................................. 7
2.2 Informational .................................................................................................................... 7
3 Disclaimer ................................................................................................................................ 92

1 Introduction
Given the opportunity to review the related codebase of the Fusionist’s Cross-chain
bridge, we outline in the report our systematic approach to evaluate potential security
issues in the smart contract(s) implementation, and provide recommendations forimprovement. Our results show that the given version of smart contracts can be further
improved due to the presence of several issues related to either security. This
document outlines our audit results.

3

1.1 About Client
Fusionist is a game universe with collectable NFTs comprising of three types ofgameplay: Colonize (building simulation), Conquer (turn-based tactics) and Unite(explore, expand, exploit, exterminate). Players take on the role of Mech Commanders,running their own planet(s), collecting rare resources, upgrading technology, scanning
blueprints to manufacture Mechs, and constructing production pipelines. They battle
through PvP and PvE battles, build starship ﬂeets for inter-planetary warfare, andconquer the galaxy. Endurance is Fusionist’s mainnet, social & game oriented
infrastructure layer.
Item

Description

ClientFusionist

Type

Smart Contract

Languages

Solidity

Platform

EVM-compatible

1.2 Audit Scope
In the following, we show the on-chain smart contract address used in this security
audit:• OriginalTokenBridge: 0xf3310e3f0D46FF5EE7daB69C73452D0ﬀ3979Bed• RemoteTokenBridge: 0x9d0698D9a6D01f1409AC56c5aDF62547b0055915

1.3 Changelogs
VersionDateDescription

0.1

August 23, 2024

Initial Draft

1.0

August 26, 2024

Final Release41.4 About Us
Supremacy is a leading blockchain security ﬁrm, composed of industry hackers andacademic researchers, provide top-notch security solutions through our technology
precipitation and innovative research.
We are reachable at Twitter (https://twitter.com/SupremacyHQ), or Email(contact@supremacy.email).

1.5 Terminology
For the purpose of this assessment, we adopt the following terminology. To classify theseverity of our ﬁndings, we determine the likelihood and impact (according to the CVSS
risk rating methodology).
• Likelihood represents the likelihood of a ﬁnding to be triggered or exploited inpractice• Impact speciﬁes the technical and business-related consequences of a ﬁnding• Severity is derived based on the likelihood and the impact
We categorize the ﬁndings into four distinct categories, depending on their severity.
These severities are derived from the likelihood and the impact using the following
table, following a standard risk assessment procedure.

As seen in the table above, ﬁndings that have both a high likelihood and a high impact
are classiﬁed as critical. Intuitively, such ﬁndings are likely to be triggered and causesigniﬁcant disruption. Overall, the severity correlates with the associated risk. However,every ﬁnding’s risk should always be closely checked, regardless of severity.

52 Findings
The table below summarizes the ﬁndings of the audit, including status and severity
details.
IDSeverity

Description

Status1Medium

Improper forceWithdraw logicConﬁrmed2Informational

Centralized risk

Conﬁrmed

3

Informational

Lack of comments

Conﬁrmed6

2.1 Medium
1. Improper forceWithdraw logic [Medium]
Severity: Medium

Likelihood: Medium

Impact: Medium

Status: Confirmed

Description
In the OriginalTokenBridge::forceWithdraw() function, it will transfer native assets foremergency withdrawal of user assets. However, the user’s assets transferred into
RemoteTokenBridge are ACE token, and forceWithdraw() is still used to withdraw the nativeassets.
199
200
201
202
203
204

//dev: It's only used in really urgent situations, like if the bridge getshacked. We use it to prevent any further losses.
function forceWithdraw(uint256 amount_) external nonReentrant
onlyRole(DEFAULT_ADMIN_ROLE) {address payable to = payable(msg.sender);(bool result, ) = to.call{value: amount_}("");
require(result, "Transfer failed.");}OriginalTokenBridge.sol

218
219
220
221
222

function forceWithdraw(uint256 amount_) external nonReentrant
onlyRole(DEFAULT_ADMIN_ROLE) {address payable to = payable(msg.sender);(bool result, ) = to.call{value: amount_}("");
require(result, "Transfer failed.");}

RemoteTokenBridge.sol
Recommendation: Revise the code logic as _ace.transfer(to, amount_);.

2.2 Informational
2. Centralized risk [Informational]
Status: Confirmed

Description
In cross-chain system logic, its key features are controlled by the EOA privilege account.
Including ORIGINAL_BRIDGE_VALIDATOR_ALICE, SIDE_BRIDGE_VALIDATOR_BOB,
FINANCE_VALIDATOR_CHARLIE, and DEFAULT_ADMIN_ROLE.
Our analysis shows that privileged accounts need to be scrutinized. In the following, wewill examine privileged accounts and the associated privileged access in the currentcontract.

7Note that if the privileged owner account is a plain EOA, this may be worrisome andpose counter-party risk to the protocol users. A multi-sig account could greatly alleviate
this concern, though it is still far from perfect. Speciﬁcally, a better approach is toeliminate the administration key concern by transferring the role to a communitygoverned DAO. In the meantime, a timelock-based mechanism can also be considered
as mitigation.
Recommendation: Initially onboarding could can use MPC wallets or multi-sig wallets
to initially mitigate centralization risks, but as a long-running protocol, we recommend
eventually transfer the privileged account to the intended DAO-like governancecontract. All changed to privileged operations may need to be mediated with necessary
timelocks.
Eventually, activate the normal on-chain community-based governance life-cycle andensure the intended trustless nature and high-quality distributed governance.
3. Lack of comments [Informational]
Status: Confirmed

Description
Throughout the codebase there are numerous functions missing or lacking
documentation. This hinders reviewers’ understanding of the code’s intention, which isfundamental to correctly assess not only security, but also correctness. Additionally,comments improve readability and ease maintenance. They should explicitly explain thepurpose or intention of the functions, the scenarios under which they can fail, the roles
allowed to call them, the values returned and the events emitted.
Recommendation: Consider thoroughly documenting all functions (and theirparameters) that are part of the smart contracts’ public interfaces. Functions
implementing sensitive functionality, even if not public, should be clearly documentedas well. When writing comments, consider following the Ethereum Natural Speciﬁcation
Format (NatSpec).

8

3 Disclaimer
This security audit report does not constitute investment advice or a personal
recommendation. It does not consider, and should not be interpreted as considering or
having any bearing on, the potential economics of a token, token sale or any otherproduct, service or other asset. Any entity should not rely on this report in any way,
including for the purpose of making any decisions to buy or sell any token, product,
service or other asset. This security audit report is not an endorsement of any particular
project or team, and the report does not guarantee the security of any particular
project. This audit does not give any warranties on discovering all security issues of thesmart contracts, i.e., the evaluation result does not guarantee the nonexistence of any
further ﬁndings of security issues, also cannot make guarantees about any additional
code added to the assessed project after the audit version. As one audit-based
assessment cannot be considered comprehensive, we always recommend proceedingwith independent audits and a public bug bounty program to ensure the security ofsmart contract(s). Unless explicitly speciﬁed, the security of the language itself (e.g., thesolidity language), the underlying compiling toolchain and the computing infrastructure
are out of the scope.

9