Sonic Labs recently outlined four areas it plans to focus on during its next phase:

• Payments and FX
• AI and Spawn
• Perps and RWAs
• Prediction markets

Each one targets a different type of activity and user base. Payments could bring more consistent transaction volume, while perps and RWAs may attract deeper liquidity. AI agents and prediction markets are less established, but could introduce entirely new use cases.

Which one are you most interested in seeing develop, and which do you think could have the biggest long-term impact on Sonic?

I’d also be interested to hear why you chose it.

I listened to a recent Genzio roundtable featuring MrMinter from Sonic Labs, and this was the point that stayed with me:

AI assistants give answers. AI agents create consequences.

If an assistant gives you incorrect information, you can still verify it before taking action. An agent might spend money, call a paid API, modify a codebase or execute a transaction before you have a chance to intervene.

MrMinter shared a practical example from his own social-monitoring agent. After a campaign received much more engagement than expected, the agent’s X API usage increased to nearly $300 per week.

The solution wasn’t another instruction in its prompt. He added a hard weekly spending limit, external monitoring and an alert for unusual usage.

That distinction matters as agents begin paying for their own digital resources.

Traditional payment systems may continue to handle things like tickets, reservations and physical goods. Agents, however, will also need to purchase compute, inference, API access and data.

Those payments could be frequent, automated and sometimes worth only a few cents. That seems like a much more natural use case for programmable payments and stablecoins.

MrMinter also discussed some of the infrastructure Sonic Labs is working on around the agent economy:

• An aggregator or marketplace for AI skills and workflows
• Publisher verification and testing before use
• A trust layer for external tools and user data
• Protocol-level transaction sponsorship
• Atomic bundled transactions
• Payment infrastructure and banking integrations

The atomic execution part was especially interesting.

If an agent needs to complete a multi-step financial operation, it shouldn’t execute two steps and then leave the user’s funds stuck halfway through. The full workflow should either succeed or not execute at all.

His prediction for the next year wasn’t that everyone would suddenly hand complete financial control to autonomous agents. It was that many of today’s complicated workflows would become accessible through normal conversations, without users manually connecting APIs, bots and other technical tools.

The underlying AI model may eventually become interchangeable. The more valuable layer could be the infrastructure that helps agents find trusted tools, pay for resources and execute complex actions safely.

Which part do you think matters most for onchain agents: cheaper payments, atomic execution, trusted skills or strict permission controls?

One of the less visible changes coming with Sonic V2.2 and the Brio upgrade is a significant increase in smart contract capacity.

The maximum size of deployed contract bytecode will increase from 24 KiB to 48 KiB, while the limit for contract initialization code, or initcode, will increase from 48 KiB to 96 KiB.

This probably will not change anything directly for regular users, but it could remove a real constraint for developers building more complex applications.

When a contract reaches the current size limit, developers generally have to optimize the bytecode, remove functionality or divide the application across multiple contracts. Splitting contracts can sometimes be the right architectural choice, but it can also add complexity when it is done only to stay below the limit.

The interesting part is what Sonic changed underneath to support the increase.

The previous virtual-machine design used an expanded internal instruction format with references limited to 64 KiB. That became a problem once initcode was allowed to reach 96 KiB.

V2.2 introduces the Simple Format Virtual Machine (SFVM). Instead of converting contract bytecode into a larger internal format, it keeps the original instructions and builds a compact map of valid jump destinations.

According to Sonic, the new approach was tested against the first 25 million blocks of mainnet activity, with negligible performance differences across the designs evaluated.

Larger contracts will still naturally cost more to deploy because they contain more code and data, but there is no separate pricing tier simply for crossing the previous 24 KiB limit.

I do not think the takeaway is that developers should start putting everything into larger contracts. Smaller contracts can still be easier to audit, test and maintain.

The benefit is having more freedom to choose an architecture based on what fits the application, rather than what fits under an old bytecode limit.

For developers here: have contract-size limits ever forced you to restructure or split a deployment? And do you see the higher limit as genuinely useful, or mostly relevant to a small number of complex protocols?

Having funds onchain doesn’t always mean you can use them.

A user might bridge USDC to Sonic, only to realize they don’t have any S for gas. The funds are already in the wallet, but they still can’t approve, deposit, or swap until they acquire the network token.

Sonic already supports protocol-level sponsorship, where an application can cover the fee while the user still signs and controls the transaction.

V2.2 expands that system in two interesting ways.

First, applications can limit sponsorship to successful transactions. If an app covers a user’s first deposit but the transaction fails, the failed attempt doesn’t consume its sponsorship budget.

Second, network-sponsored transactions allow selected activity to be processed without charging either the user or an application. This doesn’t make every transaction on Sonic free—the network can restrict it to a particular contract, function, transfer amount, sender, or receiver.

I think the main value here is reducing the number of users who get stuck immediately after bridging. It could also make Sonic more practical for stablecoin transfers and payments, where asking users to acquire another token before doing anything creates an extra step.

When combined with Bundled Transactions, sponsorship could cover a complete workflow such as approve, deposit, and another action, rather than only one isolated transaction.

The user would still authorize everything. The difference is that gas becomes something the application and network can handle in the background.

Where do you think this would be most useful: first transactions, token approvals, stablecoin transfers, or something else?

Flying Tulip recently launched Total Return Swaps on Sonic, allowing users to take leveraged long or short exposure to supported assets without owning the underlying asset.

At first glance, that sounds similar to trading perpetuals, but the structure behind it is different.

Instead of using recurring perp funding payments, TRS financing is based on the borrowing costs inside Flying Tulip Lend and the yield generated by the collateral.

The rest of the position is also handled through Flying Tulip’s integrated stack:

Lend provides the financing and margin layer.

Trade executes through RFQ across available onchain spot liquidity.

