TONSWAP Risk Engine

TONSWAP Risk Engine: Taming the Black Swan🔗

TL;DR🔗

• TONSWAP is a CLMM DEX, a stableswap DEX, a launchpad, a perps market, and an options market, all as one coherent, self-contained ecosystem; because it is a comprehensive DeFi ecosystem it is important to have a way to manage and reduce market risk so users have the best trading experience
• Lesson from the Crash: October 2025's flash crash erased $19B in leveraged positions within hours, exposing how cascading liquidations devastate traders when risk controls fail. TONSWAP's fully on-chain risk engine acts as an autonomous safety net to prevent such catastrophes.
• All On-Chain, No Wetbrains: TONSWAP’s risk engine combines a central Risk Controller and a self-balancing Control Mesh to manage risk entirely on-chain. Every product’s limits, fees, and “risk posture” adjustments are computed deterministically by smart contracts – no off-chain keepers or wetbrain (human) intervention required. This ensures that in a volatile market, the system reacts instantly and transparently, according to code, not panic or discretion.
• Real-Time Telemetry & Global Risk Index: All TONSWAP components feed live data into the Risk Controller. Metrics are smoothed (via EWMA and rate limits) and aggregated into a Global Risk Index (GRI). The GRI triggers gradual posture changes with hysteresis and cooldowns, allowing the platform to adjust risk measures step-by-step rather than abruptly.
• Self-Balancing Control Mesh: The Control Mesh is an on-chain network of control algorithms that adjust parameters across all modules. It takes the Risk Controller's posture and telemetry as input and dispatches updates to trading fees, lending caps, peg rates, perps leverage, and gas allocation. This happens every heartbeat (a periodic on-chain tick). All updates are forward-funded (sender deposits gas), so modules receive messages with gas to act immediately without lag or underfunded calls.
• Built for Safety and Transparency: The risk engine starts with conservative defaults and hard limits. Governance updates are validated on-chain to prevent invalid configurations. The Risk Controller uses a two-phase commit (intent + authorization receipt) for critical actions, guaranteeing authenticity and limiting each operation's impact. If telemetry fails or a subsystem misbehaves, the engine freezes or reduces that component's influence. Everything is auditable via on-chain getters, so the community can monitor risk in real time through dashboards without trusting an off-chain black box.

Why Does DeFi Need an On-Chain Risk Engine?🔗

Imagine waking up rekt to a market crash that’s evaporated tens of billions of dollars overnight. Unfortunately, this happened in October 2025. Between Oct. 10th and 11th, the crypto market suffered the largest leverage wipeout ever recorded, with more than $19 billion in positions liquidated almost instantly. Degens, even seasoned ones, saw their entire portfolios go to zero as automatic margin calls cascaded across exchanges. The episode underscored a harsh reality: unmitigated leverage and poor risk controls can turn a small correction into a freefall.

For DeFi platforms, the stakes can be even higher. There’s no centralized risk manager to hit the big red stop button. Some decentralized exchanges rely on off-chain keepers or manual governance interventions to manage emergencies, but those come with delays, trust assumptions, and often, too little too late. What if we could encode the risk management process itself into smart contracts, enabling the system to detect danger and rebalance in real time, 24/7?

TONSWAP's on-chain Risk Engine (built in TOLK) is the autonomous brain monitoring all the DeFi products, keeping the ecosystem within safe bounds. It operates without human or off-chain bot intervention: no keepers, no manual calls. The engine continuously processes on-chain data and makes deterministic decisions, enabling TONSWAP to respond within seconds during a crisis instead of waiting for disaster.

Below, we'll explore how this Risk Engine works: its architecture combining a central Risk Controller and self-balancing Control Mesh, integration with TONSWAP's DeFi suite, and the safeguards and testing ensuring it performs under pressure.

Risk Engine Overview🔗

TONSWAP's Risk Engine combines two on-chain components: the Risk Controller (real-time risk assessor and gatekeeper) and the Control Mesh (feedback system that auto-adjusts parameters across modules based on the Risk Controller's assessment).

