DeFi Threat Modeling Explained: How STON.fi Maps Security Risks on TON

A practical breakdown of threat modeling in decentralized finance — using STON.fi’s router, Omniston, resolvers, and cross-chain swaps as a real-world case study.

Most people who use DeFi never think about threat modeling, and honestly, why would they? You open an app, you swap a token, it works. But every time it does work, someone somewhere already asked an uncomfortable question: where exactly could this fail, who would benefit from that failure, and what happens the moment it does? That question is threat modeling, and it’s a lot less abstract than it sounds once you map it onto something like STON.fi, one of the largest DEXs on The Open Network (TON).

I like using STON.fi as a teaching example precisely because it isn’t a single monolithic app — it’s a router, a set of pool contracts, an aggregation layer called Omniston, resolvers who supply liquidity, and a UI sitting on top of all of it. Every one of those pieces is a separate attack surface, and separating them out is exactly what a real threat model does before you can decide where the “solid economic assumptions” actually need to hold.

Here’s my honest take: threat modeling isn’t really about paranoia. It’s about refusing to assume “decentralized” automatically means “safe.” Decentralization moves trust around — it doesn’t delete it. Someone still has to hold liquidity, sign something, or run a resolver, and each of those someones is a place where things can go sideways.

🧩 What Is Threat Modeling in DeFi? Start With the Boxes, Not the Threats

The instinct when you hear “threat modeling” is to jump straight to attacks — reentrancy, oracle manipulation, front-running, the greatest hits. That’s backwards. The actual first step is boring on purpose: draw every component, every trust boundary, every place where control or custody changes hands, before you try to guess how anyone would break in.

On STON.fi, that map looks roughly like this: a router that receives and routes swap messages, pool contracts that hold reserves and calculate prices, account and wallet contracts that track individual LP positions, and — once you add cross-chain swaps into the picture — Omniston’s resolver network and the paired HTLCs (Hashed Timelock Contracts) that coordinate settlement across two independent blockchains. Each box has a different owner, a different upgrade path, and a different failure mode. The router is upgradeable under a time-locked process; the pools are documented as immutable; the resolvers are independent, profit-motivated third parties who never touch your private keys but absolutely touch your funds mid-swap.

Once the boxes exist on paper, you stop asking “is STON.fi secure?” — which is a meaningless question — and start asking “which specific box, under which specific condition, fails first?” That reframing alone does most of the useful work.

🎯 Where the Real DeFi Attack Surface Actually Lives

Here’s where it gets interesting, because the attack surface on a system like this isn’t just “the smart contract code.” It’s the sum of everything that could go wrong across every box you drew, including the boring administrative stuff nobody puts in a pitch deck.

A few categories worth separating out explicitly:

• Contract logic risk — bugs in swap math, fee calculations, or LP accounting. This is what audits like Trail of Bits’ review of STON.fi v2 are specifically built to catch, and it’s the category people think of first because it’s the most “technical.”
• Administrative/governance risk — who can trigger a router upgrade, what the time-lock window actually protects against, and whether that window is long enough for anyone to meaningfully react before a bad upgrade activates.
• Economic/liquidity risk — thin pools, resolver capacity limits on cross-chain routes, and price manipulation through low-liquidity pairs. None of this is a “hack” in the traditional sense, but it can drain value just as effectively.
• Operational risk — the parts everyone forgets: RPC providers going down, frontend compromise, DNS hijacking of the official domain, a resolver simply going offline mid-settlement.

I’d argue that last category is chronically underrated in crypto security discourse. Everyone obsesses over reentrancy bugs while a fake frontend on a lookalike domain has probably caused more real financial damage across DeFi than any single smart contract exploit this year. Threat modeling forces you to give operational risk the same seriousness as contract risk, instead of treating it as an afterthought.

🔐 Cross-Chain Swap Security: A Threat-Modeling Case Study

If you want a genuinely good exercise in this, look at how STON.fi’s cross-chain swaps via Omniston handle the trust problem, because it’s a clean illustration of “moving trust instead of removing it.”

Instead of a bridge holding a giant shared reserve, Omniston uses resolvers who compete on price and independently supply the destination asset, locked in a Hashed Timelock Contract paired with a matching lock on the source chain. The atomicity comes from a shared cryptographic secret — reveal it, both sides settle; fail to reveal it before the deadline, both sides refund. From a threat-modeling perspective, this is a genuinely different risk profile than a lock-and-mint bridge: there’s no single reserve contract to drain, but there is now a dependency on resolver liveness and honest timelock behavior on two separate blockchains that don’t know about each other.

