myXRP

Contract audit · 컨트랙트 감사

Claude Sonnet

claude-sonnet-5-5-high

4 October 2026 · MyXRPBridge on Flare

Review note, 4 October 2026

I am Claude Sonnet (claude-sonnet-5-5-high). This is my own reading of the contract source. I looked at one thing: whether the numbers for lock, mint, burn and room agree with each other in every state the code can reach. It is not a summary of another reviewer's letter.

Contract. MyXRPBridge at 0x14b9DD90edaAff6527c1b168550B3FAA15b9F6AF on Flare mainnet, chain id 14. The underlying is official FXRP 0xAd552A648C74D49E10027AB8a618A3ad4901c5bE. That address cannot take USDT. name() and the symbol are myXRP. Decimals are 6.

Scope: this contract only

The myXRP website describes the desk and the cabinet as custodial. That is a different object from this contract. This letter reviews only the bridge contract. It says nothing about how the desk or the cabinet holds or books anything.

How the accounting works

Three variables carry the whole design: the FXRP balance the contract holds, totalSupply, and the per-address balanceOf map. The immutable maxAssets is the ceiling.

• Deposit. It pulls FXRP in with transferFrom, then raises totalSupply and the caller's balanceOf by the same amount. It emits a mint-style Transfer from the zero address.
• Burn (withdraw). It lowers the caller's balance and totalSupply by the same amount, emits a burn-style Transfer, and sends the same FXRP back in that transaction.
• Transfers. They move myXRP between holders and change neither totalSupply nor the FXRP held.

Those are the only places totalSupply is written. Every path that raises it also raises the FXRP held by the same amount, and every path that lowers it lowers the FXRP held by the same amount. So the FXRP held is never below totalSupply, and totalSupply equals the sum of all balances. This assumes FXRP behaves as a plain ERC-20 with no transfer fee. I found no write path that breaks the invariant.

There is no operator role, no owner, no pause, no upgrade hook, no operatorWithdraw and no accrual. The receipt does not compound. The contract is not a vault. Once deployed, the only ways FXRP leaves are the burn path and nothing else.

Room and the ceiling

maxAssets is 10,000,000.000000 FXRP. That figure is the ceiling, not an amount already issued. Deposit reverts when totalSupply + amount would exceed it, so totalSupply can never pass the ceiling. A deposit that lands exactly on it is allowed. room() returns the ceiling minus totalSupply, or zero at the ceiling. Burning myXRP lowers totalSupply and gives that room back. Solidity 0.8 checked arithmetic covers the supply math. The one unchecked block, inside the internal transfer, is safe because no balance can exceed totalSupply, which is capped at maxAssets.

Buying opened on 1 October 2026 at 00:00 Asia/Seoul. The constant OPENS_AT is 1,790,780,400. I checked that value by hand and it is 15:00:00 UTC on 30 September 2026, which is that Seoul minute. No function can change it. Burn is not gated by that time, which is harmless because nobody holds myXRP before the opening.

Findings

I found no Critical, High or Medium issue. The items below are Low or Informational, and each follows from the code as written.

• S-01. Deposit trusts the return value of transferFrom and credits amount. It does not compare the contract's FXRP balance before and after. With official FXRP, which has no transfer fee, the two are equal. The underlying is immutable, so this cannot change by an admin action. It would matter only if FXRP itself changed how it moves tokens. A balance-delta check would close it.
• S-02. A spender can use an old allowance and a new one if the holder changes an allowance from one non-zero value to another. This is the usual ERC-20 behaviour. Holders can set the allowance to zero first.
• S-03. FXRP transferred directly to the contract is not minted against and cannot be withdrawn, because no function reaches it. It does not use up any room and does not break the invariant. It only makes the held balance larger than totalSupply.
• S-04. The ceiling applies to myXRP outstanding at one moment. It is not a cap on how much passes through over time. Readers should not take maxAssets as total ever issued.
• S-05. The internal transfer blocks the zero address but not the contract's own address. myXRP sent there stays in that balance, the matching FXRP stays locked, and nothing else changes.
• S-06. Burn checks that the contract holds enough FXRP. Under the invariant this check cannot fail, so it only guards against FXRP behaving unexpectedly. If FXRP were ever to block or pause transfers, burn would revert until that stopped. The contract has no say in that. Burn updates its state before the external call and is behind a reentrancy guard.
• S-07. The 6 decimals match FXRP today. The constructor does not check them. The underlying is fixed at deploy, so this is a documentation point.

Conclusion

On the accounting questions I was asked about, the code does what the public description says. A deposit locks FXRP and mints the same myXRP. A burn returns the same FXRP in the same transaction. Room cannot go below zero or above the ceiling. No key sits above the lock. This is a statement about the source I read, not a promise about price, yield or any future state of FXRP.

What I did not check

I read the Solidity source and reasoned about it by hand. I did not run a fuzzer or a formal prover. I did not compare the deployed bytecode with the source byte for byte, and I did not read the live totalSupply, the live FXRP balance or any on-chain history. I did not review the FXRP contract or Flare's own rules for it. I did not check front-end code, the website, the desk, the cabinet or any off-chain system. I did not test gas behaviour, compiler settings or chain-level risks such as reorgs and validator behaviour. Anything outside the single contract named above is outside this review.