What Pool Version Really Tells You on STONfi — V1 vs V2 as Contract Generations

Somewhere on a pool's page on STONfi there's a small label telling you which version you're looking at. Easy to skip right past it, and most people do, because it looks like a version number the way an app update looks like a version number — background detail, not something that actually changes your risk or your returns. That instinct is wrong here in a way worth correcting, because V1 and V2 aren't cosmetic updates to the same pool. They're different contract generations, with genuinely different mechanics underneath, and treating them as interchangeable is exactly how people end up comparing two things that were never actually comparable in the first place.

It's a small label with an outsized amount riding on it, and the gap between how much attention it gets and how much it actually explains is really the whole reason this is worth writing about at all.

A version number is really a statement about which code you're trusting

When people hear "V1" and "V2," the natural assumption is that V2 is just V1 with some bugs fixed and a nicer interface. Sometimes that's roughly true across software in general. It's not the right way to think about it here.

STONfi's V1 and V2 pools are separate contract implementations, deployed independently, each with their own logic for handling swaps, reserves, and liquidity accounting. A pool's version isn't a cosmetic label — it's telling you literally which code is executing your trade and holding your deposited liquidity if you become an LP there. Two pools for the same token pair, one on each version, aren't the same pool with a different coat of paint. They're two different pieces of code that happen to serve a similar purpose, built at different times, with different assumptions baked into how they work.

I didn't actually internalize this until I went looking for why two pools for what I assumed was the "same" pair behaved a little differently under similar conditions. Turned out I wasn't comparing the same pair at all — I was comparing two different implementations of it, and no amount of staring at the surface-level numbers was going to explain the gap until I noticed the version label.

This matters beyond curiosity. If something about a pool's mechanics ever needs scrutiny — how it handles an edge case, how its fee logic actually works, what its liquidity accounting assumes — the answer depends entirely on which version you're actually looking at. A general statement about "how STONfi pools work" is incomplete unless it specifies which generation it's describing.

What actually changed between generations, and why it's not incremental

V2 introduced real architectural differences, not just incremental tuning. The most significant is a vault-based system sitting underneath liquidity management, alongside expanded support for different pool types — beyond the standard constant-product model, V2 supports StableSwap pools and weighted pools, which behave differently depending on how closely correlated the paired assets actually are.

That matters because a constant-product pool and a StableSwap pool aren't just different flavors of the same math. A StableSwap-style pool is specifically designed around assets expected to trade close to parity with each other — think two stablecoins — and it concentrates liquidity efficiency around that narrow price band in a way a standard constant-product pool doesn't attempt to do. A weighted pool changes the underlying exposure ratio between the two assets entirely, which isn't something V1 pools offer at all. None of these variations existed under V1; they're capabilities that only exist because V2 was built as a genuinely new generation, not a patch applied to the old one.

A few concrete things worth checking once you know which generation you're looking at:

  • Whether the pool is a plain constant-product design or one of V2's newer types, since that alone changes what "normal" price behavior looks like for that pair

  • Whether the pool is designed around correlated assets or genuinely independent ones, since that shapes both expected volatility and expected liquidity efficiency

  • Whether the fee configuration you're seeing reflects V2's more flexible per-pool settings or an older, more fixed V1 structure

So "V2" isn't one single thing you're either dealing with or not. It's a generation that unlocked several different pool behaviors depending on which specific type you're actually looking at within it, and lumping "V2" together as one category can be almost as misleading as ignoring version entirely.

The part that surprises people: V1 pools didn't get erased

A reasonable assumption when a new version ships is that the old one quietly goes away — deprecated, migrated, forgotten. That's not what happened here. V1 pools continue operating as deployed, with their original code intact, because STONfi's pool contracts are immutable once live. Nobody rewrote V1 pools into V2 pools. They coexist, as genuinely separate deployments, and a V1 pool for a given pair can still be sitting there holding real liquidity while a V2 pool for the same pair exists entirely separately, active at the same time, sometimes with meaningfully different conditions.

This threw me the first time I noticed it. I went looking for "the" pool for a pair I traded often and found two, both active, both with real liquidity, neither one a leftover ghost of the other. My assumption going in was that the newer version had simply replaced the old one, and that assumption turned out to be flatly wrong.

