TONSWAP Testnet Is Live: The Next Chapter Is Yours to Test

The TONSWAP public testnet is live. Connect a testnet wallet, put the app through its paces, and help get us to mainnet.🔗

TL;DR🔗

• Testnet is live. LFG. Open test.tonswap.org and connect a dedicated TON testnet wallet.
• Less spectating. More testing. Get test tokens, try an available swap, inspect a liquidity position, or explore T3 and the launchpad. Use test assets only.
• A signature is not settlement. Read the quote, review the wallet request, and check what actually arrived. Follow the whole transaction.
• Found a rough edge? Make it useful. Confusing units, stuck statuses, awkward mobile screens: send us the steps, screenshots, and transaction link in Telegram.
• Mainnet is the mission. Every reproducible problem gives us something concrete to fix. Help make TONSWAP an app you would choose to use.

Quick start: your first TONSWAP test🔗

The screens below are from the live public testnet in dark mode. Use the theme button beside the TONSWAP logo to switch appearances. Wallet approval screens vary by provider; the important checks are the network, the connected address, and the action you are authorizing.

1. Prepare a fresh testnet wallet and network fees🔗

Use a dedicated wallet for this test. In Tonkeeper, first create a brand-new, unfunded wallet. Tonkeeper’s testnet instructions start with a wallet created on mainnet: choose Add Wallet → Testnet Account, then enter that new wallet’s recovery phrase inside Tonkeeper to add its testnet account. Use the testnet account for TONSWAP. Never enter the recovery phrase into TONSWAP or a faucet.

Before requesting T3 or USDT, get native testnet coins for network fees. The TON testnet faucet accepts your public wallet address: paste it, select Get testnet GRAM, and wait for the incoming transfer. It does not need your recovery phrase or a wallet connection. Follow the faucet’s displayed limits. The native asset appears as Gram in the TONSWAP wallet, while fee notices currently call it TON.

2. Connect to TONSWAP and get test tokens🔗

Open test.tonswap.org, choose Wallet, and select Connect Wallet. Choose your wallet from the TON Connect picker, or scan the QR code with your mobile wallet. Select your testnet account, check that the requesting site is test.tonswap.org, and approve the connection. Back in TONSWAP, check your address and the TON Testnet indicator in the sidebar.

Open the connection dialog on your own device and scan its QR code. The screenshot illustrates the flow; its QR code is not a connection link for readers.

In Wallet, expand Get test tokens. Choose Claim T3 to try trading and liquidity, or Claim USDT to start the DeFi → Mint T3 journey. The screen shows the current grant and cooldown. At the time of this walkthrough, the faucet displayed 0.30 test TON to attach for delivery; keep extra native coins for wallet fees. Review the wallet request, then wait for the tokens to arrive before trying to spend them.

Our fresh disposable wallet received 1,000 test T3. The faucet showed “Tokens received” and a 24-hour cooldown, and the T3 balance matched the delivered amount. Native testnet coins pay for delivery and wallet fees; they are separate from the T3 and USDT test assets.

3. Read a small spot swap from top to bottom🔗

Choose Swap → Spot → Market. Select T3 under Sell / Pay and USDT under Buy / Receive, then enter a small amount of test T3. Wait for the live quote to finish loading.

Read Buy / Receive, Min Received, Trading fee · included, Network funding, and Slippage together. The quoted output and minimum output answer different questions: the minimum is the floor you are authorizing at the selected slippage. A market may have no recent chart candles while still providing a live quote; use the execution details in the form.

A quote is a preview. Amounts, fees, and available liquidity can change; review the current values on your own screen before approving.

When you are satisfied with the terms, select Confirm Swap. After preparation, TONSWAP shows Ready for wallet approval with the network, message count, sender, and attached native amount. Review these details, choose Continue to wallet, and approve the request once in your wallet. Follow the resulting status in TONSWAP instead of treating the wallet signature as the finish line.

4. Check what arrived, then try another journey🔗

Return to Wallet → Tokens and inspect the received asset. Open History and compare the transaction with the result. Refresh if needed. If the outcome is uncertain, inspect the existing transaction rather than submitting the swap again. A useful test report includes what you expected, what appeared in the wallet, and the transaction link.

In this walkthrough, the fresh wallet claimed 1,000 test T3 and swapped 10 T3 for 9.97 test USDT. Its resulting balances were 990 T3 and 9.97 USDT, verified on chain. TONSWAP confirmed the output while history was still syncing; history later marked the swap transaction as SUCCESS. A history refresh and receipt of the tokens are separate observations; the syncing message was not a reason to submit the swap again.

