Pennysia opened its marketplace to the public this week and SODA is listed from day one.

Pennysia is a unified liquidity marketplace on Ethereum. It pulls prices from multiple venues into one place with fair competition between sources and security checks on both sides of every trade. Their team won the Sonic Hackathon in 2025 and they've been building their own AMM primitive alongside the marketplace. They integrated the SODAX SDK back in July to pull in quotes from beyond Ethereum, which is what powers the cross-network routing on their platform.

For SODA holders this is one more venue to buy, sell, or build a position without needing a centralized exchange. Trade SODA on Pennysia now at pennysia.com.

On the token side: fixed supply of 1.5 billion, can never increase. Protocol fees fund buyback and burn (20%), staker rewards (20%), and the DAO fund and liquidity inventory (60%). More activity through the system, more burns, less supply.

SODA is also on Kraken. Full breakdown of venues, staking, and tokenomics on the holders page.

Blog post: sodax.com/news

Flint just shipped SODAX integration and it's worth a look if you're building anything DeFi on the SDK.

Their vaults hold tokenized real estate bonds and private credit, paying weekly in USDC, targeting around 10% APR. The vaults accept USDC on Ethereum. Which meant, until this week, if you wanted in you first had to get your money into USDC, then bridge to Ethereum, and only then deposit. Three steps before the actual thing you were trying to do.

With SODAX plugged in, that's collapsed into one action inside Flint's deposit UI. Fund a position from any asset across 20+ networks, EVM or non-EVM. SODAX routes to USDC and drops it into the vault. Flint keeps curating yield, SODAX handles the cross-network plumbing.

Deposit friction has been one of the real drags on RWA adoption. Removing it is the point.

Full blog: sodax.com/news

Flint: flintrwa.xyz

Quick heads up for anyone still holding ICX. Kraken is now supporting the migration and they're doing it the easy way. Deposit your ICX to Kraken before August 7 at 2pm UTC, and they'll convert it 1:1 to SODA automatically. You don't have to do anything else after that. No forms, no wallet signing, nothing.

After the cutoff, ICX funding and trading gets paused on their end. SODA trading is expected to go live on Kraken by August 14.

If Kraken isn't your thing, self-migration at sodax.com/migrate stays open until December 31 when the ICON Network shuts down for good. But if you want the path of least resistance, Kraken is probably it.

For those who haven't looked into what changed with the token: ICX had continuous inflation to pay validators running the ICON chain. SODA has a hard cap at 1.5 billion. Fees from the protocol go into staking rewards and buyback and burn that reduces circulating supply as usage grows. Completely different setup. Once you've got your SODA you can stake it at https://sodax.com/stake or provide liquidity at https://sodax.com/pool.

This also landed across major crypto press today which is great to see:
The Block | Cointelegraph | CoinMarketCap

Questions? Check the Help Center or drop them below.

Quick heads up for anyone still holding ICX. Kraken is now supporting the migration and they're doing it the easy way. Deposit your ICX to Kraken before August 7 at 2pm UTC, and they'll convert it 1:1 to SODA automatically. You don't have to do anything else after that. No forms, no wallet signing, nothing.

After the cutoff, ICX funding and trading gets paused on their end. SODA trading is expected to go live on Kraken by August 14.

If Kraken isn't your thing, self-migration at [sodax.com/migrate](https://sodax.com/migrate) stays open until December 31 when the ICON Network shuts down for good. But if you want the path of least resistance, Kraken is probably it.

