reply Supporting these limits required a change to Sonic’s execution engine.
V2.2 introduces the Simple Format Virtual Machine (SFVM), which keeps original contract instructions and uses a compact map of valid jump destinations, removing the previous size restriction.
0·-Neutral
n
news9/5news
Supporting these limits required a change to Sonic’s execution engine.
V2.2 introduces the Simple Format Virtual Machine (SFVM), which keeps original contract instructions and uses a compact map of valid jump destinations, removing the previous size restriction.
55·BLong
n
news9/4news
Doubling The Limit
How Sonic is expanding smart contract size limits with V2.2.
A developer is building an application on Sonic. As the product grows, its smart contracts need to support more features, more complex logic and more ways for users to interact. Eventually, the developer reaches the maximum contract size. They must then remove functionality, spend time reducing the code or divide the application across multiple contracts. Sonic V2.2 gives developers more room. The upgrade doubles the maximum size of smart contracts and the code used to deploy them. Why Contract Size Matters Smart contracts are programs deployed onchain. Like any program, they contain code that defines what an application can do. Ethereum introduced limits on the size of this code to protect the network from excessive processing and hardware requirements. Sonic has followed the same limits, allowing deployed contracts of up to 24 KiB and contract initialization code of up to 48 KiB. These limits are sufficient for many applications, but they can become restrictive as contracts grow more sophisticated. Developers can work around the limit by separating an application into multiple contracts. In some cases, this is the right architectural choice. In others, it introduces additional complexity purely to stay under the limit: restructuring working code, coordinating interactions across more contracts or removing features they would otherwise include. What Changes V2.2 doubles both limits: Deployed contract code increases from 24 KiB to 48 KiB Contract initialization code increases from 48 KiB to 96 KiB Initialization code is the temporary code used when creating and deploying a contract, including the instructions needed to configure it before its final code is stored onchain. The higher limits do not introduce additional fee penalties beyond Sonic's existing charges for code and data size. Larger contracts naturally require more data to be processed and stored, so existing costs continue to scale with size. There is no new pricing tier for contracts that exceed the previous 24 KiB limit. Developers gain more capacity without having to account for a new fee system. What Made This Possible Supporting larger contracts required more than changing a configuration value. Sonic's previous virtual machine used an instruction format that relied on references limited to 64 KiB of code. That was not a problem under the old limits, but with initialization code increasing to 96 KiB, the virtual machine needed a new approach. V2.2 introduces the Simple Format Virtual Machine (SFVM). Instead of converting contract code into a longer internal format before execution, SFVM keeps the original instructions and creates a compact map of valid jump destinations. The result is a simpler execution engine that removes the previous size restriction. SFVM was tested against the first 25 million blocks of Sonic mainnet activity. Across the designs evaluated, performance differences were negligible. Sonic was able to adopt the simpler architecture without a meaningful tradeoff for normal network activity. What Changes For Developers Applications can include more contract logic without being forced to split it across multiple deployments. Complex protocols have more room for features, and development teams can spend less time restructuring code solely to fit within the previous limits. This does not mean every application should use larger contracts. Smaller and simpler contracts can still be easier to review, test and maintain. The change gives developers more freedom to choose the structure that best fits their application. What Changes For Users Nothing noticeable. Users will continue to sign transactions, interact with applications and pay network fees in the same way. Existing contracts do not need to be rewritten. The difference is in what developers can build. Applications that previously required workarounds to fit under the contract size limit can now be deployed as intended, with richer functionality and simpler architecture. A Larger Foundation Increasing contract limits is not about making every smart contract larger. It is about removing a constraint when additional capacity is genuinely useful. With V2.2, Sonic doubles the room available for deployed contracts and initialization code, backed by a simpler execution engine designed for the next stage of the network's growth.
65·B+Long
n
news9/4news
Doubling The Limit
How Sonic is expanding smart contract size limits with V2.2.
A developer is building an application on Sonic. As the product grows, its smart contracts need to support more features, more complex logic and more ways for users to interact.
Eventually, the developer reaches the maximum contract size. They must then remove functionality, spend time reducing the code or divide the application across multiple contracts.
Sonic V2.2 gives developers more room. The upgrade doubles the maximum size of smart contracts and the code used to deploy them.
Why Contract Size Matters
Smart contracts are programs deployed onchain. Like any program, they contain code that defines what an application can do.
Ethereum introduced limits on the size of this code to protect the network from excessive processing and hardware requirements. Sonic has followed the same limits, allowing deployed contracts of up to 24 KiB and contract initialization code of up to 48 KiB.
These limits are sufficient for many applications, but they can become restrictive as contracts grow more sophisticated. Developers can work around the limit by separating an application into multiple contracts. In some cases, this is the right architectural choice. In others, it introduces additional complexity purely to stay under the limit: restructuring working code, coordinating interactions across more contracts or removing features they would otherwise include.
What Changes
V2.2 doubles both limits:
Deployed contract code increases from 24 KiB to 48 KiB
Contract initialization code increases from 48 KiB to 96 KiB
Initialization code is the temporary code used when creating and deploying a contract, including the instructions needed to configure it before its final code is stored onchain.
The higher limits do not introduce additional fee penalties beyond Sonic's existing charges for code and data size. Larger contracts naturally require more data to be processed and stored, so existing costs continue to scale with size. There is no new pricing tier for contracts that exceed the previous 24 KiB limit.
Developers gain more capacity without having to account for a new fee system.
What Made This Possible
Supporting larger contracts required more than changing a configuration value.
Sonic's previous virtual machine used an instruction format that relied on references limited to 64 KiB of code. That was not a problem under the old limits, but with initialization code increasing to 96 KiB, the virtual machine needed a new approach.
V2.2 introduces the Simple Format Virtual Machine (SFVM). Instead of converting contract code into a longer internal format before execution, SFVM keeps the original instructions and creates a compact map of valid jump destinations. The result is a simpler execution engine that removes the previous size restriction.
SFVM was tested against the first 25 million blocks of Sonic mainnet activity. Across the designs evaluated, performance differences were negligible. Sonic was able to adopt the simpler architecture without a meaningful tradeoff for normal network activity.
What Changes For Developers
Applications can include more contract logic without being forced to split it across multiple deployments. Complex protocols have more room for features, and development teams can spend less time restructuring code solely to fit within the previous limits.
This does not mean every application should use larger contracts. Smaller and simpler contracts can still be easier to review, test and maintain. The change gives developers more freedom to choose the structure that best fits their application.
What Changes For Users
Nothing noticeable. Users will continue to sign transactions, interact with applications and pay network fees in the same way. Existing contracts do not need to be rewritten.
The difference is in what developers can build. Applications that previously required workarounds to fit under the contract size limit can now be deployed as intended, with richer functionality and simpler architecture.
A Larger Foundation
Increasing contract limits is not about making every smart contract larger. It is about removing a constraint when additional capacity is genuinely useful.
With V2.2, Sonic doubles the room available for deployed contracts and initialization code, backed by a simpler execution engine designed for the next stage of the network's growth.
65·B+Long
n
news9/3news
Sponsored By Design
How Sonic is expanding transaction sponsorship with V2.2. A user bridges assets to Sonic. They have USDC, ETH, or another asset they want to use, but no S to pay the network fee. Despite already having funds onchain, their first interaction can stop before it starts. Sonic introduced protocol-level transaction sponsorship with v2.1.2, allowing applications to cover network fees for their users. V2.2 takes that model further. Network-sponsored transactions can remove the fee entirely for qualifying activity, while successful-only sponsorship gives applications more control over when their sponsorship budget is spent. The result is a broader model for transaction execution: the user can pay, an application can pay, or for selected transactions, nobody has to pay at all. Sponsorship At The Protocol Level Sponsored Transactions on Sonic do not rely on an offchain relayer forwarding transactions for users. Sonic's transaction processing recognises sponsorship requests directly, while an onchain Subsidies Registry holds deposited S and defines which transactions those funds can cover. A transaction requests sponsorship by setting its gas price, or fee cap for newer transaction types, to zero. The node checks the Subsidies Registry and, if an eligible fund has sufficient balance, accepts the transaction for sponsored execution. The user still signs through the normal wallet flow. Sponsorship therefore changes who pays for execution, not who authorises the action. Apps Choose What They Pay For Sonic allows sponsors to define which activity they are willing to cover rather than paying for every transaction a user makes. Sponsorship can apply to transactions from a particular account, interactions with a particular contract, or calls to a specific contract function. Sponsors can narrow this further to a particular account calling a particular function. There are also dedicated mechanisms for ERC-20 approvals and bootstrap sponsorship, which can cover the first few transactions from a new account. A DEX could cover the approval required before a swap without paying for unrelated wallet activity. A lending market could cover interactions with its contracts, while another application could sponsor a new user's first few actions. Before execution, Sonic checks that sponsorship is still available. If it is, the user's transaction executes and an internal transaction charges the selected sponsorship fund for the gas consumed. This means the network fee still exists. It simply comes from the sponsor's deposit rather than the user's wallet. What If The Fund Runs Out? Sponsorship coverage can change while a transaction waits in the pool. A transaction might qualify when submitted but lose its backing if other transactions consume the available balance first. Sonic rechecks pending sponsored transactions and can remove those that are no longer covered. Sponsored transactions also carry an effective tip of zero, giving them the lowest transaction-pool priority. Under high network load, transactions offering a positive tip are prioritised ahead of them. These constraints are part of the trade-off. Sponsorship removes a payment requirement from the user, but the network still has to account for the execution and ensure someone is covering its cost. When Nobody Pays V2.2 extends the existing system with network-sponsored transactions. With a regular transaction, the user pays. With a sponsored transaction, an application or another sponsor pays from deposited S. With a network-sponsored transaction, a qualifying transaction can be processed without a token payment at all. No S is consumed, burned or rewarded to validators for its execution. Network sponsorship builds on the existing Gas Subsidies infrastructure rather than introducing a separate transaction system. The Subsidies Registry's chooseFund logic can return a special NETWORK_SPONSORED identifier, telling Sonic that the transaction qualifies to be processed without payment. The network can still be selective about what qualifies. Criteria could identify a particular stablecoin contract, restrict sponsorship to its transfer function, require a minimum transfer amount, or introduce additional conditions around senders and receivers. The user experience remains similar to existing sponsorship. An application creates a qualifying transaction with its gas price or gas-fee cap set to zero, the user signs it, and the transaction is submitted to Sonic. The difference comes during execution. Regular sponsorship requires an internal transaction to charge the sponsor's fund. A network-sponsored transaction has no sponsor to charge, so that payment transaction is not inserted. Sponsoring Successful Transactions V2.2 also introduces successful-only sponsorship, changing the economics for applications covering their users' network fees. Sponsorship applies only when the transaction succeeds. If an application sponsors a user's first deposit and the deposit completes, the application covers the network fee. If execution fails, the failed attempt does not consume its sponsorship budget. That distinction becomes important at scale. Instead of spending its budget on every attempted interaction, an application can direct sponsorship toward completed user activity. For protocols using sponsorship as part of onboarding or product UX, this makes the cost much easier to control. From sponsored transactions to sponsored workflows Sponsorship becomes more useful when it can compose with the other execution primitives arriving with V2.2. Bundled Transactions allow related transactions to execute with fate-sharing and no interleaving between their steps. A workflow can require every transaction to succeed or have the sequence rolled back rather than leaving the user with a partially completed operation. Consider a flow where a user needs to approve an asset, deposit it and perform another action. Sponsorship can remove the requirement to acquire S before beginning, while bundles can coordinate the related transactions so the workflow does not end in a partially executed state. Sponsored transactions can also be included within bundles. This creates a more flexible execution model. Sonic can separate who authorises a transaction, who pays for it, whether a qualifying transaction requires payment at all, and how related transactions execute together. The user still signs what they do. Applications decide what they subsidise. For selected activities, the network can remove the fee entirely. And with bundles, sponsored transactions can become part of coordinated multi-step workflows. Sponsorship is no longer just a way to pay someone else's gas. With V2.2, it becomes part of how applications are designed.
10·CNeutral
n
news9/3news
Sponsored By Design
How Sonic is expanding transaction sponsorship with V2.2.
A user bridges assets to Sonic. They have USDC, ETH, or another asset they want to use, but no S to pay the network fee. Despite already having funds onchain, their first interaction can stop before it starts.
Sonic introduced protocol-level transaction sponsorship with v2.1.2, allowing applications to cover network fees for their users. V2.2 takes that model further. Network-sponsored transactions can remove the fee entirely for qualifying activity, while successful-only sponsorship gives applications more control over when their sponsorship budget is spent.
The result is a broader model for transaction execution: the user can pay, an application can pay, or for selected transactions, nobody has to pay at all.
Sponsorship At The Protocol Level
Sponsored Transactions on Sonic do not rely on an offchain relayer forwarding transactions for users. Sonic's transaction processing recognises sponsorship requests directly, while an onchain Subsidies Registry holds deposited S and defines which transactions those funds can cover.
A transaction requests sponsorship by setting its gas price, or fee cap for newer transaction types, to zero. The node checks the Subsidies Registry and, if an eligible fund has sufficient balance, accepts the transaction for sponsored execution. The user still signs through the normal wallet flow.
Sponsorship therefore changes who pays for execution, not who authorises the action.
Apps Choose What They Pay For
Sonic allows sponsors to define which activity they are willing to cover rather than paying for every transaction a user makes.
Sponsorship can apply to transactions from a particular account, interactions with a particular contract, or calls to a specific contract function. Sponsors can narrow this further to a particular account calling a particular function. There are also dedicated mechanisms for ERC-20 approvals and bootstrap sponsorship, which can cover the first few transactions from a new account.
A DEX could cover the approval required before a swap without paying for unrelated wallet activity. A lending market could cover interactions with its contracts, while another application could sponsor a new user's first few actions.
Before execution, Sonic checks that sponsorship is still available. If it is, the user's transaction executes and an internal transaction charges the selected sponsorship fund for the gas consumed.
This means the network fee still exists. It simply comes from the sponsor's deposit rather than the user's wallet.
What If The Fund Runs Out?
Sponsorship coverage can change while a transaction waits in the pool. A transaction might qualify when submitted but lose its backing if other transactions consume the available balance first. Sonic rechecks pending sponsored transactions and can remove those that are no longer covered.
Sponsored transactions also carry an effective tip of zero, giving them the lowest transaction-pool priority. Under high network load, transactions offering a positive tip are prioritised ahead of them.
These constraints are part of the trade-off. Sponsorship removes a payment requirement from the user, but the network still has to account for the execution and ensure someone is covering its cost.
When Nobody Pays
V2.2 extends the existing system with network-sponsored transactions.
With a regular transaction, the user pays. With a sponsored transaction, an application or another sponsor pays from deposited S. With a network-sponsored transaction, a qualifying transaction can be processed without a token payment at all. No S is consumed, burned or rewarded to validators for its execution.
Network sponsorship builds on the existing Gas Subsidies infrastructure rather than introducing a separate transaction system. The Subsidies Registry's chooseFund logic can return a special NETWORK_SPONSORED identifier, telling Sonic that the transaction qualifies to be processed without payment.
The network can still be selective about what qualifies. Criteria could identify a particular stablecoin contract, restrict sponsorship to its transfer function, require a minimum transfer amount, or introduce additional conditions around senders and receivers.
The user experience remains similar to existing sponsorship. An application creates a qualifying transaction with its gas price or gas-fee cap set to zero, the user signs it, and the transaction is submitted to Sonic.
The difference comes during execution. Regular sponsorship requires an internal transaction to charge the sponsor's fund. A network-sponsored transaction has no sponsor to charge, so that payment transaction is not inserted.
Sponsoring Successful Transactions
V2.2 also introduces successful-only sponsorship, changing the economics for applications covering their users' network fees.
Sponsorship applies only when the transaction succeeds. If an application sponsors a user's first deposit and the deposit completes, the application covers the network fee. If execution fails, the failed attempt does not consume its sponsorship budget.
That distinction becomes important at scale. Instead of spending its budget on every attempted interaction, an application can direct sponsorship toward completed user activity.
For protocols using sponsorship as part of onboarding or product UX, this makes the cost much easier to control.
From sponsored transactions to sponsored workflows
Sponsorship becomes more useful when it can compose with the other execution primitives arriving with V2.2.
Bundled Transactions allow related transactions to execute with fate-sharing and no interleaving between their steps. A workflow can require every transaction to succeed or have the sequence rolled back rather than leaving the user with a partially completed operation.
Consider a flow where a user needs to approve an asset, deposit it and perform another action. Sponsorship can remove the requirement to acquire S before beginning, while bundles can coordinate the related transactions so the workflow does not end in a partially executed state. Sponsored transactions can also be included within bundles.
This creates a more flexible execution model. Sonic can separate who authorises a transaction, who pays for it, whether a qualifying transaction requires payment at all, and how related transactions execute together.
The user still signs what they do. Applications decide what they subsidise. For selected activities, the network can remove the fee entirely. And with bundles, sponsored transactions can become part of coordinated multi-step workflows.
Sponsorship is no longer just a way to pay someone else's gas. With V2.2, it becomes part of how applications are designed.