Today, we’re diving into Rigoblock’s journey and unveiling a major upgrade to the Rigoblock protocol—a vision we’ve been working toward since our inception in 2016. Rigoblock enables anyone to deploy "smart pools," which are smart contracts designed to mint and burn pool tokens while interacting with onchain applications. Unlike a standard Ethereum wallet, smart pools have more constraints (they must be programmed for specific actions), but this trade-off offers enhanced security and granular control over operations. This makes them ideal for both individual and multi-user scenarios.

For example, smart pools eliminate the need to understand complex concepts like approvals, sparing users from the endless approval/signature spoofing attacks that have plagued many and drained countless wallets. Additionally, users can earn yield on idle assets by staking GRG, Rigoblock’s native token.

The Challenges with V3

In our V3 protocol, smart pools operate similarly to an ERC4626 token, where mint and burn operations depend on the pool’s token price—the total value of the pool’s tokens divided by the number of minted pool tokens. However, price updates in V3 were manual: pool operators had to calculate the value offchain and input it onchain. While this decentralized some control from the protocol’s core (and its governance) to the edges (pool operators), it introduced several issues:

• Lack of Verifiable Pricing: There was no reliable way to verify the unitary price calculation.

• Exploitable Delays: Delays in price updates created small but potential vulnerabilities.

• Inaccurate Mint/Burn Amounts: Decoupling price updates from mint/burn operations often led to incorrect minted or burned amounts.

• Unnecessary Gas Costs: Manual updates required pool operators to spend gas, even when no mint/burn transactions occurred.

• Error-Prone Process: Manual calculations and value inputs were susceptible to human error.

• Token Whitelist Restrictions: To ensure protocol integrity, Rigoblock Governance maintained a token whitelist, limiting the tokens smart pools could hold.

While striving for decentralization, we inadvertently reduced the protocol’s inclusivity by restricting the number of ownable tokens. Governance had to decide which tokens to include, a process that was neither scalable nor efficient. Adding a new token took time, and during periods of high gas prices on Layer 1, frequent price updates became unsustainable.

Introducing Rigoblock V4: A Universal Layer for Asset Management

Rigoblock V4 addresses these issues, transforming the protocol into a truly universal layer for building onchain asset management applications. Our philosophy is to make Rigoblock a lightweight, minimally restrictive layer, allowing developers to build arbitrary rules on top without needing our permission.

Key to V4 is a new universal price feed that reliably provides prices for virtually any token. As long as a price feed exists for a token, that token becomes ownable by a smart pool. The price feed ensures continuous price availability and uses a Time-Weighted Average Price (TWAP) to protect against flash price manipulations and attacks on liquidity positions’ underlying balances.

This upgrade delivers two major outcomes:

1. Unrestricted Token Ownership: Governance no longer needs to approve tokens, enabling developers to explore creative strategies and allowing pool operators to enter positions early without delays.

2. Automated, Verifiable Pricing: Price calculations are now automatic, onchain, and updated as needed, ensuring accuracy and transparency.

In short, Rigoblock V4 delivers a universal protocol for asset management while significantly reducing the governance oversight required for smart pool operations. For a quick summary of the V4 activation process, skip to the section “How V4 Activation Will Happen.”

Key Changes in V4

V4 introduces several breaking changes to the API and design.

API Changes:

• The updateUnitaryValue method no longer requires manual value input since the protocol now calculates it automatically. Access restrictions have also been removed, allowing anyone to call this method.

• Owned tokens, liquidity positions, and active applications are now stored in the smart pool’s own storage. Pool operators can prune these for efficient Net Asset Value (NAV) estimates, and the protocol will sync them automatically the first time V4 is used post-upgrade.

Design Changes:

• Extensions vs. Adapters: In V3, extensions and adapters were similar and governance-upgradable. In V4, extensions are non-upgradable and must be predefined before a pool’s deployment. This ensures deterministic price access via a Uniswap V4 hook. Adapters, however, remain governance-upgradable for now, providing flexibility to protect smart pools’ Total Value Locked (TVL) from vulnerabilities in external applications. Making adapters non-upgradable in the future could save at least 5,000 gas per call, a change we’re considering for a later upgrade.

• If successful, this would further reduce governance’s role for deployed smart pools, limiting its responsibilities to upgrading the canonical implementation address in the beacon, managing the Rigoblock pool registry, and overseeing the GRG staking system—none of which impact smart pool operations.

• As with V3, applications remain accessible in write mode only to pool operators.

Supported Applications in V4:

• Uniswap swaps (V2, V3, V4 via the Universal Router)

• Uniswap liquidity (V4 only)

• GRG staking

• Rigoblock Governance voting

More applications will be added based on TVL-weighted demand. Note that Uniswap V3 liquidity is not supported in V4, as V4 offers greater flexibility for liquidity providers, and existing V3 liquidity can be migrated to V4 or removed. Applications maintain the same APIs as in V3, so developers can use Rigoblock smart pools without adjusting their code, just as they would with the applications directly.