• Risk Controller (RC): A central smart contract that receives inputs from all products and computes a holistic risk score (the Global Risk Index) for the platform. It tracks each module's risk contribution and the overall "risk posture" (Green = normal, Yellow = elevated, Red = high risk, Black = critical). The RC decides when to tighten or loosen risk measures according to pre-set rules and coordinates two-step authorization for sensitive actions, ensuring nothing significant happens without its sign-off under the current risk posture.
• Control Mesh: An on-chain network of controller routines that executes adjustments when the Risk Controller signals a posture change or detects off-target metrics. It sends control updates to each product module (DEX pools, perps engine, gas vault, insurance fund, etc.) to restore parameters to targets. It's self-balancing—continuously correcting deviations like a thermostat—and bounded (adjustments clamped within safe limits). The mesh runs on a heartbeat, gathering telemetry and issuing commands to keep the system synchronized.

The Risk Controller and Control Mesh work together to manage all product limits, fees, and risk settings on-chain in a unified, deterministic way. The code enforces a cohesive risk policy automatically. Because it's fully on-chain, anyone can inspect or audit it. In essence, the Risk Engine is the single source of truth for risk across TONSWAP, with instant execution.

Risk Controller Contract🔗

The Risk Controller (RC) is the heart of the risk engine—a smart contract that evaluates risk and enforces the platform’s risk posture. Here’s what it does and how it’s built:

• Unified Risk State: The RC maintains all the necessary data to gauge and control risk in one place. It stores module risk weights (how much each factor contributes to the global risk), score caps (limits on each module’s risk contribution), telemetry snapshots (recent metrics reported by modules), the current posture state (Green/Yellow/Red/Black), and registries of authorization receipts (more on these shortly). By keeping this in a single persistent structure on-chain, the controller can “see” the whole chessboard and gate activities across up to a dozen product families in a coherent way. Whether it’s a DEX swap, a perps trade, or a vault withdrawal, the RC knows the context in which it’s happening.
• Safe Default Parameters: The Risk Controller deploys with governed default settings for all key parameters: risk module weights, hysteresis thresholds (Green/Yellow/Red transitions), metric decay half-lives, automation grace periods, and T3 stablecoin buffer targets. The RC starts in a conservative, safe configuration. Governance can fine-tune these values, but out-of-the-box behavior is sane and protective.
• Governance Control: Only the $TS token holders via on-chain governance can tighten risk posture manually, tightening the risk level (Green→Yellow→Red), making the system more restrictive. Loosening is gated by timelock governance. This ensures shields can be raised immediately in a crisis, but not lowered hastily.
• Two-Phase Authorization (Intent & Receipt): A cornerstone of the RC is how it authorizes actions from various products. Because of TON’s asynchronous contract model, the RC can’t just synchronously approve a transaction in one go. Instead, we use a two-phase commit for risky operations:
  • Intent Phase: A product (or a user via a product) first sends an Action Intent to the Risk Controller, basically saying “I intend to do X, with these parameters, and the worst-case impact is Y.” The RC logs this intent and does an initial check (is this product and action type allowed? does the request size seem sane? etc.).
  • Receipt Phase: The RC then computes the latest risk scores, decides if the action is acceptable under the current posture, possibly tweaks some parameters (like allowable slippage or size), and then issues an Authorization Receipt back to the product. This receipt is like a golden ticket that says “You are allowed to do X under these specific conditions, and you have a budget of Y impact to do it.” The receipt is cryptographically tied to the action (including a hash of the critical details) and signed by the RC (in practice, stored as a hash on-chain) so it can’t be forged or reused.

The product contract must present this receipt when executing the action. The RC tracks the receipt via its hash, and the product verifies that hash, the parameters, and that the receipt hasn't expired or been used. If anything is off, execution is rejected. This two-phase flow guarantees authenticity without requiring synchronous RC calls (impossible in our chain). It's like pre-approval before spending from your bank—except enforced by smart contracts. Each receipt includes 0.02 TON to ensure the receiving contract has gas to process it.