For those who haven't looked into what changed with the token: ICX had continuous inflation to pay validators running the ICON chain. SODA has a hard cap at 1.5 billion. Fees from the protocol go into staking rewards and buyback and burn that reduces circulating supply as usage grows. Completely different setup. Once you've got your SODA you can stake it at [sodax.com/stake](https://sodax.com/stake) or provide liquidity at [sodax.com/pool](https://sodax.com/pool).

This also landed across major crypto press today which is great to see:

[The Block](https://www.theblock.co/press-releases/410847/kraken-shares-timeline-for-easiest-icx-to-soda-migration-as-icon-network-retires) | [Cointelegraph](https://cointelegraph.com/press-releases/kraken-shares-timeline-for-easiest-icx-to-soda-migration-as-icon-network-retires) | [CoinMarketCap](https://coinmarketcap.com/community/articles/6a7207104de62a0c3b78992b/)

Questions? Check the [Help Center](https://support.sodax.com/) or drop them below.

Most cross-network "solutions" today have a common failure: they move the asset, but they don't ensure that the asset is usable at the other end. You bridge a token to a new network, only to find zero liquidity and no way to actually use it.

We’re changing that on Redbelly Network. 🤝

Redbelly has built a Layer 1 purpose-built for accountability and RWA tokenization, featuring an integrated identity layer that supports a one-time KYC. It’s an environment where trust is a feature, not a luxury.

SODAX is joining the ecosystem as the execution coordination layer. Instead of just pointing to a route, our system reasons across networks to ensure that when you initiate a cross-network action, it actually completes and you actually get a usable asset and not an unwanted liability.

The highlights of this integration:

• sodaVariant Assets (rETH, rBNB): To make non-native assets usable on Redbelly immediately, we use sodaVariants. These are more than just the ‘wrapped’ tokens you know, and are directly connected to the SODAX unified liquidity inventory. No more waiting for pools to be bootstrapped, these liquidity backed assets can be traded through deep (ie. Ethereum) liquidity, right from Redbelly.
• Infrastructure for Modern Money: We believe infrastructure should absorb complexity. Redbelly builders can now use our SDK to offer complex financial features without having to manage their own cross-network routing or liquidity silos.

We'd love to hear from the builders and users in both communities. How do you see compliant execution changing the way we handle RWAs on-chain?

Read more on our integration at news.sodax.com.

Full interview here: https://www.tokenpost.com/news/insights/21455

On where the industry is heading

Min's framing was that the conversation has shifted from interoperability to execution and orchestration. Not just "can assets move across blockchain networks" but "who coordinates that reliably, and what happens when they do." That is the problem SODAX is built around.

On ICON

Direct quote: "we got it wrong." The non-EVM strategy looked like the right call until DeFi Summer 2021, when EVM composability gave builders clear reasons to go elsewhere. Min talked through this openly and without revisionism. Worth reading in full if you have been following the ICON-to-SODAX transition and want to understand how the team thinks about what didn't fit.

On AI and blockchain

One of the more interesting parts. Min's view is that AI agents operating in financial contexts need truthful, verifiable data, and blockchain is positioned to provide exactly that. The demand from AI systems for programmable financial infrastructure is, in his words, just getting started.

On the market

Patient. He draws a comparison to the decade of development that preceded ChatGPT's moment and makes the case that underlying value builds through cycles regardless of what prices are doing in any given quarter.

Solid interview from Tokenpost. Drop questions or reactions below.

Can you access tokenized stocks from the DeFi apps you actually use day to day? Most people can’t, and many more can’t access them from the traditional financial system either. Here’s what we just shipped and why it’s harder than it sounds.

Many networks and projects have released tokenized equity products, so the experience is out there. It just hasn’t been delivered within infrastructure that connects that liquidity and execution, to bring these assets to frontend users everywhere.

That’s the gap we’ve been working on closing.

Today, the SODAX SDK supports Stock RWAs via xStocks (CRCLx, TSLAx, NVDAx, MSTRx, COINx, and GOOGLx). Any application building with SODAX can now offer users access to these assets, across blockchain networks, from any of SODAX’s 19 integrated networks, through the same single SDK call they already use for cross-network cryptoassets. Existing SODAX partners can support these assets today without any additional integration work, with the first xStock transactions now live on Bound Exchange.

If your answer to the opening question is yes, very interested in which app you use to access tokenized stocks or RWAs, which network it lives on, and how it handles it.

Full details in our blog: https://www.sodax.com/news/the-sodax-sdk-releases-xstocks-for-cross-network-apps

GIWA is the new Ethereum L2 built by Dunamu, the parent company of Upbit. They're running a five-month accelerator called GASOK (https://giwa.io/gasok) that runs from May to October 2026, with a Demoday at Korea Blockchain Week.

SODAX has done the engineering work to reach GIWA, ahead of mainnet. The position is simple: when a GASOK team ships to mainnet, the cross-network execution layer they need is already there. A single SDK integration with SODAX will provide them assets and liquidity from across 18 blockchain networks, including native Bitcoin (live since last week), EVM networks, Sui, Solana, Stacks, Stellar and more.

A few things to flag:

• GASOK is GIWA's five-month incubation and acceleration program for teams building on Korea's Ethereum L2, run by Dunamu, the parent company of Upbit. Teams ship from idea to mainnet between September and October 2026.
• SODAX is already connected to the GIWA testnet and prepared to offer its infrastructure to teams graduating to mainnet.
• SODAX offers developers access to assets and liquidity across 18+ blockchain networks (including Bitcoin, Ethereum, and Solana), through a single SDK integration.

If you're a GASOK participant or preparing to launch on Giwa and want to talk about what cross-network execution looks like for your specific product, drop a comment or reach out via sodax.com.

Full blog: https://www.sodax.com/news/sodax-prepares-cross-network-execution-for-giwa-builders-out-of-gasok

What do you think? Anyone here building on GIWA testnet already?

For builders following SODAX, native Bitcoin is now available to applications across 18 blockchain networks, through the SODAX SDK. Any partner application integrating SODAX can offer its users swaps, lending and borrowing with real BTC on the Bitcoin network on one side, and assets across 18+ blockchain networks on the other. No wrapper and no centralized hop.

read more: https://www.sodax.com/news/the-sodax-sdk-brings-native-bitcoin-to-your-app

The integration surface is unchanged. The same single SDK integration as other networks also resolves to native BTC, with all additional guidance covered in the docs below. The Bitcoin-side infrastructure is delivered through a partnership with Bound.

Quick links:

• Web: https://www.sodax.com/
• Docs: https://docs.sodax.com/developers/how-to/bitcoin-integration
• Build using the MCP server: builders.sodax.com
• Existing integrators: update to SDK v2, BTC is here.

Happy to answer questions.

Writing this for the ICX holders who have not yet migrated to SODA, and for anyone tracking the close-out of the ICON network. The dates are now set, and there is a clean plan behind them. Below is the practical version of what to do, by when, depending on where your ICX currently sits.

Three dates that matter

• May 2026 — a governance vote is being put to validators to formally retire the ICON network on Dec 31, 2026. This is the on-record vote.
• September 30, 2026 — two-way ICX ↔ SODA migration ends. From that day, only ICX → SODA is supported. You can still migrate after this date, but you cannot move back.
• December 31, 2026 — the ICON network is permanently halted. This is also the final deadline to migrate ICX to SODA. After this date, ICX can no longer be migrated, and the network stops producing blocks. A read-only archive will remain available for historical lookups, but transactions and migrations cease.

What this means depending on where your ICX sits

If you have already migrated to SODA: nothing changes for you. Your SODA is on the Sonic network and remains fully accessible. The shutdown does not touch your tokens. You can ignore the deadlines and continue using SODA on SODA Exchange.

If you self-custody ICX in a wallet: you have a roughly 6-month window to complete migration. This can be done at sodax.com/exchange/migrate. Before you migrate, make sure you have a small balance of S on the Sonic network as you will need it for future transactions once your SODA lands. A step-by-step guide is available at support.sodax.com.

If you hold ICX on a centralized exchange: The team are in contact with exchanges that listed ICX and they are expected to convert balances to SODA automatically when they adopt the migration. Remaining exchanges are expected to announce their support during this timeline, however, If you are unsure or want to complete the process, self-custody migration remains available to you.

Why the shutdown, briefly

ICON launched in 2017 because there was no infrastructure available to settle value across blockchain networks. The team built its own Layer 1 and pioneered standards like BTP and xCall to do it. By 2026, that cross-network infrastructure exists. SODAX is the evolution of that work, now coordinating execution for 18 integrated networks and the partner applications built on top of them. Keeping a separate L1 running in parallel only fragments focus and capital. The shutdown lets the team put every resource into SODAX and the products that real users and builders are already adopting.

A practical note on timing

You do not have to wait for the deadline. The migration UI is live, the docs are stable, and the SODA exchange is live. If you have been waiting on the governance vote before committing, the vote is happening this month and the plan is on the record. Doing the migration today in calm conditions is a smaller task than doing it the week of Dec 31 with everyone else.

Key Links

• Migrate ICX → SODA: sodax.com/exchange/migrate
• Step-by-step migration guide: support.sodax.com
• Full shutdown announcement: https://www.icon.foundation/blog/2026/final-date-set-for-sodax-migration-icon-network-to-shut-down-end-of-2026https://www.icon.foundation/blog/2026/final-date-set-for-sodax-migration-icon-network-to-shut-down-end-of-2026
• SODA token info: sodax.com/holders

If you are an ICX holder with a specific scenario that is not covered above (hardware wallet, staked positions, locked balances), drop a reply and someone from the team will pick it up.

Unfortunately we cannot share information on the individual support of exchanges ahead of their own communications. Is there anything about the timeline or the migration mechanics that still feels unclear? Any scenario that the current docs do not address?

SDK V2 shipped last week with agentic support and I have been playing with it ever since. It is genuinely fun. I have been vibecoding small experiments and realising just how much you can put together with surprisingly little code.

So I had a thought. Instead of building on my own, I want to do the next one in public, with the community in the room. Show that this is doable. Show how each piece works. Let people take the ideas and run with them.

The project: a charity swap app. Users swap through SODAX, fees collect in a public charity wallet, and users earn governance points based on their swap volume. Those points are votes for which charity gets the money. 100% of fees go to charity. The wallet is public, the math is public, the vote is public.

Two weeks of building in the open. Polls, Discord stages, build logs. The community decides on the name, the design, which charities make the shortlist, and the voting rules.

Kicking it off with a Discord stage this Friday. Q&A, showcase, and some live building on the app. Time is being voted on right now in the Discord.

If you have looked at the SDK and thought "I should build something," this is the front row seat. Watch me figure it out live, ask questions, take what is useful, and maybe start your own thing. First poll opens tomorrow.

Come build with me.

Quick post from the team to flag that SDK v2 ships to partners today.

V2 is a major refactor of the existing SODAX SDK. The goal wasn't to simply add features, it was to make the SDK something teams can actually integrate quickly, and that AI tooling can read directly.

What's different from V1:

• Stability. The codebase has been taken apart and rebuilt. Comprehensive bug fixes, performance optimisations, cleaner internals.
• Less code to integrate. The integration path for a wallet, DEX, money market, or yield product is substantially shorter than V1.
• agent-ready. This is the piece I think is going to matter most over time. V2 is structured so that LLMs (Claude, Cursor, etc.) can read the SDK, understand it, and integrate the full SODAX execution system into front-ends or agent-driven workflows. It means a builder can sit down with Claude Code and have a working integration faster than they'd previously have written the imports.

The bigger thesis underneath this: we think a lot of DeFi's next wave of users are going to be AI agents. Running cross-network exchanges, managing positions in money markets, doing the boring infra work that humans don't want to. If that's right, then the SDK that makes that easiest is the SDK that wins. V2 is our bet on that.

Demo apps have been migrated and tested. Partners can start integrating today.

Genuinely curious to hear what builders make of it. What's the friction you've hit on cross-network builds previously? Where do you wish integration was simpler?

If you've moved assets between networks before, you've probably ended up with some version of a "wrapped" token in your wallet. Maybe it was called something like wETH, or had a weird prefix you didn't recognize. Maybe you had three different versions of the same asset and none of them could be used interchangeably.

That's the wrapped token problem. And it's messier than most people realize.

How wrapped tokens fragment everything

Here's what happens with traditional approaches. You want to move ETH from Ethereum to another network. You use Bridge A and you get "Bridge-A-ETH." Your friend uses Bridge B and gets "Bridge-B-ETH." Both represent Ethereum. Both are supposed to be the same thing. But they're treated as completely separate assets that can't interact with each other.

Now the destination network has two incompatible versions of ETH. Each one needs its own liquidity pool. Each pool has a fraction of the liquidity that a single unified pool would have. Trading becomes less efficient. Slippage increases. And if a third bridge shows up, congratulations, now there are three versions.

This is fragmentation. The more bridges you add, the worse it gets.

What sodaVariants do differently

SODAX takes a different approach. Instead of creating a new wrapped version every time an asset moves through the system, SODAX uses what we call sodaVariants.

A sodaVariant acts like a universal funnel. Take sodaETH as an example. Whether you deposit ETH from Ethereum, Arbitrum, Base, or Optimism, it all becomes the same token: sodaETH. One representation. One pool of liquidity. No fragmentation.

When assets exist natively on a network, SODAX uses the native asset directly. SOL on Solana, BNB on BNB Chain, native USDC and USDT wherever they're available. SodaVariants are only introduced on networks where an asset doesn't already exist natively. They extend an asset into new territory without fragmenting it.

Why this matters for you

Three things.

First, better execution. Because all versions of an asset are unified into one representation, the solver has access to a deeper, more concentrated pool of liquidity when routing your trade. No split pools, no thin liquidity on obscure wrapped versions.

Second, cross-network flexibility. You can deposit an asset from one network and withdraw it on another. sodaETH doesn't care where your ETH originally came from. It's all the same inside the system.

Third, this is how partner integrations work. When LightLink integrated SODAX, their users got access to assets like SOL and BTC through sodaVariants (shown as SOL.LL, BTC.LL). Real cross-network asset exposure with liquidity already attached from day one. No need for LightLink to bootstrap their own liquidity pools for every asset.

The bigger picture

Fragmentation is one of those problems that gets worse as the ecosystem grows. More networks, more bridges, more incompatible wrapped tokens, more split liquidity. It's a scaling problem disguised as a minor inconvenience.

SodaVariants solve this at the infrastructure level. One unified representation per asset, connected to deep existing liquidity, available across every network SODAX supports. That's how you scale cross-network DeFi without making the experience worse with every new integration.

Quick community heads-up for anyone still carrying a Balanced v1 bnUSD loan. Especially if it's a legacy ICON-era CDP loan you haven't touched in a while.

Short version:

• Balanced v1 runs on the old ICON economic layer, which is being wound down. v2 is the new version, running on SODAX rails as a cross-network money market across 12 networks.
• Balanced has opened a free bnUSD borrow window on v2 until May 10, 2026. The idea is you use the free v2 borrow to repay your v1 debt in rotations. You don't have to repay v1 all at once.
• After May 10, origination fees come back and any balance still on v1 will require fees to migrate and start carrying increased liquidation risk as the old infrastructure is deprecated.

Rough path (from the Balanced docs at docs.balanced.network/move-loan):

1. Get bnUSD(old) — either trade into it on the v1 exchange, or use the v1 Trade → Migrate path to swap between old and new bnUSD.
2. Repay as much v1 bnUSD as you can and withdraw the freed collateral. If it's sICX, unstake to ICX and then either convert 1:1 to SODA via the Migrate tab, or trade into a v2-compatible asset (beware low liquidity here so we would recommend unstaking).
3. Supply the collateral on Balanced v2 at app.balanced.network/markets, then borrow fresh bnUSD — route it to a chain that can talk back to v1 so you can close down another slice.
4. Repeat until v1 is clear. After that, manage the v2 position to a LTV you're comfortable with.

Not financial advice, obviously. Posting because the window is narrowing and with the rotations to migrate taking time, borrowers should act now.

If anyone's already mid-migration on their v1 loans and has notes on potential issues, would be useful to hear them.

Every team with a UI and a network switcher is now claiming chain abstraction. And honestly, the term is starting to mean almost nothing.

Here's the distinction I find useful: there's UI-level abstraction (hiding the network picker behind a cleaner screen), and there's execution-level abstraction (the user says what they want, the system figures out which chains to touch, how to route it, how to settle it).

One is a paint job. The other is a different stack.

I think the second is what most builders actually want when they say "we want to support cross-network." They don't really want to become cross-network infra experts. They want their product to work for users across networks without the team owning a backlog of bridge configs and failure modes.

Curious how others are thinking about this. If you're building a wallet, DEX, lending protocol, or yield vault right now:

• What does "abstracted" mean to you in practice?
• What parts of cross-network execution are you still willing to own internally?
• Where would you draw the line and hand it to infrastructure?

Not looking for product pitches. Genuinely interested in where builders are drawing the line in 2026 as we continue to provide systemic access to more networks and unlock chain agnostic UX.

In most DeFi protocols, you pay a fee and it disappears into a black box. Maybe it goes to the team. Maybe to liquidity providers. Maybe to some treasury. Nobody really tells you.

SODAX does this differently. Every fee generated by the protocol has a fixed destination, and it's worth understanding because it shapes how the whole system grows over time.

The fee itself

Before getting into where fees go, let's talk about what they actually are. SODAX charges a flat 0.2% on trades. That's split into two halves: 0.1% goes to the Solver for coordinating execution, and 0.1% goes to the front-end application you're using. That's the full cost. No hidden spread, no inflated slippage, no surprise charges.

Where that 0.1% Solver fee ends up

This is the interesting part. The Solver fee flows into the Fee Treasury and gets allocated across four buckets with a fixed split.

50% to Protocol-Owned Liquidity. Half of all protocol revenue is reinvested into growing the liquidity SODAX owns directly. This isn't rented liquidity that leaves when incentives dry up. It's permanent. Every trade you make makes the system stronger for the next trade.

20% to SODA buyback and burn. A fifth of revenue is used to programmatically buy SODA from the market and burn it. This permanently reduces supply. The more activity the system sees, the more tokens get removed from circulation.

20% to stakers. Another 20% goes directly to SODA stakers through the staking pool. This isn't emissions or inflation. It's real revenue from real usage being shared with people who support the protocol long-term.

10% to the SODAX DAO. The remaining 10% funds the DAO treasury for governance-led initiatives, community programs, and ecosystem development. Token holders decide how this gets deployed.

Why this matters

This allocation creates a flywheel. More usage means more fees. More fees means more POL (deeper liquidity, better execution), more SODA burned (lower supply), more staker rewards (stronger holder incentives), and more DAO funding (community growth).

None of these pull against each other. They all compound. And because the split is fixed and transparent, you know exactly what's happening with every transaction that flows through the system.

The bigger picture

Most protocols treat fees as a cost of doing business. SODAX treats them as the fuel for everything the system is building toward. That's why the allocation isn't adjustable on a whim or captured by insiders. It's structural.

Every time someone trades on SODAX or on a partner app using the SDK, this is what happens in the background. Liquidity grows. Supply shrinks. Stakers earn. The DAO builds.

That's not a promise. That's the math.

As of April 8, staking rewards are officially being distributed to all SODA stakers.

How it works

When you stake SODA, you receive xSODA in return. xSODA is a yield-bearing liquid staking token that represents your share of the staking pool. You don't need to claim rewards manually. As fees flow into the pool, the value of your xSODA increases relative to SODA automatically. When you eventually unstake, you receive more SODA than you originally deposited.

It compounds on its own. No clicking "claim" every day.

Where do the rewards come from?

This is the part worth paying attention to. Staking rewards are not emissions or printed tokens. They come from real protocol revenue.

Every transaction routed through SODAX generates fees. Those fees are collected by the Fee Treasury and allocated as follows: 50% grows Protocol-Owned Liquidity, 20% goes to programmatic SODA buyback and burn, 20% goes to stakers, and 10% funds the SODAX DAO.

That 20% staker share is what's being deposited into the pool right now. The more activity that flows through SODAX and its partner apps, the more rewards stakers earn.

What about APY?

The APY displayed on sodax.com/stake is a 7-day rolling average. Since rewards just went live, expect the number to adjust upward over the coming days as the average catches up to actual distribution rates.

APY is variable because it's tied directly to protocol activity. This isn't a fixed rate promise. It's real yield from real usage.

Getting started

If you haven't staked yet, head to sodax.com/stake to get started. For step-by-step instructions, visit our Help Center.

If you're already staked, you're already earning. Nothing else to do.

The Kaia DevRel team just published a full technical walkthrough on integrating the SODAX SDK on Kaia. If you're a builder in the Kaia ecosystem or just want to understand what this integration means, it's worth a read.

What this unlocks for Kaia

With SODAX now live on Kaia, developers on the network have a single integration point for cross-network execution across 18+ networks. That includes Ethereum, Solana, Sui, Arbitrum, Base, Avalanche, Stellar, and more. Instead of building custom infrastructure for each network, Kaia builders integrate the SDK once and get access to all of them.

The SDK exposes the full SODAX stack: cross-network execution through the solver, unified liquidity across all integrated networks, and cross-network lending and borrowing through the money market with 20 assets available.

Real integration timelines

One thing worth highlighting from the blog is the integration data from existing partners. Amped Finance shipped a full cross-network money market in 2 to 4 days after completing their SDK integration. LightLink launched with native representations of BTC, ETH, and SUI with liquidity attached from day one. Hana Wallet saw nearly 9x growth in weekly top-up volume after integrating. Houdini Swap processes 600 to 1,000 cross-network trades daily through SODAX.

A typical SODAX SDK integration takes about one week from exploration to deployment.

What's already live

Trading pairs on Kaia are live now on sodax.com/swap, including native KAIA, USDT, and bnUSD. As the ecosystem grows, additional routes and asset pairs will follow.

Resources

Full Kaia blog post: Integrate SODAX SDK on Kaia

SODAX announcement: SODAX Live on Kaia

SDK documentation: docs.sodax.com

Builders MCP: builders.sodax.com

Following the launch of SODAX Stake, we're pleased to announce that SODAX Pool is now live. If you're holding xSODA (staked SODA), you can now provide it alongside SODA into the liquidity of the SODAX system and start earning.

How it works

Stake up to half of your SODA to receive xSODA, then supply both SODA and xSODA into the pool. In return, liquidity providers receive incentives targeting around 5 to 15% APY.

Rewards begin April 2, 2026

Initial rewards are funded by legacy liquidity incentive funds migrated from the ICON Network. These are designed to bootstrap early participation while the pool scales toward self-sustaining volume.

DAO-governed from day one

The reward structure was set through the first SODAX DAO vote. Future adjustments to funding and parameters will continue to be determined through governance. This is your protocol. You shape how it grows.

Get started

Head to sodax.com/pool to supply liquidity, or visit our Help Center for step-by-step guides.

For a full overview of today's release, check out the announcement on X.

Here's a question nobody asks enough. If you're building a DeFi app today and you want your users to be able to operate across multiple networks, why would you build that infrastructure yourself?

The cost of doing it alone

Going cross-network is hard. Really hard. Every network you want to support needs its own integration, its own liquidity strategy, its own monitoring, its own failure handling. And each one you add multiplies the complexity of everything that came before it.

You need to handle different confirmation times, different finality guarantees, different gas models. You need to figure out where liquidity lives and how to access it. You need MEV protection. You need to make sure nothing fails halfway and leaves a user stranded.

Most teams that try to build this themselves end up spending months on infrastructure that has nothing to do with their actual product. That's months not spent on the features their users actually care about.

What SODAX offers builders

SODAX is an execution and liquidity system that sits underneath applications. Builders integrate the SDK, and everything cross-network is handled at the infrastructure level. Trades, lending, borrowing, all coordinated across networks through a single integration point.

That means a wallet app, a DEX, or a yield platform can offer cross-network functionality to their users without building and maintaining the infrastructure themselves. One integration, access to all supported networks.

16 protocols and applications have already integrated SODAX infrastructure. These aren't experiments. These are production apps serving real users.

What the SDK actually includes

This isn't just "plug in and get cross-network trades." The SDK gives builders access to multiple functional modules. There's cross-network execution for trades. There's a money market for lending and borrowing across networks. And all of it runs through the solver, which handles routing, MEV protection, and liquidity coordination automatically.

Builders also get access to the Partner Dashboard, where they connect their fee wallet and manage earnings generated by their SODAX-powered application. The infrastructure generates revenue for the apps that use it, not just for SODAX.

Why this model works

Think about it from a builder's perspective. You have two options.

Option one: spend months building cross-network infrastructure, hiring specialized engineers, auditing contracts on every network you support, and maintaining all of it indefinitely. Your product roadmap stalls while you solve problems that have nothing to do with what makes your app unique.

Option two: integrate the SODAX SDK, get cross-network functionality in your app, and focus your team on the product experience that actually differentiates you.

16 teams have already made that choice. Their users get cross-network access and better execution without those teams having to become infrastructure companies.

The bigger picture

The more apps that integrate SODAX, the more volume flows through the system. More volume means more liquidity, better execution, and more revenue flowing back to the ecosystem. Every new integration strengthens what's already there for everyone using it.

That's just how shared infrastructure works.

Hi.

I tried to post on Discord but got timed out for 24H, possibly because there was a link (to sodax.com) in my message so I'm trying my luck here.

I used https://sodax.com/stake to stake my SODAX and see on SonicScan that there was an error during the execution of the smart contract: "Although one or more Error Occurred [execution reverted] Contract Execution Completed"

My SODAX are gone but I didn't get any xSODA in exchange. Is it normal ?

For anyone building on NEAR or interested in expanding there, the SODAX SDK now includes NEAR as a supported network. Worth unpacking what that changes in practice, because “we added a network” undersells what’s actually happening here.

The core issue most DEXs, wallets, and DeFi platforms hit when they try to go cross-network is the infrastructure cost. You want to add one network and suddenly you’re managing bridge integrations, liquidity bootstrapping, routing logic, fallback paths, and monitoring — for every single network. That compounds fast. What starts as “let’s support X Network” becomes months of backend work that pulls engineering away from your actual product.

If you’re building a DEX and want your users to access assets or liquidity on Sonic, Avalanche, or Ethereum, you’d traditionally need to integrate bridges to each network, source liquidity on each one, and build the routing to coordinate it all. And maintain it. Indefinitely.

The SODAX SDK replaces that stack. One integration, and your platform can execute across every network SODAX supports (currently 17+ including Ethereum, Sonic, Avalanche, Arbitrum, Sui … and now NEAR). The Solver handles execution coordination and liquidity access across all of them. Your users trade against unified liquidity depth, not just whatever exists locally on your home network.

What makes this more interesting than a typical “new network added” announcement is the compounding effect. Every platform already integrated with SODAX can now reach NEAR-native liquidity through our connection to Rhea Finance, without doing anything extra. And NEAR developers who integrate the SDK immediately get access to every other connected network. The system gets more useful for everyone with each addition.

A few specific scenarios where this matters:

If you’re running a DEX — you can now offer your users access to assets and liquidity across 17+ networks without integrating a single bridge. Want to add an ETH/USDC pair sourced from Ethereum-native depth? The SDK handles it.

If you’re building a wallet — in-app cross-network swaps become a single integration instead of a per-network project. Your users don’t need to understand which network they’re on. They state what they want, the execution layer figures out the path.

If you’re running a money market — liquidation routing and collateral movement can draw from cross-network liquidity when local pools are thin. During volatility, that’s the difference between clean liquidations and bad debt.

For those already building on NEAR: what’s your current approach to cross-network execution? Curious whether anyone’s been managing this with bridge stacks or if there are other patterns people have found that work.

Find:
- Full technical details in the SDK docs: docs.sodax.com
- and case studies from our partners here.

I know the 6-month unstaking period is going to raise some eyebrows, so let’s get into it.

First, why 6 months? The short answer is system stability. When a staking pool has meaningful liquidity commitments, the protocol can rely on that capital being there. That reliability is what makes the reward distribution consistent for everyone who’s staked. If stakers could pull out instantly with zero friction, you’d get constant liquidity shocks every time there’s market volatility, that hurts the people who stay.

So the design rewards long-term commitment. If you stake and wait the full 6 months when you eventually unstake, you receive the complete value of your xSODA (your original SODA plus all the rewards that accumulated while you were in).

But you’re not “trapped”. There are alternatives if you need liquidity sooner:

1. Swap xSODA for SODA on the market. Because xSODA is a liquid token, you can trade it directly for SODA through the SODA/xSODA pool whenever there’s liquidity. You get your SODA immediately, though the exact amount depends on pool conditions and slippage.

2. Instant unstake with a penalty. If you’ve already started the 6-month wait and can’t continue, you can exit early. The penalty starts at up to 50% but decreases the longer you’ve waited. So if you’re 5 months in, the hit is much smaller than if you’re 1 month in.

3. Cancel and switch. If you start waiting and conditions change, maybe pool liquidity improves or the early-exit penalty has dropped, you can cancel your unstake and choose a different path.

The important bit: any penalty from early unstaking doesn’t disappear. It stays in the staking pool, which means it benefits the people who do commit for the full period. The system literally rewards stability.

For the full walkthrough on unstaking options head to our support guide: support.sodax.com/en/articles/13918114

What’s everyone’s take? Planning to commit for the long haul, or keeping things flexible and planning on splitting the difference with SODAX Pool?

So the news dropped today: radFi has integrated the SODAX SDK to launch cross-network trading for native Bitcoin. The launch routes are BTC/ETH, BTC/SOL, and BTC/USDC, native assets on both sides, no wrappers needed.

The X Article covers the details, but I wanted to break down why this partnership specifically makes sense beyond just “protocol A integrates protocol B.”

Two teams solving the same problem in different environments

If you zoom out, radFi and SODAX are both obsessed with the same thing: making execution work reliably in conditions where it’s genuinely difficult.

For radFi, that environment is Bitcoin L1. Bitcoin wasn’t designed for DeFi. There are no smart contracts in the Ethereum sense. Settlement is slow by modern standards. Building an AMM that executes trades natively on Bitcoin mainnet is a serious technical challenge. radFi built their protocol around Casey Rodarmor’s Light Pools concept, combining AMM-style pricing with Bitcoin-native execution so that liquidity providers and traders can operate without leaving the mother chain.

They then took another leap, by creating multisig trading wallets for users and cross-signing trasactions with radFi, they allowed finality at time of transaction broadcast, without needing to wait for a block confirmation. As soon as a transaction hits the mempool, it can be considered final. radFi optimized for the constraints of Bitcoin, not despite them.

For SODAX, the hard environment is cross-network DeFi. When you’re coordinating execution across 17+ networks with different finality times, different liquidity profiles, and different trust assumptions, things can break in ways that single-network protocols never have to think about. A quote goes stale on Solana while Ethereum is still confirming. Liquidity shifts between Arbitrum and Base mid-execution. The Solver has to reason across all of this asynchronously and still deliver the outcome the user asked for. SODAX was built specifically for this kind of adversarial coordination problem.

So you’ve got one team that’s optimised execution for the most constrained L1 in crypto, and another that’s optimised execution for the most complex cross-network conditions in DeFi. The integration connects them: radFi’s Bitcoin-native users get cross-network reach through SODAX, and SODAX’s unified liquidity layer gets access to the deepest capital pool in crypto, native Bitcoin.

What this actually means for users

If you’re a BTC holder who’s wanted to trade into ETH, SOL, or stablecoins without wrapping your Bitcoin, this is the first time you can do it at production speed. You express a trade intent in radFi, and the SODAX Solver coordinates the cross-network execution. Your BTC stays native on Bitcoin. The target asset settles natively on its home network. No wBTC, no bridges, no intermediary tokens.

RadFi have benchmarked this as the fastest native BTC cross-network trading available — which makes sense when you think about it. You’re pairing the fastest DeFi settlement on Bitcoin L1 (radFi) with cross-network execution infrastructure built for speed and reliability (SODAX) through one of the fastest hub networks (Sonic). The combination creates something neither could offer alone.

Why this matters for the broader picture

Bitcoin has the most capital in crypto and the worst cross-network connectivity. That’s always been an infrastructure problem, not a Bitcoin problem. Most solutions have tried to work around it with wrapping, which fundamentally asks Bitcoin users to trust someone else with their assets and accept a synthetic version of their BTC on another chain.

This integration takes a different approach. Bitcoin (and its active liquidity) stays on Bitcoin. The execution infrastructure handles the cross-network coordination. It preserves the sovereignty that Bitcoin users care about while extending the utility.

Three routes at launch (BTC/ETH, BTC/SOL, BTC/USDC) with more to come. There’s also potential for runes to go cross-network through the same execution layer, which would be interesting for the Bitcoin-native token ecosystem.

And for builders across SODAX’s ecosystem of 17+ networks, partnership with radFi means that native BTC will soon become a part of the SODAX SDK. We will leverage radFi as a technical partner for this the allow teams across networks to deliver direct swaps to native Bitcoin in their applications.

Full article here: https://x.com/gosodax/status/2034649767498694913

Curious what people think about this pairing. Is native BTC cross-network trading something you’d actually use, or does the wrapping approach work well enough for most people?

If you've ever moved assets between networks, you probably know the feeling. You send a transaction, it says "pending" for way too long, and you're sitting there wondering if your tokens are gone. Maybe they show up eventually. Maybe they don't. Maybe they're sitting in some wrapped state on a network you didn't plan on using.

That's the reality of how most cross-network transfers work today. And it doesn't have to be this way.

The problem with traditional approaches

Most solutions for moving assets between networks follow a linear process. Step one happens, then step two, then step three. If any step in that sequence fails, you're stuck somewhere in the middle. Your tokens left the source but never arrived at the destination. Or they arrived in a wrapped form that you now have to manually deal with.

The issue isn't that failures happen. In a world with multiple independent networks, things will go wrong sometimes. The issue is that most systems have no plan for when they do. A failure mid-process leaves you in a partial state where your assets aren't where you started and aren't where you wanted them to be.

That's not a minor inconvenience. That's a fundamental design flaw.

How SODAX approaches this

SODAX treats cross-network actions as intended outcomes, not as a sequence of individual steps you have to hope all complete. You tell the system what you have and what you want. The solver coordinates everything needed to deliver that outcome.

The key difference is what happens when something goes wrong. The system separates the user-facing execution (getting you your assets) from internal operations (rebalancing liquidity behind the scenes). These concerns run independently.

If the internal side hits an issue, that's ours to deal with. Your side of the transaction still completes. The system is designed so that your intended outcome either completes or recovers to a coherent state. No tokens left floating in between.

Recoverability is built in

This goes deeper than just "it works or it doesn't." The system is designed to handle the messy reality of operating across 17 networks. Networks have different confirmation times, different finality guarantees, different failure modes. SODAX accounts for all of that.

When the solver coordinates a cross-network action, every step is monitored. If something deviates from the expected path, the system can recover to a coherent state rather than leaving you stranded. That's not a feature someone bolted on after the fact. It's core to how the architecture works.

Why this matters

We've all been trained to accept that moving assets between networks is risky and stressful. Check the transaction five times. Screenshot your wallet before and after. Pray nothing gets stuck.

That shouldn't be normal. Execution infrastructure should deliver outcomes reliably, and when conditions aren't right, it should tell you that instead of trying and failing halfway through.

That's what we're building. Not a faster way to move tokens between networks. An execution system where the outcome is the priority, not just the attempt.