For liquidity, open DeFi → Pools, choose a pool, and select Deposit. Enter the amounts, compare the allocation shapes, and inspect the prices in T3 per token and the Your position preview table. Check the number of wallet approvals and the separate native funding requirement before continuing. After a completed deposit, inspect Wallet → Positions.

For stablecoins, open DeFi → Mint T3 and review the reserve asset and resulting T3 amount. For a token sale, start in Launchpad with an existing minted test token, inspect the required funding and approvals, and follow the continuation into liquidity. The sections below explain what to examine in each journey.

An exchange becomes real when someone other than its builders can use it, understand it, and show them what needs to improve.

Today, we are opening the TONSWAP public testnet at test.tonswap.org. We invite you to connect a testnet wallet, explore the available markets, try the liquidity and launchpad workflows, and tell us what happens. Share your feedback in the TONSWAP Telegram chat.

Our objective is straightforward: reach mainnet as soon as possible. Your testing helps us get there by turning unknowns into observations, observations into reproducible problems, and problems into verified improvements.

A successful trade is useful evidence. So is an unclear approval screen, an unexpected balance, or a transaction whose status you cannot confidently explain. We need to understand the whole experience, including the moments that a demonstration usually leaves out.

The testnet is where your experience becomes part of the engineering.

From an earlier promise to something you can use🔗

When Polkaswap launched in April 2021, it gave concrete form to an ambition that still matters: people should be able to exchange assets and provide liquidity without handing those activities to a conventional exchange operator. That launch belongs to the history behind TONSWAP, but history is a starting point, not a substitute for making the next product work.

The lesson we take from the 2023 teardown is that the things surrounding a system must not be confused with the system itself. A token is not an application. Attention is not usable liquidity. A roadmap is not an executed transaction. The work becomes clearer when we separate these things rather than asking one to stand in for another. That distinction has remained central to our thinking about what deserves to be built.

There are several ways to respond when an earlier promise remains unfinished. We can repeat the promise, abandon it, or examine what still needs to work. TONSWAP belongs to the third response.

In 2026, the question is practical. Can someone arrive, understand the available choices, complete an action, and verify the result? Can a community move from a token sale to a functioning market without losing its way between disconnected tools? Can a more experienced participant inspect execution terms without making the basic interface incomprehensible to everyone else?

These are the questions this testnet is meant to expose.

We do not need to settle every argument about the future of decentralized finance before answering them. We need people to use the software.

One application, distinct responsibilities🔗

TONSWAP brings together trading, liquidity provision, a stablecoin hub, token sales, derivatives, and supporting risk-management functions. Its architecture uses T3 as a common base for liquidity and settlement. The purpose is to make these activities work together without pretending that they are all the same activity.

That distinction is important. Buying an asset is different from supplying liquidity. Supplying liquidity is different from committing a position to a reward campaign. Creating a token sale is different from establishing a market in which people can trade. A useful application should connect these actions while preserving what each one means.

The current exchange architecture uses bin-based DLMM liquidity, an evolution from the earlier CLMM descriptions of TONSWAP. Liquidity is allocated across discrete price bins, with the liquidity workflow expressing prices in T3 per token and offering different allocation shapes. The implementation is designed to keep the allocation shown in the preview consistent with the allocation submitted for approval.

For a liquidity provider, the meaningful question is where the deposited assets will participate in trading. For a trader, it is what the available liquidity means for the quoted exchange. Those questions should remain visible beneath the convenience of a simple interface.

This gives testers a concrete job. Change the deposit amounts. Compare the available distributions. Read the price units. Examine the approval. Then inspect the resulting position. Tell us where the relationship between those stages is clear, and where you have to guess.

The Concentrated preview allocates liquidity across seven price bins. This example uses a token labeled NEW, so prices are expressed in T3 per NEW. Choose a distribution, adjust the range, and inspect each bin’s share and token amounts in the table before approving. The four approvals and 5.6–5.8 TON shown beneath this example are separate network funding; use the requirements displayed for your own deposit.

T3 provides another connected workflow. The protocol’s composite stablecoin design includes reserve routes for USDT, USDC, and KUSD, while the application includes minting and redemption interfaces. Minting, burning, and receiving redemption proceeds are distinct operations; the redemption integration specifically distinguishes an accepted burn from completed delivery of the reserve assets. Testnet representations of these assets should be used as test instruments, not treated as real dollar balances.

