Buying and selling
The dapp offers ETH/CUBIT swaps through the selected deployment’s router. Taxes are applied in the hook; the estimated amount to receive must already be net of taxes included in the quote.
The dapp connected to Sepolia currently uses the historical version with 0.30% LP fees. The requested 0.01% version with multiple fixed walls has not yet been redeployed. A demonstration or simulation mode is not an on-chain state.
Before preparing a swap
Check the wallet’s network, the displayed deployment and the data block. Allow ETH for gas in addition to the amount to swap. The dapp must flag unavailable RPC or stale data and prevent signing based on an unverified state.
A change of account, network, amount or router address requires a new quote. Peripheral addresses can change through the V2 registry.
Buying CUBIT
- Choose an ETH amount. In exact-input mode, the 3% buy tax is included in that amount.
- Read the estimated net CUBIT amount, fees and minimum received set by the slippage tolerance.
- Check the simulation and the details displayed by the wallet, then sign.
- Wait for a successful receipt and refreshed on-chain balances.
Purchases use native ETH through msg.value. The CUBIT router does not use Permit2 for this workflow.
Selling CUBIT
Selling may require an ERC-20 approval allowing the router to transfer the chosen CUBIT amount. The frontend prepares authorization for the requested amount.
After approval confirmation, the dapp rechecks the account, network, registry revision and quote freshness before the swap. Approval and sale are two separate transactions when the previous allowance was insufficient.
Selling returns ETH net of the 15% tax: 12% of gross ETH funds walls and 3% goes to the team. On the CUBIT router path, tokens absorbed by walls are destroyed at the end of the sale when burning is required.
Minimum received and deadline
Slippage limits the accepted difference from the quote. A tax already included in the quote is not a reason to arbitrarily add 15 percentage points of slippage.
In the frontend sources reviewed, a quote remains fresh for 30 seconds. The transaction deadline is calculated from the chain timestamp. These checks can prevent signing after a long approval wait; a fresh quote must then be reviewed.
A transaction rejected by these limits protects the agreed minimum or maximum amount. Its failure does not mean the limit should be removed.
If the transaction fails
| Situation | Useful action |
|---|---|
| Wrong network or changed account | Return to the intended context and request a new quote |
| Expired quote | Recalculate the net amount and minimum received |
| Changed router or revision | Review the current address and new action; the old approval remains attached to the old spender |
| Insufficient liquidity | Check a quote for a smaller amount and the available positions |
| Unavailable RPC | Wait for a valid on-chain read before signing |
| Transaction already sent | Check the hash and receipt before preparing another |
The router rejects input that is not fully consumed and exact output that is not fully supplied. Funds spent in a reverted transaction are rolled back by the EVM, excluding gas.
Checking the result
A hash means the transaction was submitted; only the receipt indicates success. Check the explorer’s network, status, recipient and BuyTaxed or SellTaxed events.
Wall reference prices do not replace a quote for a given order. Reading dapp data.
Sources: dapp/src/chain/swap.ts, executeSwap.ts, deployment.ts and contracts/src/periphery/CubitRouter.sol. Browser/mobile wallet acceptance testing remains separate from automated tests.