myXRP
Grok

Contract audit · 컨트랙트 감사

Grok

grok-4.7

3 October 2026 · MyXRPBridge on Flare

Contract: MyXRPBridge
Network: Flare mainnet, chain id 14
Address: 0x14b9DD90edaAff6527c1b168550B3FAA15b9F6AF
Underlying: official FXRP 0xAd552A648C74D49E10027AB8a618A3ad4901c5bE
Compiler on the explorer: solc 0.8.28, optimizer on, 200 runs, EVM target paris
Runtime size: 2,917 bytes
Read: 3 October 2026, Flare public RPC and the Flare explorer

1. What this page is

This is a review of one deployed contract. It asks whether the code at that address does what a 1:1 wrapper should do, who can move the FXRP it holds, and what a holder of myXRP still has to accept. It is not a review of the cabinet, the pool report, any company, or any licence. Those are not in the bytecode.

The address above is the whole scope. Another contract that also answers name() = "myXRP" is a different contract. A reader should match the address, not the ticker.

2. What the chain shows

CallValue
name() / symbol()myXRP / myXRP
decimals()6, the same as FXRP
underlying()the official FXRP address above
maxAssets()10,000,000.000000
totalSupply()25.000000
room()9,999,975.000000
FXRP balance of the bridge25.000000
OPENS_AT()1,790,780,400 — 1 October 2026, 00:00 Asia/Seoul

The explorer lists the contract as verified, not a proxy, compiler 0.8.28. The creation transaction is 0xee361ab34728ed5a817ff9db70b67573ff02f029ae47a8b7e0242e9bec4485e5, four seconds after OPENS_AT, from 0x998718199D8aF65ed3a1cb03cfEc2faF7c301eFb. That account has no role afterwards, because the contract records none.

Three user transactions follow, all on 30 September 2026: a deposit of 25.000000, a withdrawal of the same amount, and a deposit of 25.000000 again. Each FXRP movement matches the myXRP movement in the same transaction. A simulated withdraw of the full 25.000000 from the holder succeeds. One unit more reverts.

underlying and maxAssets are immutables. OPENS_AT is a literal in the bytecode. None of the three can be changed.

3. What the code does

The contract is a sealed wrapper on one chain. It is not a vault, not a yield token, and not a message bridge. There is no relayer, no oracle, no share price, and no fee.

Both deposit and withdraw share one reentrancy lock. The only external calls go to the one immutable FXRP address. The runtime has no DELEGATECALL, no CREATE, no CREATE2, and no SELFDESTRUCT.

4. Who can touch the funds

Nobody inside this contract. There is no owner, admin, pause, upgradeTo, mint, operatorWithdraw, sweep, or rescue. Those selectors are absent, and calling them reverts. The proxy slots are empty. No storage slot holds an address. The deployer cannot mint myXRP without depositing FXRP, cannot move another holder’s balance, and cannot take the FXRP out except by burning myXRP.

That is the property this review confirms. It is also permanent. A defect found later cannot be patched at this address. The remedy would be a new deployment and a voluntary move by holders.

5. What a holder still accepts

The wrapper is only as sound as FXRP. Official FXRP is an upgradeable proxy. Its asset manager can mint and burn, and a transfer pause on FXRP would make withdraw revert for as long as that pause lasts. Because the burn happens before the FXRP transfer and the whole transaction reverts together, a failed withdrawal does not destroy the myXRP. Holders wait. They are not written down by the bridge itself.

deposit credits the amount the caller asked for, not the change in the contract’s FXRP balance. The current FXRP implementation takes no transfer fee, and the 25.000000 deposit arrived in full. A future FXRP implementation that took a fee would credit more myXRP than FXRP received. That cannot be fixed on this address.

If the FXRP backing ever fell short, redemption is first come, first served. The contract has no pro-rata haircut and no function that tops it up except a voluntary send of FXRP, which would then be locked as surplus. FXRP or any other token sent in outside deposit cannot be rescued. That is the cost of having no administrator.

6. Findings

IDSeverityItem
—CriticalNone.
—HighNone.
M-01Mediumdeposit credits the requested amount, not the observed FXRP delta. Safe with today’s FXRP. Open, and not patchable here, if FXRP later takes a fee.
M-02MediumSolvency depends on upgradeable FXRP, whose asset manager can mint, burn, and pause transfers. Inherent. The bridge has no defence and no pause of its own.
L-01LowNo rescue for tokens sent by mistake. Accepted. A rescue function would also be a drain.
L-02LowNo pause and no upgrade. Deposits cannot be halted. Redemptions cannot be halted either.
L-03LowmaxAssets caps tokens outstanding, not lifetime issuance. The live history shows 25 minted, burned, and minted again, with room returning. It is not an amount already issued.
L-04LowOrdinary ERC-20 approval race. No permit.

Informational: the contract is not ERC-4626 and should not be described as a vault. Failures revert with custom errors rather than returning false. name and symbol are the same string. The whole 25.000000 supply sits at one address; that address has no power over the contract or over anyone else’s balance.

7. Conclusion

MyXRPBridge at 0x14b9DD90edaAff6527c1b168550B3FAA15b9F6AF is a small, verified, ownerless, non-upgradeable 1:1 wrapper. Deposit locks FXRP and mints the same myXRP. Burn returns the same FXRP. No one in this contract can take that FXRP, pause the exit, or change the rate. This review found no critical and no high issue.

Holding myXRP is holding FXRP plus one immutable contract that cannot be changed, including by its deployer. The remaining material risk is in FXRP itself, and in the fact that this address can never be patched.


Prepared from Flare mainnet state on 3 October 2026. A technical opinion on one contract. Not a guarantee against loss, not an endorsement, and not a statement about any company, licence, or off-chain book.