The wallet view brings tokens, positions, and transaction history together so that an action can be followed beyond its initial submission. That is an essential part of what we want people to examine. A trading screen is only one view of an exchange; the record of what you now hold is another. They should tell a consistent story.

A token sale should lead somewhere🔗

For a project creator, a sale is not the final destination. It is one stage in establishing something other people can participate in.

TONSWAP’s current launchpad workflow creates a sale for an existing minted token. It is not a claim that entering a name automatically creates a token, completes a sale, and produces a liquid market. The workflow separates sale creation, the required funding and approvals, and the creator’s continuation into liquidity and trading.

This separation makes the process more useful, not less ambitious. A creator should be able to see what already exists, what must be supplied, what each approval authorizes, and what remains unfinished. When several approvals are necessary, progress should be understandable. When a session is interrupted, the application should help distinguish completed stages from actions that have not yet been submitted.

For this testnet, we want creators to follow that journey rather than stop at the first successful screen. Prepare a test-token sale. Examine its requirements. Follow the available continuation into liquidity. Check that the intended token remains selected and identifiable when you move toward trading. Report any point at which the application makes you reconstruct information it should already know.

The larger ambition is to make a community’s financial infrastructure easier to establish. The immediate task is more specific: make the handoffs between its parts dependable.

A token becoming visible is not the same as a market becoming usable.

Beyond spot trading, with the differences intact🔗

The trading interface includes Spot, Perps, and Options modes. The broader protocol also defines instruments such as Shout and relative-performance options, alongside the supporting pricing, collateral, and settlement machinery. These products should be tested according to the markets and contract states actually available in the deployed release, rather than treated as interchangeable buttons on a trading ticket.

For experienced derivatives users, the useful feedback is about the terms of the position. Is the direction clear? Can you distinguish the amount committed from the exposure being taken? Are the applicable fees, limits, and settlement conditions understandable before approval? Does the resulting position agree with what you reviewed?

The testnet is an opportunity to make those distinctions obvious. A familiar interface should reduce unnecessary work; it should not conceal the nature of the instrument.

The DeFi area also includes farming, volatility, insurance, and governance views. The contract specification describes farming campaigns associated with DLMM bin shares and a Parisian-style range-cover mechanism, whose trigger depends on a price remaining outside a defined range for a continuous period. That is a specific contractual condition, not a general promise that every liquidity-provider loss will be reimbursed.

These distinctions are worth testing as carefully as the transaction itself. A reward, a position, a coverage condition, and a payout are different facts. The application should help you understand which fact you are looking at.

There is also a crosschain workspace for the configured TON-to-SORA route. The current interface distinguishes burning a supported asset on TON, preparing its proof, and completing minting on the destination network separately. Supported assets depend on the deployment’s explicit configuration. This is not an unrestricted bridge for arbitrary tokens, and a source-chain action is not, by itself, evidence that destination delivery has finished.

Advanced testers can help by examining that boundary: the selected asset, destination, proof preparation, recovery information, and the distinction between a completed source action and the remaining destination action.

Across these functions, availability depends on the relevant deployment configuration, contract activation, liquidity, and supporting services. An unavailable action should explain its requirements. A pending action should remain pending until there is evidence of its outcome. Those are product behaviors we want tested, not details we expect users to work around.

A signature is not settlement🔗

One of the most important things to test is also one of the easiest to overlook: what the application means when it says an action is complete.

On TON, contracts communicate through messages, and processing those messages produces transactions that change individual contract states. A user’s action can therefore involve several connected steps rather than one indivisible event. Wallet approval and final receipt of an asset answer different questions. (TON Docs)

Approval answers whether you authorized a request. Submission concerns whether that request was sent. Execution concerns what the contracts did. Settlement concerns whether the intended resulting assets or position were delivered and recorded.

A clear interface can make this sequence feel straightforward. It must not achieve that simplicity by collapsing different states into a premature success message.

TONSWAP’s current implementation work follows this distinction. The swap flow tracks the original input through pool execution and recipient credit. Liquidity confirmation checks credited owner shares. Pending-operation records are intended to preserve the original action across interruptions rather than encourage blind resubmission when its outcome is uncertain.

This is where ordinary testing becomes especially valuable. Approve an action and follow it to its result. Return to the wallet. Refresh the page. Reopen the application. Check whether the same action still has the same meaning.

You do not need to know the internal message format to notice that a balance has not updated, that a status is ambiguous, or that the application appears to be asking you to repeat something you already approved. Describe what you saw.

