The converter separately sends an equal raw amount of TIGEROG from its own reserve to the calling account. The legacy token never becomes a converter-held escrow balance. E1 E2 E3
Axelar ITS is designed for tokens that exist and move across connected chains. That is a different operation from converting TIGEROG back into the legacy BNBTiger contract. E6
BscScan publishes an exact-match verified contract named TigerOGMigration. Its constant DEAD is the dead address, and upgrade transfers legacy tokens to it. E1
Open verified source on BscScan ↗The receipt contains a BNBTiger Transfer event from the calling/upgrader address directly to 0x…dEaD, then a TIGEROG Transfer from the converter to that same address, for the same raw amount. E2
Open transaction on BscScan ↗In latest-state calls captured while the observed chain head was block 110,281,458, the migration contract had a zero BNBTiger balance and reported a TIGEROG reserve available for upgrades. E3
Open observed block ↗address public constant DEAD =
0x000000000000000000000000000000000000dEaD;
function upgrade(uint256 amount) external whenNotPaused {
if (amount == 0) revert InsufficientBalance();
if (TIGEROG.balanceOf(address(this)) < amount)
revert InsufficientTigerOGTokens();
BNBTIGER.safeTransferFrom(msg.sender, DEAD, amount);
TIGEROG.safeTransfer(msg.sender, amount);
emit TokensUpgraded(msg.sender, amount);
}
function withdraw(
uint256 amountBNBTiger,
uint256 amountTigerOG
) external onlyOwner {
if (amountBNBTiger > 0)
BNBTIGER.safeTransfer(owner(), amountBNBTiger);
if (amountTigerOG > 0)
TIGEROG.safeTransfer(owner(), amountTigerOG);
}DEAD is a constant equal to 0x…dEaD; the owner cannot replace it through a setter. E1
safeTransferFrom(msg.sender, DEAD, amount) does not route them through address(this). E1
The reserve is TIGEROG held by the converter; it is the asset distributed in exchange. E1 E3
withdraw can transfer only assets owned by the converter. It cannot act as 0x…dEaD or move tokens recorded at that address. Inference from E1 + E3
The verified converter exposes upgrade, pause controls, availability, ownership controls, and withdrawal; it exposes no downgrade, redeem, release, or reverse-conversion function. E1
The following fields are decoded from the successful receipt for transaction 0xb0b086…a2fb5 at block 95,416,649 on 29 April 2026 at 19:15:43 UTC. E2
What this proves: at least one live execution of the converter followed the verified source exactly. The legacy-token event’s recipient is the dead address, not the migration contract. Inference from the observed receipt
“Tokens are held in a secure conversion contract.”
The project website presents this statement next to its Freedom Bridge upgrade description. Its wording represents the legacy tokens as converter-held custody. E7
Open the TIGEROG project site ↗The legacy transfer does not place tokens in the converter.
The verified upgrade function calls safeTransferFrom(msg.sender, DEAD, amount). A successful receipt records the legacy transfer from the caller to 0x…dEaD, and the converter’s observed BNBTiger balance was zero. That is inconsistent with the statement that legacy tokens are held in the conversion contract. E1 E2 E3
This comparison is limited to custody and recoverability. The observed conversion did transfer the same raw amount of TIGEROG to the caller, so this report does not dispute that narrow raw-amount observation. It also does not assess a general claim that a protocol is “secure.” The documented inconsistency is the specific description of legacy tokens as converter-held when the verified transfer path sends them to the dead address. E1 E2 E3 E7
“your legacy tokens are permanently locked in the conversion contract.”
The production site uses this wording in its answer about converting TIGEROG back to BNBTiger. E4
Open the Freedom Bridge FAQ ↗At the observed block, BNB Chain returned eth_getCode(0x…dEaD) = 0x and eth_getTransactionCount(0x…dEaD) = 0. In plain language: no contract bytecode is deployed at that address, so there is no vault or unlock program there, and the address had initiated no transactions through that block. E5
The migration contract also has no authority to originate a transaction from the dead address. The owner’s token-withdrawal authority reaches only balances held by the converter. Combining those facts, the legacy tokens are not recoverable through the migration contract or an unlock routine at the recipient. Inference from E1 + E5
Observation block number: 110281458 (0x692c2f2) timestamp: 2026-07-16T07:13:57Z hash: 0x142ab65d62909f3a3823e825f22ec2c96e6d4c4d962669bdf7239c210968cb97 Request: eth_getCode( "0x000000000000000000000000000000000000dEaD", "0x692c2f2" ) Result: "0x" Request: eth_getTransactionCount( "0x000000000000000000000000000000000000dEaD", "0x692c2f2" ) Result: "0x0" Request: BNBTiger.balanceOf( "0x18b2AeD6Aa6aE20A70be57739F8B5C26706Ff2af" ) Result: 0x0000000000000000000000000000000000000000000000000000000000000000
Replay note: these are captured responses from the public BNB Chain endpoint. Replaying historical state later requires an archive-capable endpoint; ordinary public nodes may prune old state.
A transfer to 0x…dEaD is commonly treated as an economic burn, but it is not necessarily an ERC-20 _burn that reduces totalSupply. The converter calls transferFrom, not _burn. Also, public-chain data cannot prove an absolute negative about every conceivable private key. The evidence supports the narrower and decision-relevant conclusion: this is not a converter-controlled lock, no unlock code exists at the recipient, no reverse function exists in the converter, and no outbound use of the dead address was observed through the named block. E1 E5
A migrated holder cannot use this converter to restore BNBTiger.
In the observed path, the holder’s BNBTiger is transferred to 0x…dEaD and the converter transfers TIGEROG to the holder. The verified source and ABI expose no downgrade, redeem, release, or reverse-conversion entry point. E1 E2
A holder cannot capture that legacy-market premium by reversing the conversion.
If BNBTiger later trades above TIGEROG and sufficient liquidity is available to execute a sale at that higher price, a migrated holder cannot reclaim their former BNBTiger through this contract to sell into that market. Restoring legacy exposure would require acquiring BNBTiger separately, if an external market is available. This is a consequence of the contract path, not a prediction of price or liquidity. E1 E2
Prices can rise or fall, and an apparent price may not be executable without enough market liquidity. This report does not recommend converting, holding, buying, or selling either token. The evidence supports the narrower structural point: after an upgrade, the converter itself provides no route back to the legacy asset. E1 E2
| ID | Claim | Basis | Evidence |
|---|---|---|---|
| C-01 | The migration contract is 0x18b2AeD6Aa6aE20A70be57739F8B5C26706Ff2af. | Verified factFreedom Bridge’s production configuration names it, and BscScan publishes verified source at that address. | E1, E4 |
| C-02 | The converter sends BNBTiger directly to 0x…dEaD. | Verified factExact source: safeTransferFrom(msg.sender, DEAD, amount). | E1 |
| C-03 | A live conversion executed caller → dead and converter → caller. | Observed eventThree matching receipt logs: legacy Transfer, new-token Transfer, TokensUpgraded. | E2 |
| C-04 | The converter is not holding legacy tokens for later release. | Supported inferenceThe transfer bypasses the converter, and its observed legacy balance was zero. | E1, E3 |
| C-05 | The converter offers no reverse conversion. | Verified factNo downgrade, redeem, release, unlock, or reverse entry point appears in the verified source/ABI. | E1 |
| C-06 | Its owner cannot withdraw tokens from the dead address. | Supported inferenceThe owner-only function transfers the converter’s balance; no code or authority lets it act for 0x…dEaD. | E1, E5 |
| C-07 | Axelar functionality does not create a TIGEROG → BNBTiger redemption path. | Supported inferenceThe token identifies Axelar ITS, whose documented purpose is cross-chain token deployment/transfer; the legacy converter remains a separate contract with only upgrade. | E1, E6 |
| C-08 | The TIGEROG project website’s converter-custody description is inconsistent with the verified legacy-token path. | Supported inferenceThe site says tokens are held in a secure conversion contract; verified code and a receipt instead show a direct transfer from the caller to the dead address. | E1, E2, E3, E7 |
| C-09 | A completed upgrade provides no contract-based route back to the holder’s former BNBTiger. | Supported inferenceThe observed legacy transfer is caller → dead and the verified ABI has no reverse-conversion entry point. Any later difference in market value or liquidity is conditional and outside the contract evidence. | E1, E2 |
The legacy conversion is one-way through the deployed TigerOGMigration contract. BNBTiger goes to the dead address, TIGEROG comes from the converter’s reserve, and no converter-controlled lock or reverse redemption exists. Axelar moves TIGEROG between chains; it does not reverse the legacy migration. E1 E2 E3 E5 E6