Contract audit · 컨트랙트 감사

Gemini

gemini-3.8

4 October 2026 · MyXRPBridge on Flare

1. Review Scope and On-Chain Parameters

This technical audit letter provides an evaluation of the MyXRPBridge contract by Gemini (gemini-3.8), dated 4 October 2026. The review examines the deployed bytecode on Flare mainnet, evaluating asset admission, operational boundaries, and systems sitting outside the bytecode.

The contract deployment parameters and verified state are recorded as follows:

Contract: MyXRPBridge at 0x14b9DD90edaAff6527c1b168550B3FAA15b9F6AF
Network: Flare mainnet (Chain ID 14)
Underlying Asset: Official FXRP at 0xAd552A648C74D49E10027AB8a618A3ad4901c5bE
Token Identity: name() and symbol() return myXRP; decimals are 6
Deposit Ceiling (maxAssets): 10,000,000.000000 FXRP
Opening Time (OPENS_AT): 1,790,780,400 (1 October 2026 00:00 Asia/Seoul)

The ceiling parameter maxAssets is 10,000,000.000000 FXRP. That figure is the ceiling, not an amount already issued. The timestamp confirmed that buying opened 1 October 2026 00:00 Asia/Seoul.

The review scope is strictly bounded to the smart contract bytecode. The website's custodial desk and cabinet are a different object. This letter reviews only the contract. Off-chain infrastructure, custodial desks, and user cabinets sit entirely outside this bytecode. This review does not invent or evaluate any company number, office, licence, or yield, and recognizes no wallet addresses other than the contract and official FXRP.

2. Asset Acceptance and Rejection Boundaries

A central focus of this audit is determining what assets the contract will accept, what it will refuse, and how edge cases behave.

The contract accepts exclusively official FXRP at 0xAd552A648C74D49E10027AB8a618A3ad4901c5bE. This dependency is fixed as an immutable variable at deployment. When a user calls deposit(amount), the contract executes a transferFrom call to this immutable FXRP address.

All other assets are refused or structurally incompatible:

Rejection of USDT and Alternative Tokens: The contract contains no method to accept Tether USD (USDT) or other ERC-20 tokens. Furthermore, the underlying FXRP address cannot take USDT. The bridge cannot mint against USDT or process it in any capacity.
Rejection of Native FLR: The contract declares no receive() or payable fallback() functions. Direct native FLR transfers revert immediately.
Stranding of Unsolicited Transfers: Sending another token to the contract strands it. If a user transfers FXRP, USDT, or another token directly to the contract address without calling deposit(), the assets become permanently locked. The contract contains no sweep, rescue, or recovery functions.
Input Constraints: Calls to deposit() revert with ZeroAmount() if the amount is zero, with NotOpen() if submitted before the opening timestamp, and with CapExceeded() if the deposit pushes total supply beyond maxAssets.

3. Minting, Redemption, and Parity Mechanics

The contract implements a direct 1:1 wrapper without fee deductions or variable valuation.

Deposit locks FXRP and mints the same amount of myXRP. Burn returns the same FXRP in that transaction. Both processes execute atomically. Because both tokens use six decimals, one unit of FXRP maps precisely to one unit of myXRP.

Key structural properties include:

No Compounding: The receipt does not compound. There is no yield accumulator, rebasing schedule, or internal rate adjustment. One myXRP permanently redeems for one FXRP.
Not a Vault: Do not call this contract a vault. It does not implement ERC-4626 vault standards, maintains no investment strategies, charges no management fees, and generates no return. It functions solely as a reserve-backed bridge token.
Restoration of Room: The public room() function reports remaining mint capacity under the ceiling. When tokens are burned via withdraw(), capacity returns dynamically up to the 10,000,000.000000 FXRP ceiling.

4. Privilege Architecture and Autonomous Operation

Bytecode analysis confirms that the contract operates completely autonomously without administrative privileges.

No Operator Key: The contract possesses no owner, admin, or privileged role. No entity can modify parameters or pause execution.
No Privileged Withdrawals: There is no operatorWithdraw function, backdoor, or migration method. Assets leave the contract only when a user burns their own myXRP.
No Upgradeability: The bytecode contains no proxy patterns or delegatecall dispatchers. The logic is immutable.
Reentrancy Guard: Both state-modifying endpoints utilize a non-reentrant mutex (locked), preventing reentrancy attacks during external calls.

5. Scope Delineation: Bytecode vs. External Systems

To avoid ambiguity, this review defines the boundary between smart contract logic and external components.

The Custodial Desk and Cabinet: The website's custodial desk and user cabinet are separate off-chain mechanisms. The contract functions independently of web portals, off-chain accounting, or institutional desks.
External FXRP Dependencies: The contract relies on the liveness of the official FXRP contract at 0xAd552A648C74D49E10027AB8a618A3ad4901c5bE. If the external FXRP system pauses or halts transfers, bridge redemptions will revert until upstream functionality resumes.
Yield and Commercial Terms: The contract does not generate or distribute yield. Any financial return discussed on external sites sits outside this bytecode.

6. Findings

Static analysis identified no critical or high-severity vulnerabilities. Findings are categorized below:

ID	Severity	Title	Note
GEM-01	Medium	Upstream Dependency on FXRP Liveness	Redemptions require successful calls to `0xAd552A648C74D49E10027AB8a618A3ad4901c5bE`. If FXRP transfers are paused upstream, bridge operations revert.
GEM-02	Low	Irretrievability of Misdirected Tokens	Direct transfers of assets to the contract address bypass `deposit()` and strand funds permanently due to the deliberate lack of an admin rescue function.
GEM-03	Low	Nominal Parameter Accounting	`deposit()` credits `amount` without verifying balance deltas. This is safe with standard FXRP, but would cause accounting divergence if a transfer fee were introduced.
GEM-04	Low	Standard ERC-20 Allowance Concurrency	`approve()` implements standard ERC-20 allowance behavior without atomic increase/decrease helpers or EIP-2612 permit functionality.
GEM-05	Informational	Circulating Ceiling vs. Lifetime Issuance	The `maxAssets` cap limits concurrent circulating supply. Because redemptions replenish available room, cumulative volume over time may exceed 10 million.

7. Verification Limits and Non-Executed Operations

This assessment concludes with explicit documentation of actions not executed on chain:

No Live Mainnet State Modifications: No transactions were submitted from reviewer accounts to execute live deposits, withdrawals, or token approvals with real funds.
No Local Toolchain Recompilation: Independent compilation from Solidity source via local solc was not performed; bytecode analysis relied on RPC inspection and explorer verification records.
No Off-Chain System Testing: No penetration testing or code review was performed on the website's custodial desk, cabinet servers, or database infrastructure.
No Cross-Chain Collateral Auditing: No simulation was conducted regarding underlying collateral mechanisms within the broader Flare FAssets network.