The useful unit of testing is a completed journey, not a button press.

Start with one complete journey🔗

Open test.tonswap.org and use a dedicated testnet wallet. Keep mainnet assets out of the test environment.

The wallet includes a Get test tokens flow for obtaining test T3 or test USDT. T3 can be used to explore the available trading and liquidity functions; test USDT provides a starting point for the Mint T3 workflow. Faucet requests require native testnet tokens for delivery and wallet fees, and the interface displays the applicable grant availability and cooldown. Follow those displayed conditions when requesting assets.

Then choose one journey and complete it carefully.

For a first visit, start with a small test swap in an available market. Read the quoted amount, execution terms, and minimum output. Review the wallet request. After approval, follow the status, inspect the received asset, and compare the result with the transaction history. The most helpful first test is one you can explain from beginning to end.

For liquidity, inspect a funded and available pool, review the allocation, and follow the deposit through to the resulting owner position. For T3, compare the minting or redemption terms with the assets ultimately recorded. For a token sale, follow the creator’s stages and the continuation toward a usable market.

These journeys exercise the connections between features. They also give us a better basis for investigating a problem than isolated screenshots without context.

After an ordinary successful attempt, try the kinds of interruption that happen during normal use. Reject an approval and check that the application returns to a sensible state. Reload while an action is pending and inspect how it resumes. Switch accounts and verify that the displayed information belongs to the account now connected.

When an outcome is uncertain, inspect the existing transaction and report the uncertainty rather than repeatedly submitting the same action.

Please test on the devices and environments you actually use. A control that is obvious on a large desktop display may be difficult to understand on a phone. A wallet handoff may interrupt your understanding even when the underlying transaction works. Text, spacing, navigation, and error messages are part of the system’s usability, not decorative concerns added after the engineering.

Tell us what happened, not what you think we want to hear🔗

Send feedback to the TONSWAP Telegram chat. We welcome reports from first-time users, experienced traders, liquidity providers, project creators, and developers.

The most useful report describes your objective, the steps you took, what you expected, and what actually happened. Include the relevant screen, token pair or asset, amount, approximate time, device, browser, and wallet application where those details matter. A transaction link or hash is particularly useful for a submitted action. Screenshots or a short recording can clarify interface behavior.

An illustrative report might read: “I tried to swap test T3 for test USDT on my phone. I approved the request in my wallet, but the swap screen remained pending after I returned. After reloading, the received balance appeared, while the history entry still showed pending. Here are the transaction link, browser version, and screenshots.”

That gives us a sequence to investigate. It does not require the tester to decide whether the cause lies in contract execution, data retrieval, wallet communication, or presentation. Separating observation from explanation helps us identify the right problem.

Never include a recovery phrase, private key, or other secret in a report.

Feedback does not have to describe a failure. Tell us which information helped you decide, which explanation was missing, and where you hesitated before approving. An interface can be technically functional and still leave someone uncertain about what they are doing.

A new user who cannot tell whether a transaction completed has found a product problem. An experienced user who notices inconsistent units has found a precision problem. A developer who can reduce an unexpected result to a repeatable sequence has given us a particularly effective way to investigate it.

All three contributions matter.

The fastest route to mainnet is through better evidence🔗

We want to launch mainnet as soon as possible. That means reducing uncertainty quickly, not disguising it.

The feedback process should be concrete: reproduce the reported behavior, identify its cause, correct it, and test the corrected journey. Public testing complements contract review and release qualification; it does not replace them. Its particular value is that it brings the application into contact with people, devices, expectations, and sequences of actions that its builders cannot fully anticipate.

This is also how a community begins to shape infrastructure. Someone encounters a problem. Another person confirms it. A clear explanation makes it reproducible. A correction improves the experience for everyone who comes afterward.

Participation produces more than activity. It produces knowledge about what the system needs to become.

The ambition behind TONSWAP is larger than a testnet. We want decentralized trading and the tools around it to become useful enough that people choose them for what they let them do. But that future depends on present-tense details: an understandable quote, a correctly credited position, a sale that can be followed through its stages, and a transaction whose outcome is clear.

You do not need to endorse every part of that ambition to help improve one of those details. Bring the standards you already use when deciding whether software deserves your trust.

Open the TONSWAP testnet, try a complete journey, and tell us about it in Telegram. What would need to become clearer or work better before you would choose to use TONSWAP regularly?

The next person to use TONSWAP may never encounter the problem you find today. That is what your contribution can make possible.