• Receipt Consumption & Idempotence: Once a product receives a valid receipt, it executes the action (e.g., trade or withdrawal) via executeWithReceipt(receipt, data, ...). The product consumes the receipt: applies RC-mandated parameters (fee multiplier, leverage cap), uses the allowed effect budget, and marks it used. It sends a Telemetry Notify message to the RC with the outcome. The RC updates metrics, marks the receipt hash consumed (preventing replay), and ignores duplicates. Unexecuted receipts expire. This ensures retries don't cause double-counting, meaning the system is idempotent. Every significant action is pre-approved and accounted for, or blocked.
• Live Telemetry & Fallbacks: Modules continuously send telemetry updates to the RC (e.g., perps volatility, insurance reserves) via a special opcode, keeping the RC's view current. If a module's telemetry goes stale beyond a timeout, the RC assumes failure (like a dead man's switch) and can freeze functions or cap that module's weight in the global risk index. For example, if the Control Mesh stops reporting, the RC might freeze posture escalations or limit automation's influence, preventing a glitchy system from causing false alarms or complacency. Lack of data is treated as potential risk until proven otherwise.

The Risk Controller acts as TONSWAP's vigilant risk brain, monitoring metrics, gating actions, and enforcing rules. The Control Mesh translates those risk decisions into actual parameter adjustments across the platform.

Telemetry & The Global Risk Index (GRI)🔗

Before exploring the Control Mesh, let's take a look at how the Risk Controller calculates risk and the Global Risk Index (GRI) that determines the platform's posture and quantifies current system risk.

• Per-Module Scoring with Smoothing: Each risk module (DEX liquidity, perps volatility, oracle/peg, automation status, etc.) feeds data to the RC. To handle noisy inputs (price swings, volume spikes), the RC uses EWMA (Exponentially Weighted Moving Averages) and smootherstep ramps to smooth sudden changes. It also applies per-second velocity limits on score changes, rate-limiting how fast any module's risk score can increase. This prevents erratic swings and allows graceful reactions.
• Aggregation with Weight Caps: The RC combines module scores (weighted sum) into the Global Risk Index. Not all risk factors are equal or independent. An "automation failure" signal alone won't trigger panic mode if markets are stable. The RC applies an automation weight cap when that module is the sole high signal. The GRI is a weight-normalized sum (each module's score × its weight), with rules to cap contributions when needed. The result: a single number representing overall platform stress.
• Validation of Parameters: Risk parameter updates must pass a strict validation checklist before acceptance. The RC ensures module weights sum correctly, posture thresholds follow the proper order (Green < Yellow < Red < Black), caps are positive, and smoothing factors remain stable. These checks prevent invalid or malicious configurations, ensuring the Risk Controller can never enter an inconsistent state.
• Posture Decisions with Hysteresis: The GRI is continuously evaluated against threshold bands that correspond to the various risk postures (for example, maybe GRI < 0.2 is Green, 0.2–0.5 is Yellow, 0.5–0.8 is Red, >0.8 is Black – just illustrative numbers). However, to avoid the situation where the system flips back and forth if GRI hovers near a boundary, the RC employs hysteresis. This means there are actually two sets of thresholds – one for escalating to a higher risk state and another (slightly lower) for de-escalating to a safer state. The RC will only escalate or relax the posture one tier at a time and at most once per defined time window. There are cooldown timers so that if we go from Green to Yellow, we won’t jump to Red immediately even if the number blips up – we’d need to sustain the higher risk for a certain period, and similarly we won’t drop back to Green too fast. This controlled escalation is crucial for stability: it ensures that when the system is tightening restrictions, it’s doing so deliberately and not overshooting, and when relaxing, it’s confident the risk has abated.
• Visibility into Risk Composition: For the curious Nolans among us, the Risk Controller offers getter functions to query risk info on-chain. You can check the current automation weight, which modules contribute most to the risk score, and the latest telemetry values. This enables dashboards and external reviews. Anyone can observe in real time how factors like perp volatility push the GRI towards Red, or how the automation weight cap activates. This transparency builds trust and at all times the community can see exactly how the risk model operates.

Having established how risk is determined and posture transitions occur, let's examine the Control Mesh—the mechanism that executes system-wide adjustments in response.

Control Mesh: Self-Balancing Parameter Adjustments🔗

The Control Mesh adjusts parameters across TONSWAP's modules based on Risk Controller signals and telemetry, sending coordinated control updates to maintain system stability:

• Governance-Defined Targets & Telemetry Inputs: Governance sets target parameters (T3 peg price, Gas Vault reserves, perps liquidity ratios, insurance thresholds). Modules send telemetry (peg deviation, gas levels, market stress, insurance usage) to the mesh, which calculates deviations from targets.
• Solvers with Hard Clamps: For each domain (peg, fees, gas, perps risk, insurance), the Control Mesh runs a solver algorithm—mini feedback controllers like Peg MPC (adjusts stablecoin peg), Fee Allocator (tweaks fee distribution), Gas PI controller (adjusts gas reserve skimming), Perps LQR controller (manages leverage/funding rates), and Insurance CVaR surrogate (adjusts insurance contributions). Each solver computes an ideal adjustment from telemetry to correct deviations. All outputs are bounded by hard clamps—even if a glitch outputs "set fee to 500%," the mesh clamps it to a safe maximum. These pure functions are deterministic (same inputs = same output), ensuring auditability and predictability.
• State and Monotonic Sequences: The Control Mesh stores latest telemetry, solver decisions, and sequence counters. Each heartbeat increments sequences and updates decisions. Persisting state ensures cycles are reproducible (off-chain replay yields identical results) and each update has a unique sequence. Monotonic sequences let modules reject out-of-order or stale messages.
• Heartbeat: The Coordination Cycle: The Control Mesh doesn’t just continuously spew out updates; it operates in discrete cycles triggered by a heartbeat function (which any authorized party can call, often the Gas Vault or a keeper-like automaton funded by it – but note, this is a permissioned action requiring a deposit). When a heartbeat is called, the mesh will:
  • Aggregate latest telemetry: It pulls in the fresh telemetry readings from all sources (or uses stored values if none new).
  • Run solver updates: It computes any adjustments needed using the solvers, considering the current risk posture as well (for instance, if we’re in a higher risk posture, the targets might shift or the aggressiveness of adjustments might change).
  • Increment sequence numbers and store decisions: It updates the internal sequence counter and records the new control outputs.
  • Dispatch control messages: Sends messages to each module with new directives (T3 peg adjustment, Gas Vault skim ratio, perps max leverage/funding rate, etc.).

If automatic control is disabled (by governance or RC freeze in high-risk scenarios), the heartbeat won't dispatch or will be rejected, acting as a safety gate. Heartbeats only trigger changes when conditions are normal or governance-approved.

• Documented Fallbacks and Overrides: The Control Mesh has clear rules for edge cases. If telemetry stales, the solver enters "hold" mode or uses a safe default. Manual overrides by governance or operators are allowed but constrained: overrides must respect solver clamps (no unsafe values) and bump sequence numbers to prevent confusion when resuming normal operation. All behaviors—stale telemetry handling, override mechanics—are documented in code. Goal: operators know exactly how the system responds to faults. Predictability is key; even in chaos, the control mechanism behaves predictably.

In simpler terms, the Control Mesh is like an automated maintenance crew that, every few seconds or minutes, checks all the readings (pressure, temperature, etc. of our DeFi machine) and gives each subsystem a gentle nudge to keep things running smoothly. If something’s off (peg is drifting, gas is low, a perps market is overheating), it applies a calibrated fix within safe boundaries. And it does so by paying for the privilege, ensuring the fixes are delivered. The result is a DeFi platform that self-corrects continuously, rather than waiting for some external actor to notice and intervene.

Module Integration: How Products Work with the Risk Engine🔗

Here's how TONSWAP modules integrate with the Risk Controller and Control Mesh. Every module speaks the same risk language and follows the same patterns:

• T3 Stablecoin Treasury: T3 is TONSWAP's composite stablecoin (a basket of USD-pegged stablecoins). The T3 hub sends telemetry to the Risk Controller: peg deviation (holding $1 or drifting?), queue depth (withdrawals/mint requests queued), skew (basket imbalance), and fee buffer levels. This helps the RC gauge stability. T3 also receives peg adjustment directives from the Control Mesh during inline catch-up. The mesh may instruct T3 to adjust fees, rebalancing speed, or slow redemptions to protect liquidity. This occurs during normal operation (often in the same transaction as user actions—"inline catch-up" means the next user action triggers pending control updates, keeping the module current without separate keeper transactions).
• Gas Vault (Automation Funding): The Gas Vault collects fees to fund automated transactions. It reports telemetry (gas reserves vs. targets, task backlog) to the Control Mesh, which adjusts the skim ratio (fee diversion percentage) accordingly. Low reserves increase the skim; sufficient funding reduces it. Updates apply during heartbeats or maintenance, ensuring continuous automation funding. The Gas Vault (or whitelisted sender) must call the heartbeat and supply 0.04 TON from reserves.
• Perpetuals Engine: The perps engine streams telemetry (per-market volatility, queue depths, insurance fund status) to the Risk Controller, which adjusts risk scores accordingly. The engine also receives Control Mesh directives during normal operation (funding payments, liquidations). In elevated risk postures, the mesh may instruct lower max leverage (is 1337x leverage modest?), wider funding bands, or paused actions. The engine applies these "inline catch-up" adjustments automatically, reducing new exposure or slowing liquidations—without keeper intervention.
• CLMM Router (DEX aggregator/router): The CLMM router executes swaps on the DEX and reports spot market depth telemetry to the Risk Controller (shallow liquidity indicates higher risk). The Control Mesh adjusts trade execution parameters like TWAP slicing: in normal conditions, large swaps execute in big chunks; under elevated risk, the mesh instructs smaller slices over longer intervals to reduce market impact. This happens automatically without any keeper; the router applies current control settings at the time when trades arrive. During volatility, large trades execute slower or with adjusted fees per on-chain policy protecting liquidity.
• Insurance Fund & Fee Sink: These modules receive mesh guidance on reserve accumulation and fee distribution based on CVaR calculations. The Control Mesh's heartbeat dispatches synchronized updates to all modules simultaneously, prepaying gas for each message. This ensures coordinated platform-wide adjustments, so all modules receive the latest sequence number and act in unison, preventing scenarios where one module adjusts while others lag.