Technical Improvements:

• V4 leverages EIP-1153 (transient storage opcodes) for non-reentrant modifiers and to avoid handling large arrays in memory. This results in a more linear increase in gas costs for price calculations as the number of held tokens and liquidity positions grows. Initially, smart pools can hold up to 128 tokens and 64 liquidity positions, though we’re stress-testing to increase these limits.

• The spread charge on mint operations has been removed. Previously, this percentage fee protected pools from exploits due to mismatches between pool value and underlying assets. With real-time price calculations, this risk is reduced, and the spread artificially inflated the unitary price. A spread is still applied on burn operations under certain conditions (e.g., when the holder isn’t the sole pool holder), with the amount benefiting remaining holders. The maximum spread has been lowered from 10% to 5%, with potential removal in the future as price accuracy improves. The default spread is the maximum unless a smaller value is set.

• To further protect against price manipulations, a lockup period (default maximum of 30 days, minimum of 1 day) enforces a minimum time between the last mint and a burn operation.

New Features in V4

A standout feature in V4 is the ability for pool holders to burn using any token held by the pool. In V3, burns required sufficient base token balance, failing if the pool’s base token had been converted into another token. With the new burnForToken method, holders can redeem another token instead of the base token, even if the base token balance is insufficient. For now, this feature is limited to cases where the pool lacks enough base token, but future updates may remove this restriction and potentially allow minting with other tokens based on demand.

How V4 Activation Will Happen

Rigoblock V4 will be enabled through an onchain governance proposal for each supported chain. Once the new implementation is set in the protocol factory, pool operators must upgrade their smart pools to point to the V4 implementation. Operators can choose to remain on V3, but as V4 introduces breaking changes, the interface will soon deprecate support for V3 pools, limiting their operations at the interface level. V3 pools will still be displayed, but some operations will require direct onchain interaction.

On the upside, upgrading to V4 doesn’t require redeploying your smart pool—your pool will retain the same address across all supported chains.

Conclusion

With Rigoblock V4, we’re taking a significant step toward our vision of a universal protocol for asset management—one that’s secure, inclusive, and developer-friendly. By removing barriers to token ownership, automating price calculations, and introducing powerful new features, V4 empowers pool operators and developers to innovate like never before. We’re excited to see the creative strategies and applications that will emerge as the community adopts this upgrade. Stay tuned for the governance proposal to activate V4 on your chain, and join us in shaping the future of onchain asset management! Share your thoughts, strategies, or questions with us on Discord, and let’s build the next generation of asset management together.

Today, we’re diving into Rigoblock’s journey and unveiling a major upgrade to the Rigoblock protocol—a vision we’ve been working toward since our inception in 2016. Rigoblock enables anyone to deploy "smart pools," which are smart contracts designed to mint and burn pool tokens while interacting with onchain applications. Unlike a standard Ethereum wallet, smart pools have more constraints (they must be programmed for specific actions), but this trade-off offers enhanced security and granular control over operations. This makes them ideal for both individual and multi-user scenarios.

For example, smart pools eliminate the need to understand complex concepts like approvals, sparing users from the endless approval/signature spoofing attacks that have plagued many and drained countless wallets. Additionally, users can earn yield on idle assets by staking GRG, Rigoblock’s native token.

The Challenges with V3

In our V3 protocol, smart pools operate similarly to an ERC4626 token, where mint and burn operations depend on the pool’s token price—the total value of the pool’s tokens divided by the number of minted pool tokens. However, price updates in V3 were manual: pool operators had to calculate the value offchain and input it onchain. While this decentralized some control from the protocol’s core (and its governance) to the edges (pool operators), it introduced several issues:

• Lack of Verifiable Pricing: There was no reliable way to verify the unitary price calculation.

• Exploitable Delays: Delays in price updates created small but potential vulnerabilities.

• Inaccurate Mint/Burn Amounts: Decoupling price updates from mint/burn operations often led to incorrect minted or burned amounts.

• Unnecessary Gas Costs: Manual updates required pool operators to spend gas, even when no mint/burn transactions occurred.

• Error-Prone Process: Manual calculations and value inputs were susceptible to human error.

• Token Whitelist Restrictions: To ensure protocol integrity, Rigoblock Governance maintained a token whitelist, limiting the tokens smart pools could hold.

While striving for decentralization, we inadvertently reduced the protocol’s inclusivity by restricting the number of ownable tokens. Governance had to decide which tokens to include, a process that was neither scalable nor efficient. Adding a new token took time, and during periods of high gas prices on Layer 1, frequent price updates became unsustainable.

Introducing Rigoblock V4: A Universal Layer for Asset Management

Rigoblock V4 addresses these issues, transforming the protocol into a truly universal layer for building onchain asset management applications. Our philosophy is to make Rigoblock a lightweight, minimally restrictive layer, allowing developers to build arbitrary rules on top without needing our permission.

