Blaster swap exchanged tokens through liquidity pools with wallet authorization.

Wallet Access and Token Identity

A usable wallet connection required access to the network where the exchange contracts were deployed. The exchange's Blast deployment didn't make balances on another network available to its contracts. Holding a token elsewhere and holding it in the relevant account were different starting conditions.

Token identity also included the contract address. ERC-20 defines names and symbols as optional metadata, so a displayed ticker can't uniquely identify an asset. The selected input and output must correspond to the intended contracts.

Spending Permission Before Exchange Execution

An ERC-20 approval sets a spending allowance for a specified spender. The token contract records that permission separately from an exchange transaction.

Connecting a wallet doesn't itself create this allowance. An existing allowance may cover the intended input, while an insufficient allowance requires a separate authorization change. The relevant comparison uses the same token, owner and spender.

An approval also doesn't reserve pool liquidity or fix an exchange price. Permission to spend and acceptable exchange terms answer different questions.

Execution Records and Recipient Balances

A transaction hash identifies a submitted transaction; it doesn't by itself establish successful execution. For an exchange, the record must show what contract ran and whether the operation succeeded. Token movements then explain the output that reached the recipient.

The V2 pair recorded swap input amounts, output amounts and a destination in its swap event. That record described activity within the pair. When interpreting a routed exchange, intermediate transfers may belong to the route rather than the wallet's final receipt.

The Frontend Withdrawal Window

The shutdown announcement asked liquidity providers and staking participants to withdraw before January 15, 2025. It described continued frontend access until that date to support withdrawals. That was a historical transition window, not an ongoing promise of access.

View image file

A frontend deadline doesn't establish that every deployed contract disappeared or that every remaining position became recoverable. Present access to a particular position remains unresolved without its contract state and a usable withdrawal method.

Transaction Funding and Exchange Costs

Contract execution requires network resources, so the available input-token balance isn't the entire funding requirement. Gas covers computation. Its cost is separate from the token amounts that the exchange moves, even when both affect the same wallet's balance.

A quote and a transaction record describe different moments. The quote supplies proposed exchange terms; the execution record contains the operation that reached the chain. Comparing them requires consistent input and output assets, together with the actual network charge. A fixed total-cost figure wouldn't describe every amount, route or network condition.

Pool Reserves and Executable Amounts

The V2 pair enforced liquidity constraints before accepting a swap. The V2 pair required each requested output amount to be smaller than its corresponding recorded reserve. It also checked incoming amounts and the balance relationship after accounting for its swap charge.

Those checks explain why the presence of a pool didn't mean every trade size was possible. An allowance couldn't overcome insufficient reserves. A valid exchange needed compatible token transfers and amounts that satisfied the pool's rules.

Router Versions and Available Methods

Contract versions changed which exchange methods and parameters were available. V2 and V3 records shouldn't be treated as interchangeable instructions. A method supported by one router doesn't establish support in another deployment or in a particular interface.

The V3 router interface included single-pool and encoded-path swap methods. It also exposed permit-related helpers, conditional on compatible token authorization. When interpreting a historical transaction or an integration, distinguish the router's supported methods from the controls and routes available through an interface.

Liquidity Withdrawal as a Separate Operation

Liquidity withdrawal returned assets represented by a pool position, whereas a swap exchanged an input asset for an output asset. In the V2 pair, burning liquidity tokens calculated proportional amounts of the underlying balances. That operation had its own conditions and event record.

A wallet containing a liquidity position therefore had a different task from a wallet holding an ordinary input token. Treating the position as a completed swap would obscure which assets remained inside the pool.

Yield Features and Historical Incentives

The exchange's V2 design incorporated yield handling associated with Blast. For pools containing WETH or USDB, the V2 pair claimed yield and updated reserves when liquidity was added or removed. It didn't establish a fixed return for every trader or turn each swap into an entitlement to rewards.

The shutdown announcement described the December Gold distribution as the final distribution. Historical reward language therefore shouldn't be carried into a new exchange decision as an active benefit.

The Next Exchange Decision

A new exchange requires an available execution path for the intended assets and acceptable amount limits. Historical contract functionality alone doesn't establish that availability. Existing holders face a different decision: whether their account contains ordinary tokens, a liquidity position or a staking position requiring its own exit method.

For an unfinished task, identify what the account currently holds before choosing another operation. A new swap can't substitute for withdrawing an existing position, and a permission record can't substitute for the intended token receipt.