Each TONSWAP product sends telemetry (source of truth) and receives adjustments (subject to control) from the risk engine. This two-way integration enables unified risk management and keeper-free automation with fine-grained control.

Governance, Safety Nets, and Automation Guarantees🔗

Let's clarify how governance and safety work in the risk engine, and how we prevent catastrophic automation failures:

• Atomic Governance Updates: When the community votes to change a risk parameter, the Risk Controller validates it (checking sums, thresholds order) before activation. It recomputes the Global Risk Index immediately using new settings and adjusts internal smoothing thresholds in one atomic transaction, preventing inconsistent in-between states. RC updates are all-or-nothing and self-consistent. The moment new config goes live, risk scores and posture recalculate under the new regime, preventing surprises like an erroneously low threshold triggering instant posture jumps.
• Capability Tokens for Pre-Approval: For high-frequency actions (swaps, small trades), requiring full RC approval each time would be too slow. The Risk Controller issues capabilities—pre-approved "work permits" for modules. Example: the RC grants the CLMM module a capability allowing "up to X volume of swaps in Y minutes without further approval". Capabilities have TTLs and effect budgets like receipts, but skip the two-phase process. Products consume (burn) capability tokens when actions occur, then report back to RC. Capabilities can be revoked or expire, keeping RC in control. This ensures fast-paced actions have risk limits without constant overhead—like giving a trusted module a limited credit line. Governance or RC can issue and revoke these on demand, temporarily authorizing or pausing operations.
• Automation Cannot Panic Alone (Let’s all Panic Together): A critical safety feature: the Control Mesh cannot trigger platform-wide panic by itself. The Risk Controller treats automation status as a special module. If financial modules show normal telemetry but automation signals high risk or stale data, the RC won't declare an emergency. Instead, it elevates the automation risk flag and may freeze posture changes rather than escalate overall posture. If automation malfunctions, the system holds steady or pauses safely, it won't liquidate positions just because automation had a glitch. This prevents Control Mesh bugs or network issues from triggering cascades. The system defaults to fail-safe mode (halting new risky actions) until automation recovers, but won't auto-liquidate when only automation signals red while markets remain green.
• Heartbeats Require Funding & Sanity: Automation heartbeat calls are gated. The Gas Vault or authorized sender must pay at least 0.04 TON for the heartbeat to run. If the Control Mesh is disabled (e.g., governance paused automation in a crisis), the heartbeat function rejects calls. This prevents heartbeat spam and malicious control loop attempts (unauthorized calls are rejected; authorized calls during pause are also rejected). The value requirement naturally rate-limits heartbeat frequency based on available gas funding.
• Manual Overrides with Controlled Impact: Governance overrides are designed to be safe and reversible. Manual control messages are clamped to solver-defined safe ranges, preventing destabilizing values. When an override is issued, the mesh increments the sequence number, ensuring downstream modules treat it as a fresh update and drop any delayed or stale messages. This prevents conflicting commands. Overrides cleanly insert into the command stream, allowing seamless resumption of automated decisions once lift, making them a reliable emergency tool without risking inconsistent states.

Bottom line: failsafe by design. We assume failures can happen, such as stalled oracles or contracts running out of gas, so we build protections to prevent or minimize their impact. The Risk Engine and automation serve as shields, not vulnerabilities.

Testing & Observability🔗

The Risk Engine demands rigorous testing. We built comprehensive test suites and observability tools to ensure reliability:

• Risk Controller Basics Test Suite: End-to-end tests simulate core RC flows: enabling (stake/activate), product registration, capability issuance/consumption, two-phase intent → receipt → execution, and telemetry reconciliation. We mimic actions (trades, withdrawals) in a sandbox to verify RC handles intents and receipts correctly, updating scores and posture as expected. Tests confirm RC logic works with real contract interactions and that idempotence (no double-counting) functions even with out-of-order or late messages.
• Control Mesh Test Suite: Tests feed sample telemetry to the mesh, trigger heartbeats, and verify outputs match solver algorithms. We test manual overrides using compiled contracts in sandbox. Example: simulate peg drift, volatility spike, low gas vault – run heartbeat and confirm sensible updates (peg adjustment, increased skim, reduced leverage) within clamps. Verify idempotency and appropriate responses to state changes. Override tests ensure injected overrides take effect as intended.
• Control Solvers Deterministic Tests: We test each solver algorithm (peg control, fee allocation, gas PI, perps LQR, insurance CVaR) with varied inputs to verify: (1) deterministic and stable outputs (same input → same output; small input changes → proportionate output changes), and (2) outputs respect clamps and invariants (never exceeding max values, never going negative when disallowed). This unit-tests the Control Mesh's mathematical core in isolation.
• Module Integration Tests: We test how the risk engine interacts with products. Perps automation tests simulate volatile markets to verify the module enters reduce-only mode in Red posture and schedules liquidations under risk constraints. CLMM TWAP integration tests simulate large swaps across risk postures to confirm the router adjusts slicing per instructions without keepers. T3 (stablecoin) scenarios test sudden constituent depegs to verify the T3 hub takes corrective action (slowing withdrawals, raising fees, notifying RC to escalate posture). These realistic workload tests ensure the risk layer and product layer stay synchronized under high load and complex interactions.
• On-Chain Getters for Monitoring: The Risk Controller and Control Mesh provide read-only getters for users and monitoring tools to query: GRI breakdown (module scores, weights), module telemetry snapshots (perps volatility, peg deviation, etc.), and control outputs (last peg adjustment, sequence number). This enables real-time dashboards showing Global Risk Index, current posture, top risk contributors, and recent control actions—all fetched directly from the blockchain. This transparency is rare in DeFi and aids debugging by allowing on-chain state inspection.

In short, we’ve not only built DeFi’s most robust risk engine but also verified its behaviour through rigorous testing and made its inner workings visible. When dealing with billions of users and billions in user assets, nothing less would do. Billions must TONSWAP.

Summary🔗

The TONSWAP Risk Engine is our answer to the question: “How do you prevent DeFi users from getting rekt?” By anchoring all risk detection and response entirely on-chain, we remove dependencies on human intervention and off-chain bots, which can be slow or unreliable. Instead, we embrace the principles of DeFi in every TONSWAP product, so whether it’s the DEX, the stablecoin, perps, launchpad, farm, or any future module, data feeds into and is managed by this robust and comprehensive unified risk framework.

Products submit telemetry; the Risk Controller scores risk and adjusts platform posture as needed. The Control Mesh then issues directives, such as adjusting fees, liquidity, peg rates, gas allocation, which the TONSWAP products implement immediately. This closed-loop runs continuously, keeping the system safe. If a crisis occurs, clamps, hysteresis buffers, and fallback rules ensure deterministic behavior. Everything is logged on-chain, making the system autonomous, self-adaptable, and auditable in real time.

The result is a platform that is autonomous yet controlled. We've hard-coded crisis-response best practices directly into smart contracts. The Risk Engine won't stop external market crashes, but ensures TONSWAP reacts instantly, cutting leverage, halting risky actions, protecting liquidity, prioritizing longevity, all without the need to bring in any wetbrains.

For DeFi users, this means TONSWAP is built for both calm and chaotic markets. October 2025's lessons are built into our design. This deep dive shows the engineering safeguarding your assets and the protocol. The Risk Engine is your silent guardian, working 24/7 for you.

Welcome to the new era of smart on-chain DeFi. TONSWAP is the DeFi Platform for Mass Adoption on TON.

Join our telegram chat if you aren't afraid of black swans!

Samurai Cats are not afraid of the black swans. Play MeowFi now on Telegram

Disclaimer: Cryptocurrency trading involves significant risk and volatility. This article is for informational purposes and does not constitute financial advice. Past performance of any token or network (including TON or SORA) is not indicative of future results. Always do your own research and consider your risk tolerance before participating in DeFi or trading. Use TONSWAP and related financial tools responsibly, and consult with a financial advisor if you have any concerns. Keep in mind that while TONSWAP and the TON network offer advanced features and integrations, there are always risks in smart contract platforms, so never trade or provide liquidity with funds you cannot afford to lose.