Key to V4 is a new universal price feed that reliably provides prices for virtually any token. As long as a price feed exists for a token, that token becomes ownable by a smart pool. The price feed ensures continuous price availability and uses a Time-Weighted Average Price (TWAP) to protect against flash price manipulations and attacks on liquidity positions’ underlying balances.

This upgrade delivers two major outcomes:

1. Unrestricted Token Ownership: Governance no longer needs to approve tokens, enabling developers to explore creative strategies and allowing pool operators to enter positions early without delays.

2. Automated, Verifiable Pricing: Price calculations are now automatic, onchain, and updated as needed, ensuring accuracy and transparency.

In short, Rigoblock V4 delivers a universal protocol for asset management while significantly reducing the governance oversight required for smart pool operations. For a quick summary of the V4 activation process, skip to the section “How V4 Activation Will Happen.”

Key Changes in V4

V4 introduces several breaking changes to the API and design.

API Changes:

• The updateUnitaryValue method no longer requires manual value input since the protocol now calculates it automatically. Access restrictions have also been removed, allowing anyone to call this method.

• Owned tokens, liquidity positions, and active applications are now stored in the smart pool’s own storage. Pool operators can prune these for efficient Net Asset Value (NAV) estimates, and the protocol will sync them automatically the first time V4 is used post-upgrade.

Design Changes:

• Extensions vs. Adapters: In V3, extensions and adapters were similar and governance-upgradable. In V4, extensions are non-upgradable and must be predefined before a pool’s deployment. This ensures deterministic price access via a Uniswap V4 hook. Adapters, however, remain governance-upgradable for now, providing flexibility to protect smart pools’ Total Value Locked (TVL) from vulnerabilities in external applications. Making adapters non-upgradable in the future could save at least 5,000 gas per call, a change we’re considering for a later upgrade.

• If successful, this would further reduce governance’s role for deployed smart pools, limiting its responsibilities to upgrading the canonical implementation address in the beacon, managing the Rigoblock pool registry, and overseeing the GRG staking system—none of which impact smart pool operations.

• As with V3, applications remain accessible in write mode only to pool operators.

Supported Applications in V4:

• Uniswap swaps (V2, V3, V4 via the Universal Router)

• Uniswap liquidity (V4 only)

• GRG staking

• Rigoblock Governance voting

More applications will be added based on TVL-weighted demand. Note that Uniswap V3 liquidity is not supported in V4, as V4 offers greater flexibility for liquidity providers, and existing V3 liquidity can be migrated to V4 or removed. Applications maintain the same APIs as in V3, so developers can use Rigoblock smart pools without adjusting their code, just as they would with the applications directly.

Technical Improvements:

• V4 leverages EIP-1153 (transient storage opcodes) for non-reentrant modifiers and to avoid handling large arrays in memory. This results in a more linear increase in gas costs for price calculations as the number of held tokens and liquidity positions grows. Initially, smart pools can hold up to 128 tokens and 64 liquidity positions, though we’re stress-testing to increase these limits.

• The spread charge on mint operations has been removed. Previously, this percentage fee protected pools from exploits due to mismatches between pool value and underlying assets. With real-time price calculations, this risk is reduced, and the spread artificially inflated the unitary price. A spread is still applied on burn operations under certain conditions (e.g., when the holder isn’t the sole pool holder), with the amount benefiting remaining holders. The maximum spread has been lowered from 10% to 5%, with potential removal in the future as price accuracy improves. The default spread is the maximum unless a smaller value is set.

• To further protect against price manipulations, a lockup period (default maximum of 30 days, minimum of 1 day) enforces a minimum time between the last mint and a burn operation.

New Features in V4

A standout feature in V4 is the ability for pool holders to burn using any token held by the pool. In V3, burns required sufficient base token balance, failing if the pool’s base token had been converted into another token. With the new burnForToken method, holders can redeem another token instead of the base token, even if the base token balance is insufficient. For now, this feature is limited to cases where the pool lacks enough base token, but future updates may remove this restriction and potentially allow minting with other tokens based on demand.

How V4 Activation Will Happen

Rigoblock V4 will be enabled through an onchain governance proposal for each supported chain. Once the new implementation is set in the protocol factory, pool operators must upgrade their smart pools to point to the V4 implementation. Operators can choose to remain on V3, but as V4 introduces breaking changes, the interface will soon deprecate support for V3 pools, limiting their operations at the interface level. V3 pools will still be displayed, but some operations will require direct onchain interaction.

On the upside, upgrading to V4 doesn’t require redeploying your smart pool—your pool will retain the same address across all supported chains.

Conclusion

With Rigoblock V4, we’re taking a significant step toward our vision of a universal protocol for asset management—one that’s secure, inclusive, and developer-friendly. By removing barriers to token ownership, automating price calculations, and introducing powerful new features, V4 empowers pool operators and developers to innovate like never before. We’re excited to see the creative strategies and applications that will emerge as the community adopts this upgrade. Stay tuned for the governance proposal to activate V4 on your chain, and join us in shaping the future of onchain asset management! Share your thoughts, strategies, or questions with us on Discord, and let’s build the next generation of asset management together.