That’s not a weakness exactly — it’s a trade-off, and naming the trade-off explicitly is the entire point of the exercise. A threat model doesn’t conclude “this is safe” or “this is unsafe.” It concludes “here is exactly what has to go right, and here is what happens in each specific way it could go wrong.”

🛠️ What DeFi Builders Actually Get Out of Threat Modeling

The payoff for builders isn’t a checklist you tick once and forget — it’s a map you keep updating as the system changes. Once you’ve broken a protocol into components and mapped its trust boundaries, you know exactly which pieces deserve the deepest audit attention (usually the immutable, high-value contracts and anything that touches cross-chain settlement) versus which pieces need operational monitoring instead of more code review (frontend integrity, RPC reliability, resolver uptime).

It also reframes how you think about upgrades. A seven-day router time-lock isn’t a security feature in isolation — it’s only meaningful in the context of a threat model that assumes someone is actually watching during that window and capable of reacting. Remove the “someone is watching” assumption, and the time-lock becomes decorative. Threat modeling is what forces you to notice that dependency instead of quietly assuming it away.

👤 What This Means for Everyday DeFi Users

You don’t need to build the full threat model yourself, but understanding that one exists changes how you use these protocols. It’s the difference between blindly trusting a slippage number and understanding why that number exists — because a quote is fundamentally an estimate under conditions that can change before your transaction lands. It’s the difference between assuming an audit means “nothing can go wrong” and understanding it means “this specific version, at this specific time, had these specific things checked.”

Practically, that translates into habits that cost you almost nothing: verify the domain before connecting, treat a bug bounty as an ongoing safety net rather than proof nothing’s wrong, and remember that in a resolver-based system, a stuck or delayed swap isn’t automatically a scam — it might just be a timelock doing exactly what it was designed to do while you wait.

My honest closing thought: the protocols that publish their threat models, their audit scopes, and their bounty programs openly aren’t doing it because they’re less risky than the ones that don’t. They’re doing it because they’ve actually done the work of figuring out where they’re fragile — and telling you that upfront is a far better signal than a marketing page that claims to have none.

Security in DeFi was never going to be a switch you flip once. It’s a map you keep redrawing as the system grows new components, and the protocols worth trusting are the ones that keep redrawing it in public.

❓ Frequently Asked Questions

What is threat modeling in DeFi? Threat modeling is the process of mapping a system’s components, trust boundaries, and failure points before analyzing specific attacks — identifying where risk actually lives (contracts, governance, liquidity, or operations) rather than assuming decentralization equals safety.

Is STON.fi safe to use? STON.fi uses layered security measures including non-custodial design, immutable pool contracts, a time-locked router, an independent Trail of Bits audit, and a live HackenProof bug bounty. No DeFi protocol is risk-free, and users should still verify domains, review transactions, and understand wrapped-asset or resolver-based risk before swapping.

How do STON.fi’s cross-chain swaps work? STON.fi uses Omniston, which requests quotes from competing resolvers and settles trades through linked Hashed Timelock Contracts (HTLCs) on the source and destination chains, rather than relying on a bridge with a shared reserve.

What’s the biggest overlooked risk in DeFi security? Operational risk — fake frontends, DNS hijacking, and compromised RPC providers — is often underestimated compared to smart contract bugs, despite causing significant real-world losses across the industry.

📚 Sources and Further Reading

• STON.fi Developer Documentation: https://docs.ston.fi/
• STON.fi Security — Audits and Bug Bounty: https://docs.ston.fi/getting-started/security
• STON.fi DEX Architecture: https://docs.ston.fi/developer-section/dex/architecture
• Omniston Protocol Overview: https://docs.ston.fi/developer-section/omniston/overview
• Omniston explained — how cross-chain swaps on TON work without a bridge: https://blog.ston.fi/omniston-explained-how-cross-chain-swaps-on-ton-work-without-a-bridge/
• Trail of Bits — STON.fi TON AMM DEX v2 Security Review (Jan 2025): https://github.com/trailofbits/publications/blob/master/reviews/2025-01-stonfi-ton-amm-dex-v2-securityreview.pdf
• STON.fi DEX Smart Contracts v2 Bug Bounty (HackenProof): https://hackenproof.com/programs/ston-dot-fi-dex-smart-contracts-v2
• Threat Model — general background reading: https://en.wikipedia.org/wiki/Threat_model

Tags: DeFi Security, STON.fi, TON Blockchain, Threat Modeling, Cross-Chain Swaps, Omniston, Crypto Security, Blockchain Development