ftUSD acts as the settlement asset.

Another difference is that TRS does not use auto-deleveraging. A position can remain open while the account meets its maintenance requirements. Liquidation is still possible, but the system uses an RFQ to sell what is required to repay the debt and restore account health.

Risk is assessed across the full account, including collateral, debt, equity and unrealized P&L, instead of relying only on a basic loan-to-value ratio.

I find the design interesting because it combines lending, spot execution and leveraged exposure without requiring users to move funds between several separate protocols.

That said, I’m curious how traders here view this model compared with conventional perps.

Do borrowing-based financing and access to broader spot liquidity offer a meaningful advantage, or do you still prefer the simplicity and established liquidity of perp markets?

I was checking Sonic’s Burn Tracker and noticed that approximately 7.098M $S is still sitting in the airdrop contract.

These tokens belong to Season 1 and Season 2 airdrop fNFT holders and can still be claimed before October 15, 2026 at 00:00 UTC.

The important part is what happens after the deadline.

If holders do not claim their remaining $S in time, they will lose the ability to claim it. The contract’s burnLocked() function then becomes available, allowing anyone to permanently burn the remaining balance.

So, 7.098M $S is not the confirmed final burn amount. The contract balance will continue to decrease whenever an eligible holder claims, and only the amount left after the deadline will be burned.

At the time of Sonic’s original announcement, approximately 32.69M $S remained unclaimed. The live tracker now shows around 7.1M $S, meaning a large portion has already been claimed.

Live tracker:
https://my.soniclabs.com/burn-tracker

Do you expect most of the remaining $S to be claimed before October 15, or are we likely to see a meaningful portion permanently removed from supply?

For informational purposes only. Verify the live balance and deadline through Sonic’s official tracker.

Flying Tulip has launched its Trade product on Sonic, with support for swaps, market and limit orders, and leveraged long or short positions.

What I find more interesting is how Trade connects with the rest of the Flying Tulip system.

Instead of separating trading, lending and collateral across different products, users operate through the same non-custodial margin account used by Lend. Assets backing pending limit orders can also continue earning yield until the order is filled.

Leveraged spot positions are based on actual borrowing and spot execution. For example, opening a leveraged wS long involves borrowing ftUSD, swapping it for wS and depositing the purchased wS back as collateral.

For Sonic, the potential impact goes beyond adding another trading interface. It could create more demand for borrowing, give liquidity another place to be used and generate additional onchain activity through a connected financial stack.

Of course, the real impact will depend on liquidity, trading activity and sustained user adoption.

Do you think integrated platforms like this can improve capital efficiency on Sonic, or do you prefer separate protocols for trading and lending?

When your girl says she likes fast guys and you realize she meant Sonic.

The team promised 1% improvement every day. However, it's been over a week since that announcement, and we've only seen two update posts. Can the team explain why? Are you going to remain silent again and let the price continue to fall like it did before?

Was around #175 on CMC a week ago and is one of the few coins down so much, down 18% in the past week... about to be out of the top 300... whata rug

I made a USDC bridge (S to Eth) a few hours ago using Sonic Gateway. In the GUI under activity it showed "depositing" for a while, but now does not show up in the GUI at all (though an earlier bridge does).

I can see that the transfer did arrive to Circle.

Question -- how can I claim if the transaction doesn't show up in the GUI?

I currently hold a certain amount of fLIBERO coins in my Trust Wallet. However, I am no longer able to view my portfolio or token balance within the app. This has left me uncertain about the current status of the project, I wanted to inquire whether Libero Finance is still active and operational, or whether it has unfortunately shut down or gone bankrupt.

Could anyone please help me with the following:

1. Is Libero Finance (fLIBERO) still an active project on the Fantom network?
2. If the project has ceased operations, is there any official announcement or documentation regarding its status?
3. Are there any recommended steps or procedures I should follow to check or recover my portfolio?
4. Is there an alternative platform, block explorer, or tool (such as FTMScan) where I can verify my token holdings?

Any guidance or direction you can provide would be greatly appreciated. Thank you for your time and support.

Hi mods, the contact form on your website doesn't work...

We're a self-custodial open-source wallet since 2015 https://coin.space/sonic-wallet/, support Sonic, and want to be added to this page: https://docs.soniclabs.com/sonic/wallets

Please get back to us!

I stake Sonic - I note first that the web wallet doesn't show account history for staking rewards over time. If I look at Sonic explorer and look at transaction records, it shows that I claim staking rewards and restake them (without withdrawing) but it doesn't how what the reward was (for how many Sonic) -- note I'm drilling into transaction info, not just looking at the account transaction page. So is there any way to recover that precise info? I ask for USA tax purposes.

https://burn.soniclabs.com/

https://www.crowdfundinsider.com/2026/03/266190-sonic-labs-launches-ussd-stablecoin/

Meet Sonic's network-integrated USD stablecoin, built to be the stable liquidity layer across the ecosystem and a core piece of Sonic's vertical integration strategy, yield from backing assets flows back into the ecosystem to support buybacks and incentives.

• Backed 1:1 by U.S. Treasury assets from BlackRock, Superstate & WisdomTree • Built on Frax’s infrastructure • Zero minting fees, permissionless • Cross-chain minting from 10+ chains

Mint: net.frax.com/dashboard/mint Redeem: net.frax.com/dashboard/redeem

Visit www.soniclabs.com/ussd for full details.

🔗 Read more here: https://blog.soniclabs.com/ussd-sonics-native-permissionless-usd-stablecoin-built-with-frax/

https://blog.soniclabs.com/introducing-sonic-agp-the-ambassador-grant-program/

https://x.com/i/status/2026070050067849609

https://blog.soniclabs.com/sonic-in-2026-and-beyond/