That coexistence is worth sitting with, because it means checking "which version" isn't a one-time historical curiosity — it's an ongoing, live question every time you're choosing where to trade or where to deposit. Here's roughly how I actually work through it now, in order:

  1. Search for the pair and note every pool that comes up, rather than clicking into the first result

  2. Check the version label on each one before comparing anything else about them

  3. Compare TVL, volume, and fees only between pools that share the same version and type, not across different generations as if they were describing the same thing

Skipping straight to step three without steps one and two is exactly how a shallow, quiet V1 pool sitting next to a deep, active V2 pool for the same tokens ends up looking, on paper, like two versions of one thing. In practice it's closer to two separate markets that happen to share a token pair.

Why this changes what liquidity providers specifically need to check

If you're providing liquidity, the version isn't background information — it determines which contract logic is actually holding your funds and processing every swap against your position. A V1 pool and a V2 pool for the same nominal pair can have meaningfully different liquidity depth, different fee dynamics, and different overall activity levels, simply because liquidity providers and traders don't necessarily split evenly between generations. One version might be where most of the real volume for that pair actually concentrates, while the other sits comparatively quiet, earning correspondingly less in fees despite looking similar on a surface glance.

That has a direct, practical consequence: TVL and volume figures need to be read per-pool, per-version, not assumed to represent "the pair" as some unified concept. Fee configuration and pool type interact directly with version too, and treating them as separate questions is where comparisons go wrong fastest. A V2 StableSwap pool designed for closely correlated assets, a V2 weighted pool with an uneven exposure split, and a plain V1 constant-product pool can each show different yield behavior for what looks like a comparable amount of deposited capital — not because one is definitively better, but because they're structurally different machines answering the same surface-level question in different ways.

This is really the same lesson that applies to TVL in isolation: a single number, viewed without its structural context, tells you less than it appears to. Version is part of that structural context, not a footnote sitting beside it, and skipping it means every other comparison you make afterward is built on an assumption that might not hold.

🧭 How this actually shows up on STONfi's own pool pages, and the habit worth keeping

This isn't a detail you have to dig for — STONfi's pool listings surface version directly, and it's worth reading it as seriously as you'd read TVL or fees rather than skimming past it on the way to the numbers that feel more immediately important. When you're comparing two pools for the same pair, checking version first tells you whether you're actually looking at a fair comparison at all. A V1 pool and a V2 StableSwap pool for what sounds like the identical pair aren't directly comparable on TVL or APR alone, because the underlying mechanics generating those numbers aren't the same. Reading version alongside pool type — which STONfi also displays — gives you the actual shape of what you'd be depositing into, before a single dollar figure enters the picture.

What changed my own habit here wasn't a warning, it was a disappointing result — depositing into what I assumed was "the" pool for a pair, only to realize afterward there was a second, more active version I hadn't checked for. Cheap lesson, but I'd rather have learned it reading a pool page than by comparing returns after the fact.

Because STONfi's pool contracts are immutable, checking version isn't something that becomes outdated the way a general market observation might. A V1 pool's core mechanics today are its mechanics permanently — what can shift is liquidity, volume, and fees within whatever range that version's code allows, not the underlying contract logic itself. Before comparing two pools, or before depositing into one, check the version the same way you'd check TVL or fees — as a first-class piece of information, not metadata sitting in small text. Version isn't a tiebreaker you check after everything else looks equal. It's context that determines whether "everything else" was ever actually comparable to begin with.

❓ FAQ

Were V1 pools shut down or migrated when V2 launched? No. V1 pools continue operating as originally deployed, since STONfi's pool contracts are immutable — V1 and V2 pools for the same pair can exist simultaneously as genuinely separate deployments.

Is a V2 pool always better than a V1 pool for the same pair? Not automatically. It depends on where liquidity and volume actually concentrate for that specific pair, and on which pool type is involved — a quiet V2 pool isn't inherently better than an active V1 one.

Why do StableSwap and weighted pools only exist under V2? They were introduced as part of V2's architecture. V1 only supports the standard constant-product model, so those pool types simply aren't available under the earlier generation.

Does checking pool version matter for traders, or only for liquidity providers? It matters for both. Traders care because liquidity depth and price impact can differ meaningfully between versions of the same pair; LPs care because it determines which contract logic actually holds their deposited funds.


$GRAM

GRAM
GRAMUSDT
1.428
+1.13%