It has been almost three months since we announced our first implementation of chain abstraction, and we want to share with our community the progress. TLDR: This article is a closer look to our changelog this past 3 months, and we're working on a cool demo to showcase the full end-to-end experience.
Our vision: Community as Value-Sharing Liquidity Providers
At Openfort, we've taken a unique approach to chain abstraction. While many solutions in the market rely on third-party solvers or fillers who compete to front liquidity on destination chains in exchange for fees, we've placed ecosystems at the center of our model.
Our vision grants ecosystems the power to become liquidity providers for their own users. Instead of value being captured by external solvers, ecosystems deploy tailor-made 4337 chain abstraction infrastructure that allows them to share this value directly with their users.
This fundamental shift transforms the relationship between ecosystems and their users. Ecosystems now have the tools to provide a unified balance that's instantly accessible across all their applications, regardless of the underlying blockchain. Users gain a seamless, friction-free experience without sacrificing security or control over their assets.
The evolution of Openfort chain abstraction: From v0.1 to today
Our chain abstraction framework has undergone significant evolution since its inception. What started as a proof of concept has grown into a "almost" production-ready system that addresses real-world requirements for secure, efficient cross-chain transactions.
Core components and their evolution
- Time-Locked Vaults Our system centers around tokenized vaults that securely store user funds with configurable locking periods. These vaults serve as counterparty guarantees for Paymasters, ensuring that funds are only used as intended. Unlike traditional locked assets, these vaults can be yield-bearing, allowing users to earn returns while their assets serve as security.
We've simplified the "locking" process to be as user-friendly as possible - users simply send a transaction from their EOA to their Smart Contract Account, and a backend watcher automatically transfers the funds to a time-locked vault using a pre-approved session key.
- Invoice Manager A critical advancement in our system is the implementation of the Invoice Manager, which:
- Manages the settlement of invoices between chains
- Prevents double-repayment of invoices with state proof verification
- Authorizes paymasters and paymaster verifiers
This component has been crucial in protecting users against double-repay scenarios, a key requirement we've successfully implemented.
-
Ecosystem Paymasters Our 4337-compatible Chain Abstraction Paymasters (CABPaymasters) front funds on destination chains for users with sufficient locked balances. Each ecosystem owns its Paymaster, giving them direct control over the experience while maintaining a non-custodial architecture.
-
Paymaster Verifiers We've implemented permissionless verification of remote events and storage proofs, allowing for trustless verification of invoices across chains.
Production requirements met
Since our initial release, we've successfully implemented several critical production requirements:
-
Protected users against double-repay: Through state-proofs and our InvoiceManager, we've ensured that invoices cannot be repaid multiple times, protecting both users and ecosystems.
-
Execution at destination chain speed: Transactions execute at the native speed of the destination chain, with repayment happening asynchronously on the source chain.
-
Proving system fallbacks: Beyond Polymer's fast proving system (thanks to the V2), we've integrated Hashi as a fallback proving mechanism, ensuring that the system can continue to operate even if primary proving services are unavailable.
-
Native token sponsorship: We've implemented native token sponsorship with refund rates agreed upon at transaction signing, not at repayment time. This protects users from token volatility during the transaction lifecycle.
Our system now leverages cross-L2 execution proofs from Polymer, eliminating the need for users to trust Openfort or the Ecosystem. Repayment only occurs with verified execution proof from the destination chain, and the InvoiceManager tracks all invoices on-chain to prevent double-refunds.
What sets our approach apart
Our chain abstraction framework differs fundamentally from other solutions in the market:
Ecosystem-Centric vs. Solver Networks
While many approaches rely on third-party solvers or fillers to compete for providing liquidity, we empower ecosystems to be their own liquidity providers. This allows ecosystems to capture and share value that would otherwise go to external parties.
Yield-Bearing Security
Our time-locked vaults allow users to earn yields on their locked assets, transforming what would typically be idle capital into productive investments. This represents a significant improvement over traditional security models where locked assets generate no returns.
True Abstraction Across Applications
Our solution unifies user liquidity across apps within an ecosystem, providing a single balance that's instantly spendable regardless of which chain an application runs on. This creates a seamless experience where users don't need to think about which chain they're interacting with.
Looking Ahead: Completing the Chain Abstraction Vision
While we've made significant progress, several key components of our production roadmap are still in active development:
- Transaction Sequencing Enhancements
We're working on advanced transaction sequencing mechanisms to prevent double-spending of counterparty resources, further enhancing the security of our system.
- Non-Custodial Security Architecture for Paymasters
Although our current implementation provides strong security guarantees, we're advancing our integration with secure enclaves (via lit, turnkey, and nitro) with custom policies to ensure that Openfort never has custody of ecosystem funds.
- Intelligent Liquidity Path Selection
We're developing systems to automatically select the cheapest refund liquidity path for each transaction. Users will approve these paths by signing an EIP-712 message, ensuring transparency and control over how their transactions are processed.
- L2 Reorg Resistance
To address the challenges of layer-2 reorganizations, we're implementing additional safeguards to ensure transaction finality even in cases of network reorganizations.
- External Liquidity Fallbacks
We're building fallback mechanisms to external liquidity sources, ensuring transaction execution even in cases where ecosystem liquidity might be constrained.
As we continue to develop and refine our chain abstraction solution, we invite developers, ecosystems, and users to join us on this journey. Together, we can build a future where blockchain interactions are as simple and intuitive as traditional web experiences, unlocking the full potential of Web3 for everyone.