# Lamina
## Problem While the growth of new blockchains has enabled greater scaling and new use cases, it has also led to fragmented liquidity and a poor user experience. With over 100+ L1s, L2s and rollups as a service (RaaS) proliferating the amount of chains out there today, the UX for end-users and developers has eroded. Users face issues such as managing multiple wallets, handling seed phrases, and dealing with different RPC networks and gas tokens. Terrible UX is one of the major obstacles to adoption of crypto products preventing mainstream adoption. ## The Solution - Lamina Lamina is an omni-chain DeFi platform that pioneers a reimagined UX in DeFi, enabling a new paradigm of on-chain trading and asset management powered by intents. Built from the ground up with seamless UX, interoperability and security as a priority, our goal is to supercharge the mainstream adoption of DeFi and Web3. Powered by Lamina's proprietary cross-chain infrastructure based on an intent-centric model that leverages solver networks to power chain abstraction, Lamina enables users to hold all their assets on one chain and transact on any chain instantly, without ever having to use a bridge or worry about changing different wallets and signing multiple approvals and transactions. Lamina brings instant atomic execution for all transaction types, not just swaps. This includes lending, borrowing, staking, restaking, flash loans etc. across all ecosystems (EVM, SVM, TONVM, MoveVM, BTC) so users can interact with any DeFi protocol on any chain from one unified frontend on the Lamina platform. Built around a universal master account model that integrates smart contract wallets at the protocol level, retail and institutional users can transact all across DeFi with just one wallet and manage their portfolio and positions with ease. * **Unified Interface**: The Lamina frontend provides a unified user experience by interacting with the underlying smart contract wallet on different blockchains. This interface displays aggregated balances, transaction histories, and dApp interactions from multiple chains. * **Seamless dApp Integration**: The wallet provides a single point of interaction for various dApps across blockchains, simplifying the user experience and promoting interoperability. This eliminates the need for EOAs and allows for more sophisticated features like multisig security, social recovery and multicall transactions, ultimately reducing friction and making blockchain technology more accessible to the average user for on-chain trading and asset management while solving for the fragmentation of liquidity in a multi-chain world. ## Benefits **No bridging:** Our implementation enables users and protocols to move liquidity across various blockchains without having to interact with bridges. Bridges as we know are insecure by design. Of the $3.1B of crypto exploited in DeFi, 64% of them were from cross-chain bridging. \ **Instantaneous transactions:** Bridging from one chain to another chain often requires users to wait minutes to sometimes hours for their transaction to settle. In DeFi, the opportunity cost of waiting even a few minutes is literally millions of dollars. With Lamina, you can take part in cross-chain DeFi without ever having to wait. \ **Improved UX:** By using account abstraction and smart contract wallets, we have drastically improved the UX so users don't have to download multiple wallets for different blockchains. Simple one-click login improves the onboarding experience so users can forget about seed phrases, gas, bridging, and the poor UX of on-chain DeFi. \ **Institutional-grade Security:** Lamina chooses to be proactive rather than reactive when it comes to security. Security audits are a one-way street. Even after a protocol has been audited, there are always chances for exploits and vulnerabilities that have been overlooked. New attack vectors can always arise at any point in time.\ \ This is why Lamina has built-in realtime monitoring and compliance solutions that protect retail and institutional users from a multitude of on-chain exploit with 24/7 risk assessment and mitigation. # Existing Solutions vs Lamina Various existing solutions like liquidity aggregation, shared sequencers, cross-chain messaging protocols, and smart contract wallets have attempted to address liquidity fragmentation but have been insufficient.
## **Shared Sequencers** Platforms like Espresso aim to mitigate liquidity fragmentation by centralizing transaction sequencing within specific ecosystems. However, their limitation is that they only work within their ecosystems. This means that they cannot aggregate liquidity across different blockchain ecosystems, limiting their scope and effectiveness.​ ## **Cross-Chain Messaging Protocols** Solutions like Axelar and LayerZero, along with bridging aggregators like Li.Fi, attempt to improve the cross-chain experience by facilitating communication and asset transfer between different blockchains. Despite these efforts, they struggle with long settlement times and have been vulnerable to large-scale exploits. The existence of multiple, often incompatible bridges further complicates the user experience, leading to additional fragmentation rather than unification. ## **Smart Contract Wallets** Wallets like Safe and Biconomy help with wallet management and allow for gas abstraction, simplifying user interactions by eliminating the need to hold multiple gas tokens. However, they still do not fully address the issues of cross-chain transactions and liquidity fragmentation, as they are often limited to specific blockchain ecosystems. ## **Intent-Based Infrastructure** Platforms like CowSwap and Across Protocol aim to simplify transaction flows by abstracting away the complexities of gas fees and multi-step transactions. These infrastructures use "intents" to express user desires in a simplified manner. However, they are limited by the underlying infrastructure they rely on and are not universally applicable across all blockchain ecosystems​​. ## **Liquidity Aggregation** Aggregating liquidity at the blockchain level. Polygon's AggLayer is highlighted as a compelling solution that provides a unified bridge secured by zk proofs, allowing chains to opt in without sacrificing their technical independence. While Polygon's AggLayer is designed to be a neutral and holistic solution for liquidity aggregation, it may not connect to chains and virtual machines (VMs) that cannot be proven using its zk-proof solution. This limits the extent of liquidity aggregation achievable through AggLayer. ## Summary These solutions, while addressing parts of the problems, are insufficient on their own and sometimes even exacerbate the issues due to their isolated implementations. Lamina's approach at chain abstraction aims to unify these disparate systems and create a more seamless experience for users across different blockchains. # How it works
The flow of the intent-based transaction system involves several components, from users to decentralized applications (dApps). Here’s a breakdown of each stage: 1. **Users:** The process begins with users who express their goals or intents. Instead of specifying detailed actions, users only need to describe what they want to achieve. 2. **Lamina Unified Frontend (Protocol API):** The expressed intents are received by the Smart Contract Wallet (SCW) frontend. It converts these intents into a more detailed format called User Operations (UserOps). 3. **Lamina Interop Infrastructure (Crosschain API):** The UserOps are then handled by bundlers. Bundlers validate and group these operations, executing the necessary steps to meet the intent. The Solvers are then responsible for interpreting the intents and determining how to fulfill them. They also handle payment of gas fees and other execution details. 4. **SCW Contracts:** The bundlers communicate with SCW contracts, which are smart contracts specifically designed to manage the users' wallets and execute the required transactions according to the UserOps. 5. **Dapps:** Finally, the processed transactions are sent to decentralized applications (dapps) for execution. This is where the actual transaction takes place, fulfilling the user’s original intent. In this system, the user's experience is streamlined because they only need to specify the end goal (intent), and the underlying infrastructure handles all the complex operations needed to achieve that goal. This approach aims to enhance user experience by abstracting the complexities involved in blockchain transactions. {% content-ref url="/pages/HhNSc069qhn65WkAOvGE" %} [Crosschain System Overview](/technology/crosschain-system-overview) {% endcontent-ref %} # Tokenomics Lamina introduces a native token designed to align incentives across our ecosystem and ensure seamless operation of our platform. The token serves multiple purposes, including incentivizing solvers, encouraging user liquidity, and enabling governance and loyalty mechanisms. Below, we detail the key functions and distribution mechanisms of our token, ensuring a fair and efficient system for all participants. ## **Value Flow**
## **Token Functions** 1. **Incentivizing Solvers** * **Role of Solvers**: Solvers are critical to the platform's functionality, executing transactions and ensuring smooth and secure operations. They contribute computational power and expertise to process and validate transactions within our network. * **Incentive Mechanism**: To attract and retain high-quality solvers, the token is used as a reward mechanism. Solvers receive tokens proportional to their contribution to the network, based on the complexity and volume of transactions they handle. This incentivizes them to join the network and consistently provide reliable service. 2. **Liquidity Commitment** * **User Liquidity**: For the platform to operate efficiently and offer frictionless experiences, a substantial amount of liquidity is essential. Users are encouraged to commit liquidity by staking tokens to solvers, which helps facilitate instant and atomic transactions. * **Incentives for Liquidity Providers**: Users who provide liquidity are rewarded with tokens. The rewards are dynamically adjusted based on market conditions, transaction volumes, and the duration of the liquidity commitment. This mechanism ensures that liquidity remains robust, and the platform can handle a high volume of transactions. 3. **Governance and Treasury Management** * **Governance Mechanisms**: The token also serves as a governance tool, giving holders the power to participate in decision-making processes. Token holders can vote on various proposals, including updates to the protocol, changes in fee structures, and treasury allocations. This democratic process ensures that the community has a say in the platform's development and evolution. * **Treasury Control**: A portion of the token supply is allocated to a community treasury. This treasury is used for platform development, marketing, partnerships, and other initiatives. Token holders can vote on the usage of these funds, ensuring transparency and accountability. 4. **Loyalty Rewards** * **Loyalty Mechanisms**: To foster long-term engagement, the platform includes loyalty programs that reward users for their continued participation. This includes staking rewards, transaction fee discounts, and exclusive access to new features or products. The loyalty rewards are distributed in tokens, incentivizing users to remain active and loyal to the platform. ## **Token Distribution** The initial distribution of tokens is designed to balance immediate needs with long-term sustainability. The distribution plan includes: * **Community and Ecosystem**: A significant portion of tokens is allocated to the community and ecosystem fund. This includes rewards for solvers, liquidity providers, and users participating in governance. * **Team and Advisors**: A portion of tokens is reserved for the project team and advisors. These tokens are subject to vesting schedules to align the interests of the team with the long-term success of the platform. * **Investors**: Early investors and strategic partners receive a portion of the tokens, also subject to vesting periods, to ensure their commitment to the project’s growth. * **Treasury**: A reserve of tokens is set aside in the community treasury, governed by token holders, to fund future development, marketing, and other essential activities. ## **Token Supply and Emission** * **Total Supply**: The total supply of tokens is capped at a fixed amount, ensuring scarcity and preventing inflation. The specific supply cap will be determined based on detailed economic modeling. * **Emission Schedule**: The release of tokens follows a predefined emission schedule, designed to incentivize early adoption while ensuring a steady supply for ongoing rewards and incentives. # FAQs ### Is Lamina just middleware or infrastructure? No. Lamina is a consumer facing application built on top of our own crosschain infrastructure, powered by our own solver network. ### What networks do you support? We currently support EVM, TVM (TON), SVM and BTC L2s. ### What tokens do you support? We support ERC-20,721,1155, SPL tokens, BRC-20, Runes, Ordinals and Jettons. ### Do you support LSTs / LRTs? Yes. ### Do you support NFTs? Yes. ### Can I use Lamina on my phone? Yes, you can access Lamina on any browser on your phone and even directly on telegram through the Lamina Telegram mini app. # What are Intents? ## **Introduction** Cross-chain intents are a foundational concept powering the Lamina platform, enabling seamless interactions across multiple blockchain networks. They provide a mechanism for users to initiate and execute actions that span different blockchains, leveraging the diverse capabilities and liquidity available across all ecosystems. ## **What Are Cross-Chain Intents?** A cross-chain intent is a declarative statement or request made by a user or application, specifying an action to be performed across different blockchain networks. This action can involve a variety of operations, such as transferring assets, executing smart contracts, or interacting with decentralized applications (dApps) on different chains. For instance, instead of placing orders by signing a raw transaction that executes directly on the blockchain (as done on Uniswap or SushiSwap), Lamina users submit an "intent to trade" message. This message outlines details such as the assets and amounts they wish to trade and is signed by the user. The intent acts as a signed authorization, allowing solvers to carry out the trade on the user's behalf using the specified assets and amounts. Cross-chain intents are crucial for enabling interoperability and improving UX in a fragmented omnichain world, where assets and services are spread across multiple blockchains. ## **Key Characteristics** 1. **Declarative Nature**: Cross-chain intents are high-level descriptions of actions that a user wishes to execute, rather than detailed instructions. This abstraction allows the underlying protocol to manage the complexities of cross-chain communication. 2. **Interoperability**: They enable seamless interactions between different blockchain networks, allowing users to leverage the unique features and liquidity of each chain without needing to redeploy infrastructure or duplicate assets. 3. **Atomicity**: Cross-chain intents are designed to be executed atomically, ensuring that either all parts of the transaction succeed or none at all. This atomic nature prevents issues such as partial execution, which can lead to asset loss or inconsistencies. ## **Components of Cross-Chain Intents** 1. **Intent Data Structure**: * **Action**: The specific operation to be performed, such as asset transfer, contract execution, etc. * **Source Chain**: The blockchain network where the intent is initiated. * **Target Chain**: The blockchain network where the action is to be executed. * **Parameters**: Additional information required to execute the action, such as asset amounts, contract addresses, and specific instructions. * **Initiator**: The entity (user or application) that creates the intent. * **Signature**: A cryptographic signature that verifies the authenticity and authorization of the intent. 2. **Intent Registry**: A decentralized ledger that records all submitted cross-chain intents. This registry ensures transparency and provides a reference point for validators and executors. 3. **Intent Validators**: Nodes responsible for verifying the validity and authenticity of intents. They check for sufficient funds, compliance with protocol rules, and proper intent structure. 4. **Solver Network**: A network of solvers or agents responsible for carrying out the actions specified in the intents on the target chain. They are critical for bridging the gap between different blockchains and ensuring that the intents are fulfilled accurately. 5. **Communication Protocol**: The underlying protocol that facilitates secure message passing and data synchronization between the involved blockchains. It handles the complexities of cross-chain communication, including data translation and consensus mechanisms. ## **How Cross-Chain Intents Work** 1. **Creation**: A user or application formulates a cross-chain intent by specifying the desired action, along with necessary details such as source and target chains and parameters. 2. **Submission**: The intent is submitted to the Intent Registry on the source chain, along with a cryptographic signature for verification. 3. **Validation**: Intent Validators review the submitted intent to ensure it meets all necessary criteria, including proper authorization and sufficient assets. 4. **Broadcasting**: Upon successful validation, the intent is broadcast to the Executor Network, signaling that it is ready for execution. 5. **Execution**: Solvers on the target chain perform the required actions, such as transferring assets or invoking smart contracts. They ensure that the operation is completed atomically and securely. 6. **Finalization**: After execution, a transaction receipt is generated and sent back to the source chain. The Intent Registry is updated to reflect the completion of the intent, providing a record for transparency and auditing. ## **Use Cases** 1. **Cross-Chain Asset Transfers**: Moving assets from one blockchain to another, enabling users to leverage different platforms and liquidity pools. 2. **Cross-Chain Smart Contract Calls**: Invoking smart contracts on one blockchain based on conditions or events occurring on another chain. 3. **Multi-Chain dApp Interaction**: Allowing decentralized applications to operate seamlessly across multiple blockchains, offering a unified user experience. ## **Advantages of Cross-Chain Intents** 1. **Flexibility and Interoperability**: Users can interact with multiple blockchain networks without being confined to a single ecosystem. 2. **Efficiency**: Eliminates the need for redundant infrastructure deployment and complex cross-chain setups. 3. **Security**: The atomic nature of cross-chain intents ensures that transactions are either fully executed or not at all, preventing partial failures and inconsistencies. ## Summary Cross-chain intents are a powerful and essential backbone of the Lamina platform, enabling the seamless and secure interaction of assets, contracts, and data across different blockchain networks. By abstracting the complexities of cross-chain communication, they empower developers and users to fully leverage the capabilities of a multi-chain ecosystem, driving innovation and interoperability in the DeFi space. # What is Chain Abstraction? The concept of Chain Abstraction aims to address the fragmentation of liquidity and the complexities of user experience in a multichain blockchain world. As the blockchain landscape evolves with numerous chains offering various use cases, users and developers face challenges in navigating and interacting across these disparate networks. Chain Abstraction seeks to unify these interactions, creating a seamless experience akin to Web 2.0 applications while maintaining the fundamental properties of blockchain technology, such as decentralization, trustlessness, and censorship resistance. ## **The Need for Chain Abstraction** The rapid proliferation of blockchains, each with unique features and functionalities, has led to a fragmented ecosystem. Key issues include: * **Liquidity Fragmentation**: Assets and liquidity are spread across multiple chains and layers, making it difficult for users and applications to access a unified liquidity pool. This fragmentation creates inefficiencies, as users must navigate different protocols and bridges to move assets between chains. * **Poor User Experience**: The multichain environment requires users to manage multiple wallets, seed phrases, and gas tokens. Each chain may have different transaction workflows, adding to the complexity. Cross-chain transactions often involve lengthy settlement times and exposure to security risks through bridges. ## **Broader Impact and Future Outlook** ### **Improved Capital Efficiency** By simplifying liquidity management and user interactions, Chain Abstraction can enhance capital efficiency across the blockchain ecosystem. This can lead to more robust and liquid markets, benefiting traders and liquidity providers. ### **User Onboarding** Simplified user experiences can lower the barriers to entry for new users, facilitating broader adoption of blockchain technologies. This is particularly important as the ecosystem seeks to attract users beyond the current crypto-savvy audience. ### **Modular vs. Monolithic Chains** While Chain Abstraction benefits modular chains by facilitating interoperability and liquidity sharing, monolithic chains may also gain from improved user experiences and liquidity aggregation. However, the primary beneficiaries are likely to be the modular chains, which can more easily integrate with the abstracted infrastructure. ## **Summary** Chain Abstraction represents a crucial step toward a more unified and user-friendly blockchain ecosystem. By addressing the challenges of liquidity fragmentation and poor user experience, it offers a comprehensive solution that can drive broader adoption and innovation in the crypto space. As the technology and infrastructure continue to develop, Chain Abstraction has the potential to fundamentally reshape how users and applications interact with blockchain networks. # What are Solver Networks? Solver networks are third parties responsible for executing trades on behalf of users based on their submitted intents. In general, a solver is a computer algorithm that takes the orderbook as input and calculates the optimal prices and traded amounts for all orders and liquidity sources (such as AMMs), ensuring the best overall trading experience. After a user submits an intent, the protocol groups it with other intents into a batch auction. A competition then begins where solvers propose solutions for the intents in the batch. The solver offering the best solution is selected to execute the trades. Solvers are rewarded with Lamina tokens and transaction fees for settling batches, motivating them to find better prices and win the opportunity to execute user intents. # Account Models Account models in blockchain refer to the underlying frameworks used to manage and track ownership of digital assets, execute transactions, and interact with decentralized applications (dApps). These models define how user accounts are structured, how transactions are authorized, and how data is stored and processed. There are different account models for various blockchains and the choice of account model has significant implications for the security, scalability, functionality, and user experience of a blockchain network. ## Major Account Models in Blockchain ### **Unspent Transaction Output (UTXO) Model** * **Description**: The UTXO model, used by Bitcoin and several other blockchains, treats each transaction as consuming and producing unspent transaction outputs. UTXOs are discrete units of value that are either entirely spent or unspent; they do not have partial states. * **Operation**: Each transaction consumes UTXOs as inputs and creates new UTXOs as outputs. A transaction must reference UTXOs from previous transactions as inputs and can produce new UTXOs that are sent to addresses. * **Key Characteristics**: * **Statelessness**: The UTXO model does not maintain a persistent state; each transaction is self-contained. * **Deterministic Balances**: User balances are derived by summing the value of all UTXOs associated with an address. * **Privacy**: Offers some privacy benefits, as users can create multiple addresses and manage their UTXOs across them. ### **Account/Balance Model** * **Description**: The account/balance model is used by Ethereum and many other blockchains. It keeps track of account balances directly, akin to a bank ledger, and includes both simple user accounts and contract accounts (smart contracts). * **Operation**: Accounts have balances and can store code and data. Transactions can change balances and invoke smart contracts. Each account is identified by a unique address. * **Key Characteristics**: * **Statefulness**: The network maintains a global state that includes account balances and smart contract states. * **Direct Interaction**: Accounts can interact directly with each other and with smart contracts. * **Flexibility**: Supports complex operations through smart contracts, enabling a wide range of decentralized applications. ### **Hybrid Models** * **Description**: Some blockchains, such as those in the Polkadot ecosystem or with unique architectures like Solana, employ hybrid models that combine features of the UTXO and account/balance models. * **Operation**: These models may include features like account-based state management while also supporting UTXO-like mechanisms for specific functionalities. * **Key Characteristics**: * **Customization**: These models allow for customized handling of transactions and state, often tailored to specific use cases or optimizations. * **Enhanced Functionality**: They can offer the privacy benefits of UTXOs with the flexibility of account-based systems. ## Differences and Variability in Account Models Across Blockchains ### **Design Philosophy and Goals** Different blockchains are designed with specific goals in mind, such as scalability, privacy, smart contract functionality, or simplicity. These goals influence the choice of account model: * **Bitcoin** emphasizes security and simplicity, opting for the UTXO model to ensure determinism and immutability. * **Ethereum** aims to provide a robust platform for dApps, hence the use of the account/balance model to facilitate smart contract interactions. ### **Scalability Considerations** The choice of account model can significantly impact a blockchain's scalability: * **UTXO Model**: Often more scalable for simple transactions as it does not require maintaining a complex global state. * **Account/Balance Model**: Can handle more complex operations but may face scalability challenges due to the need to maintain a consistent global state. ### **Security and Privacy Requirements** Different account models offer varying levels of security and privacy: * **UTXO Model**: Can enhance privacy through the use of multiple addresses and the non-linkability of UTXOs. * **Account/Balance Model**: Offers direct interaction and complex logic execution but can be more vulnerable to specific attack vectors like reentrancy in smart contracts. ### **Functionality and Flexibility** The account model affects the types of applications that can be built on the blockchain: * **Account/Balance Model**: Supports complex dApps, DeFi applications, and sophisticated user interactions through smart contracts. * **UTXO Model**: Typically used for simpler financial transactions, though innovations like Bitcoin's Taproot and Script can add complexity. ### **User Experience and Usability** The user experience can differ significantly based on the account model: * **Account/Balance Model**: Often provides a more straightforward user experience, as users have a single account balance and address. * **UTXO Model**: Requires users to manage multiple UTXOs, which can complicate user experience, especially in terms of transaction fees and change outputs. ## Summary Account models in blockchain are fundamental to the design and operation of blockchain networks. The choice of model impacts the blockchain's security, scalability, functionality, and user experience. While the UTXO model is well-suited for networks focused on secure and simple transactions, the account/balance model provides the flexibility needed for more complex applications and smart contracts. The specific requirements and goals of each blockchain determine the most appropriate model, leading to the diversity of approaches seen in the blockchain ecosystem. Regardless, the varying account models across different blockchains necessitate downloading multiple wallets, making it cumbersome for users to manage assets and transact seamlessly across various blockchain ecosystems in a multichain world. Lamina's universal account model improves this UX for the end-user. # Ethereum Ethereum uses an account-based model, which is distinct from the UTXO model used by Bitcoin. This model involves accounts that store balances and state information, allowing for direct interactions between accounts and the execution of complex logic through smart contracts. The Ethereum account model consists of two primary types of accounts: Externally Owned Accounts (EOAs) and Contract Accounts (CAs). ## **Externally Owned Accounts (EOAs)** * **Definition**: EOAs are accounts controlled by private keys held by users. They are similar to personal wallets in traditional banking systems. * **Components**: * **Address**: A unique identifier derived from the public key. * **Balance**: The amount of Ether (ETH) held by the account. * **Nonce**: A counter that increments with each transaction sent from the account. It prevents transaction replay attacks and ensures each transaction is processed only once. * **Control and Security**: * **Private Key**: A secret key used to sign transactions. The security of an EOA depends entirely on the secrecy of this key. If the private key is lost or compromised, access to the account and its assets is lost. * **Transactions**: To initiate a transaction, the owner must sign it with their private key. This transaction can involve sending Ether, interacting with smart contracts, or deploying new contracts. ## Limitations Externally Owned Accounts (EOAs) are a fundamental component of the Ethereum blockchain, controlled by private keys held by users. While EOAs have been crucial for the growth and operation of the Ethereum ecosystem, they come with significant limitations. These limitations arise from their inherent design and the constraints of the Ethereum Virtual Machine (EVM). Below is a detailed exploration of the primary limitations of EOAs: ### **Security Risks Due to Private Key Management** EOAs are entirely controlled by private keys. This control mechanism poses several security challenges: * **Single Point of Failure**: The security of an EOA is solely dependent on the security of the private key. If the private key is lost, stolen, or compromised, the user loses access to the account, and all assets held in it can be permanently lost. * **No Built-in Recovery Mechanism**: There is no native recovery mechanism for EOAs. Unlike traditional financial systems where lost passwords can be reset, losing a private key means irreversible loss of control over the account. * **Susceptibility to Phishing and Hacking**: Users must safeguard their private keys against phishing attacks, malware, and other forms of cyber threats. Since EOAs are often managed through software wallets, they can be vulnerable to these types of attacks. ### **Inflexible Transaction Mechanism** The EOA model has a rigid transaction mechanism, which includes: * **Fixed Signature Scheme**: EOAs use the Elliptic Curve Digital Signature Algorithm (ECDSA) for signing transactions. This fixed scheme limits flexibility, preventing the implementation of alternative signature algorithms or multi-signature setups within the EVM context. * **Single-Signer Requirement**: EOAs can only have one signer (the private key holder). This design limitation prevents the use of multiple signers for added security, such as requiring multiple approvals for high-value transactions. * **Direct Control Requirement**: The same private key used to control the account must sign every transaction. This requirement limits the ability to delegate certain permissions or use intermediary systems for transaction approvals. ### **Lack of Advanced Features and Custom Logic** EOAs are simple and lack programmability: * **No Custom Transaction Logic**: Unlike smart contract wallets, EOAs cannot include custom logic for transactions. For example, features like spending limits, time-locks, or whitelists cannot be natively implemented within EOAs. * **No Built-in Automation**: EOAs do not support automated actions based on predefined conditions. This limitation prevents the creation of automated systems like recurring payments or condition-based transfers without involving a separate smart contract. * **No Multicall Capability**: EOAs cannot bundle multiple transactions into a single atomic transaction. Each action requires a separate transaction, which can be inefficient and costly, especially for complex operations involving multiple steps. ### **Gas Payment Restrictions** EOAs face restrictions related to gas payment: * **Gas Fees Must Be Paid in ETH**: EOAs can only pay transaction fees using ETH. This restriction can be inconvenient for users who hold assets in other tokens and do not have sufficient ETH to cover gas fees. * **No Gas Fee Subsidization**: EOAs cannot natively implement mechanisms to subsidize gas fees, such as allowing dApps or third parties to cover the transaction costs on behalf of the user. ### **User Experience Challenges** The user experience with EOAs can be challenging, particularly for non-technical users: * **Complex Onboarding**: New users must understand the importance of securely managing private keys and the risks associated with losing them. This complexity can be a significant barrier to entry for mainstream adoption. * **No Social Recovery**: There is no built-in mechanism for social recovery, where a user's trusted contacts can help regain access to an account. This lack of recovery options increases the risk and anxiety for users managing their funds. * **Difficulties in Key Management**: Safely storing and managing private keys is a non-trivial task. Users need to be vigilant about backups, secure storage, and avoiding phishing attempts, which can be overwhelming. ### **Centralization Risks** The simplicity of EOAs can inadvertently lead to centralization risks: * **Custodial Services**: Due to the challenges associated with managing private keys, many users may prefer to use custodial services like centralized exchanges (CEXs) or custodians that manage the keys on their behalf. This shift can lead to centralization, where a few entities control large numbers of accounts, contradicting the decentralized ethos of blockchain. ### **Limited Interoperability with Advanced dApps** As decentralized applications (dApps) evolve, many require functionalities that EOAs cannot natively support: * **Incompatibility with Multi-Signature Requirements**: dApps requiring multisig security cannot natively integrate with EOAs without additional smart contracts. * **Lack of Support for Conditional Transactions**: Advanced dApps that rely on conditional transactions or complex state-dependent logic are not fully compatible with the simplistic design of EOAs. ## **Summary** While EOAs have been foundational to the development of the Ethereum ecosystem, their limitations in security, flexibility, and user experience present significant challenges. These limitations underscore the need for more advanced solutions, such as smart contract wallets, which offer enhanced features and greater flexibility. # Solana Solana is a high-performance blockchain designed for decentralized applications and crypto-currencies. Unlike Ethereum and many of the blockchains mentioned earlier, Solana does not natively support Externally Owned Accounts (EOAs) in the same way. Instead, Solana uses a different account model. ## Solana's Account Model **1. Account Structure** Solana accounts are more generalized than EOAs and are used to store data. Each account has a certain amount of space allocated to it and can store arbitrary data. Accounts are stateful objects that hold both data and the SOL balance. This model allows for greater flexibility in how accounts can be used. **2. Keypairs and Signers** In Solana, an account is controlled by a keypair (public and private key). The private key is used to sign transactions, while the public key serves as the account address. This concept is somewhat similar to EOAs but differs in the following ways: * **Multiple Signers**: Transactions can require multiple signatures from different keypairs, adding a layer of security. * **Program-derived Addresses (PDAs)**: These are addresses generated by programs (smart contracts) on the blockchain and can be used to manage accounts without requiring a private key. **3. Data Storage and Rent** Solana accounts store data, and maintaining an account incurs a rent fee, which is a small amount of SOL. If the rent is not paid, the account becomes inactive. **4. Transaction Model** Transactions on Solana are constructed differently from Ethereum: * **Instructions**: A transaction contains one or more instructions, each specifying a program (smart contract) to invoke. * **Accounts**: Each instruction specifies which accounts are involved and what data they need to access. * **Signers**: The transaction includes signatures from the necessary keypairs. #### Key Differences from EOAs * **Flexibility**: Solana accounts can store more complex data structures and interact with programs in more versatile ways than EOAs. * **Rent System**: Unlike EOAs, Solana accounts require rent to remain active, which can affect long-term storage costs. * **Multi-signature Support**: Solana natively supports transactions that require multiple signatures, enhancing security without needing additional smart contracts. * **Program Interaction**: Solana’s account model allows for more sophisticated interactions with programs, leveraging PDAs for managing permissions and data. ## Summary While Solana does not use EOAs in the traditional sense found in Ethereum and many EVM-compatible blockchains, it employs a flexible and powerful account model that supports keypairs, multi-signature transactions, and program-derived addresses. This model is designed to enhance scalability, performance, and security, making Solana suitable for high-performance decentralized applications. # TON The TON (The Open Network) blockchain is a high-performance, decentralized multi-blockchain system originally developed by Telegram and now maintained by the open-source community. It uses a unique architecture and account model that differs from the traditional EOAs (Externally Owned Accounts) found in Ethereum and similar blockchains. ## TON Blockchain's Account Model ### **Account Structure** TON's account model is somewhat similar to the UTXO model used by Bitcoin but also includes features more typical of account-based models: * **Account Contracts**: In TON, every account is essentially a smart contract. Even simple user accounts that just hold a balance of TON cryptocurrency (known as Toncoin) are represented by smart contracts. * **Address Structure**: Each account has a unique address, which can interact with the blockchain through the sending and receiving of messages. ### **State and Storage** * **Persistent State**: Unlike simple EOAs that just hold balances, accounts in TON have persistent state, which can include balances, code (for smart contracts), and other data. * **Smart Contracts**: Similar to Ethereum, TON allows accounts to run smart contracts, enabling complex logic and functionality. These smart contracts can manage multiple assets, execute conditional logic, and more. ### **Private Keys and Security** * **Control Mechanism**: Accounts in TON are controlled by private keys. The private key is required to sign transactions, providing security and control over the account. * **Key Management**: As with other blockchains, key management is crucial. Loss of a private key results in loss of access to the account and its assets. ## Comparison with EOAs ### **Account and Contract Integration** * Unlike EOAs, where the account and the contract are distinct entities, in TON, each account can inherently be a smart contract. This integration simplifies the management of both assets and logic within the same framework. ### **Scalability and Performance** * TON's sharding and multi-blockchain architecture provide a scalable solution capable of handling a high volume of transactions, surpassing the typical performance of networks relying on EOAs. ### **Advanced Features** * TON offers advanced features like instant hypercube routing and infinite sharding, which are not present in traditional EOA-based systems. ## Summary The TON blockchain presents a sophisticated and scalable account model that integrates smart contract functionality at the core level. Unlike the EOA model, where accounts are primarily balance holders and smart contracts are separate, TON accounts are inherently capable of complex operations, making the system highly versatile. Its unique architecture, combined with advanced features, positions TON as a powerful platform for decentralized applications, with the potential for high throughput and robust security. # Bitcoin Bitcoin, as the first and most well-known cryptocurrency, uses a unique system for managing ownership and transactions, distinct from the Externally Owned Accounts (EOAs) model used in Ethereum and similar blockchains. Bitcoin and its Layer 2 solutions have their own methods for managing private keys, transactions, and scaling. Here's a detailed look at how these systems work: ## **Bitcoin's Account Model** Bitcoin does not use accounts in the same way as Ethereum's EOAs. Instead, Bitcoin operates on a system called the Unspent Transaction Output (UTXO) model. ### **UTXO Model** * **Unspent Transaction Outputs (UTXOs)**: In Bitcoin, the fundamental unit of value transfer is the transaction, which consists of inputs and outputs. Outputs from previous transactions that have not been spent are called UTXOs. These UTXOs are what Bitcoin wallets track to determine a user's balance. * **Private Keys and Addresses**: Bitcoin users control their funds through private keys. Each private key can generate one or more public addresses, which are used to receive Bitcoin. The private key must sign any transaction spending Bitcoin associated with its addresses. ### **Key Management** * **Hierarchical Deterministic (HD) Wallets**: Most modern Bitcoin wallets use an HD wallet structure, allowing a single seed phrase to generate multiple private keys and addresses. This structure simplifies key management and backup. ### **Security and Recovery** * **Private Key Security**: Like EOAs, Bitcoin's security relies heavily on the private key's secrecy. If a private key is lost or compromised, the associated Bitcoin is irretrievably lost. * **Recovery Phrases**: HD wallets often provide a recovery phrase (seed phrase) that can regenerate the wallet and all associated addresses, providing a backup mechanism. ## **Limitations and Challenges** ### **Scalability and Usability** * **On-Chain Scalability**: Bitcoin's main blockchain has limited transaction throughput due to its block size and block time. Layer 2 solutions address this but introduce complexity and require user understanding of off-chain protocols. * **Complexity in Usage**: Layer 2 solutions like the Lightning Network require users to understand concepts like channel management, routing, and liquidity, which can be challenging for non-technical users. ### **Security Considerations** * **Custodial vs. Non-Custodial**: Lightning Network wallets can be custodial (where a service provider manages channels and funds) or non-custodial (where users have full control over their funds). Custodial solutions can be simpler but introduce trust issues. * **Off-Chain Risks**: While the Lightning Network offers speed and low fees, it also carries risks like channel exhaustion (where a channel runs out of funds) and potential routing failures. ## Summary Bitcoin's use of the UTXO model and the implementation of Layer 2 solutions like the Lightning Network and sidechains such as Liquid offer different approaches to scaling and usability compared to Ethereum's EOAs and smart contracts. While Bitcoin prioritizes security and decentralization, its account model and transaction mechanisms have inherent limitations in terms of flexibility and scalability. Layer 2 solutions aim to mitigate these issues, providing faster and cheaper transactions while maintaining the security of the main Bitcoin blockchain. # Smart Contract Wallets ## **What are Smart Contract Wallets?** Smart contract wallets are a revolutionary advancement in the realm of blockchain technology, offering enhanced security, flexibility, and usability over traditional Externally Owned Accounts (EOAs). Unlike EOAs, which are controlled by a private key, smart contract wallets are controlled by code deployed on the blockchain. ## **Ethereum Accounts Overview** Before diving into smart contract wallets, it is essential to understand the two types of accounts on the Ethereum blockchain: * **Externally Owned Accounts (EOAs)**: Controlled by private keys, EOAs are the most common type of Ethereum account. They are used to store and transfer ETH and tokens and interact with smart contracts. * **Contract Accounts (CAs)** or **Smart Contract Wallets**: These accounts are controlled by smart contracts rather than private keys. Transactions are executed based on the logic defined in the contract code. Both types of accounts have an Ethereum address and share three base properties: * **ETH Balance**: The amount of ETH available in the account. * **CodeHash**: A hash of the account's code stored on the Ethereum Virtual Machine (EVM). * **StorageRoot**: A data structure (Merkle Patricia trie) that tracks the account's data. ## **Smart Contract Wallet Structure** A smart contract wallet is essentially a smart contract that manages a user's funds and actions. Unlike EOAs, which require a private key for transaction authorization, smart contract wallets use code-based logic to define transaction rules and permissions. The key components include: * **Custom Logic**: Smart contract wallets can implement custom transaction rules, such as requiring multiple approvals (multisig), enabling social recovery, or setting spending limits. * **User Interaction**: Users interact with smart contract wallets through transactions that trigger the smart contract's functions. These interactions can be customized to suit various use cases. * **Gas Costs**: Deploying and interacting with smart contract wallets involves higher gas costs due to the execution of smart contract code on the blockchain. ## **Key Features and Functionalities** Smart contract wallets offer several advanced features that are not possible with EOAs: ### **Multisig Security** Multisig (multi-signature) wallets require multiple parties to sign a transaction before it can be executed. This provides an added layer of security, preventing unauthorized transactions even if one key is compromised. ### **Social Recovery** Social recovery allows users to recover access to their wallet through trusted individuals or "guardians." If a user loses their private key, they can regain access by getting approval from a pre-defined group of guardians. ### **Custom Transaction Logic** Smart contract wallets can define custom logic for transactions, such as time-locks, spending limits, or whitelisting specific addresses. This flexibility enables more sophisticated use cases, such as automated payments or conditional transactions. ### **Gas Payment Flexibility** Unlike EOAs, which require gas fees to be paid in ETH, smart contract wallets can be designed to support payment in other tokens or even subsidize gas fees through relayers. ### **Account Abstraction** Account abstraction (AA) separates the account's control from the user's private key, allowing smart contract wallets to act as both the account and the signer. This separation enables features like session keys and transaction batching. ## **The Role of ERC-4337** ERC-4337 is a standard that enhances the usability and functionality of smart contract wallets by introducing a more streamlined and robust framework. Key aspects include: * **UserOperations**: A new type of transaction that encapsulates all necessary information for a smart contract wallet operation, reducing complexity. * **Bundlers and Relayers**: Mechanisms that aggregate multiple UserOperations and submit them as a single transaction, improving efficiency and reducing gas costs. * **EntryPoint Contract**: A contract that processes UserOperations and ensures proper execution and compensation for relayers. ERC-4337 simplifies the development and deployment of smart contract wallets, making it easier for developers to create and customize wallets with minimal effort. ## **Advantages of Smart Contract Wallets** Smart contract wallets provide several advantages over traditional EOAs: * **Enhanced Security**: Multisig and social recovery mechanisms significantly reduce the risk of losing funds due to private key loss or theft. * **Flexibility and Customization**: Developers can implement a wide range of features and transaction rules, catering to specific use cases and user preferences. * **Improved User Experience**: Account abstraction and gas payment flexibility offer a more intuitive and user-friendly experience, especially for non-technical users. * **Scalability**: Smart contract wallets can be adapted to support new features and protocols, ensuring long-term relevance and utility. ## **The Future of Smart Contract Wallets** Lamina believes the adoption of smart contract wallets is expected to grow as blockchain technology evolves. Key trends and developments include: * **Protocol-Level Account Abstraction**: Platforms like Lamina integrating account abstraction at the protocol level will standardize smart contract wallets across the ecosystem, eliminating the need for EOAs. * **Mainstream Adoption**: As the usability and security of smart contract wallets improve, they have the potential to become the default wallet type for mainstream users, driving broader adoption of blockchain technology. ## **Summary** Smart contract wallets represent a significant advancement in the Web3 ecosystem, offering a more secure, flexible, and user-friendly alternative to traditional EOAs. As standards like ERC-4337 continue to evolve, and platforms like Lamina integrating smart contract wallets at the protocol level, we are poised to become a cornerstone of the blockchain user experience. Smart contract wallets will undoubtedly play a critical role in shaping the next generation of decentralized applications and services. Lamina stays at the forefront of this innovation by integrating smart contract wallets at the protocol level. The wallet provides a single point of interaction for various dApps across blockchains, simplifying the user experience and promoting interoperability. # Architecture
1. **Lamina Unified Frontend (Top Layer)**: * **Unified Dashboard**: A central panel displaying all assets, balances, transaction history, and options for blockchain interactions. * **dApp Browser**: An integrated browser for accessing and interacting with various decentralized applications across different blockchains. Users connect to the respective dApps through Lamina and wrap their intents into full smart contracts wallet user operations 2. **Lamina Universal Wallet Account (Middle Layer)**: * **Account Management Module**: * Handles the creation and management of smart contract wallets for different blockchains. * Supports UTXO-based blockchains (like Bitcoin), account/balance model blockchains (like Ethereum) and hybrid blockchains (like Solana, TON). * **Security Module**: * Implements security features such as multi-signature, two-factor authentication, and social recovery. * **Transaction Processing Module**: * Manages the creation, signing, and broadcasting of transactions. * Ensures transactions are correctly formatted for the specific blockchain. 3. **Blockchain Connectors (Integration Layer)**: * **UTXO Model Connector**: * Connects to UTXO-based blockchains (e.g., Bitcoin, Dogecoin) for managing UTXOs and transactions. * **Account/Balance Model Connector**: * Connects to account/balance model blockchains (e.g., Ethereum plus other EVM chains) for managing balances, token transfers, and smart contract interactions. * **Hybrid Model Connector**: * Supports blockchains with custom models (e.g., Solana, TON) and facilitates unique transaction formats and state management. 4. **Cross-Chain Interoperability Layer (Crosschain API)**: * Manages cross-chain swaps, lending, borrowing, staking, restaking and asset transfers. * Facilitates cross-chain asset management through the Lamina solver network. * Deterministic payout resolution through Hyperlane, borrowing both their AVS infrastructure and easy to deploy nodes. 5. **Backend Services (Bottom Layer)**: * **Node Management**: * Maintains connections to blockchain nodes for real-time data access and transaction broadcasting. * **Data Storage**: * Securely stores user data, wallet configurations, and transaction history. 6. **Security Infrastructure**: * **Encryption**: * Provides secure storage for sensitive data using advanced encryption techniques. * **Hardware Wallet Integration**: * Supports integration with hardware wallets (e.g., Ledger, Trezor) for enhanced security. * **Realtime Monitoring** * Lamina integrates the latest in real-time monitoring from Hypernative, enabling 24/7 risk anal to protect liquidity providers and users from malicious transactions and attacks. 7. **APIs and SDK**: * Provides APIs and SDKs for developers to integrate Lamina's features into other applications to enable interoperability and access users and liquidity across all blockchains. # Crosschain System Overview Architecture & Components *** ## Lamina's Multilayered Infrastructure This document is a high-level system overview of Lamina Finance's infrastructure components; and will briefly discuss each component's purpose, function, and usage. Our proprietary infrastructure leverages a network of solvers that compete to fill intents across EVM, SVM, TONVM, MoveVM and BTC blockchains.\ \ Solvers in the Lamina network execute transactions on the destination chain from the signer's smart contract wallet, covering the execution, validation, and gas costs. Then the **Lamina** crosschain paymaster deterministically repays the solver from the signer's locked funds on their own escrow contract. Through this system the execution is atomic and entirely P2P (user-solver). ## Component: Crosschain API - Protocol interaction

Figure 1a Crosschain API and Protocol API interaction

Figure 1b Crosschain API - Protocol API callgraph

*Figure 1a* shows how our Lamina protocol (Protocol API) interacts with our Crosschain API and how other protocols could integrate with our Crosschain API. Protocols include actors such as bridges, liquidity aggregators, price matching aggregators, and multi-chain marketplaces. The components in this interaction can be generalized as the *Crosschain API* and the *Protocol API*. The *Protocol API* composes transaction calldata to be executed as well as specifies the target, target chain, signer, and execution cost requirements. The *Protocol API* will have the user sign and submit data from *Crosschain API*. *Crosschain API* runs a simulation on would-be transactions. The results of this simulation will estimate the cost for validation, execution, suggested bid, and base gas fee. *Crosschain API* will return, the sum total of these costs, a request for the signer to lock funds and a userop. Once signed and submitted to *Crosschain API*, the lock request and userop will be validated and added to the *Crosschain Mempool*. *** ## Client Validation: Crosschain API - Client Interaction

Figure 2a Crosschain Client validates message to add to Crosschain Mempool

Figure 2b Crosschain Client callgraph

*Figure 2a* shows the process by which the *Crosschain Client* ensures funds are locked and the userop is signed. Similar to ERC4337 bundlers, the userop needs to be validated by the client before merging the message into the mempool. However, there are two key differences: (1) the lock request needs to be executed on an RPC for the origin chain and then validated; and (2) the transaction simulation is validated in an environment where the execution cost and paymaster calls are executed as pre-userop. The *Crosschain Client* validates the userop in the context of a solver fronting the *Hyperlane* costs to the *Crosschain Paymaster* and to the *SCW*. After the *Crosschain Client* finishes validating the lock amount, lock deadline, and userop, the full message including lock info, calldata, and execution cost will be merged to the *Crosschain Mempool*. *** ## Solver Execution: Crosschain Mempool - Solver Interaction

Figure 3a Solver finds a message on the Crosschain Mempool and executes it on-chain

Figure 3b Solver - Paymaster callgraph

Figure 3a shows how a *Solver* who joins the **Lamina** solver network executes a message from the Crosschain Mempool. {% hint style="info" %} *Note*: *validation for merging a message to the Crosschain Mempool does not ensure a successful userop bundle at execution time, therefore it is expected that the Solver re-validates the userop bundle before execution.* {% endhint %} The *Solver* acts as liquidity provider directly for the signer. The operation is executed atomically as a three part bundle, in order : (1) overpaying *Crosschain Paymaster* to execute on *Hyperlane*; (2) add execution cost + validation gas + execution gas to the signer's smart contract wallet (*SCW*); and (3) the signer's signed userop. Because the bundle is executed atomically, the *Crosschain Paymaster* call to *Hyperlane* is entirely deterministic. *** ## Deterministic Crosschain: Crosschain Paymaster - Hyperlane Network

Figure 4a Crosschain Paymaster deterministically executes the solver payout across Hyperlane

Figure 4b Crosschain Paymaster - Hyperlane callgraph

Figure 4a shows the *Crosschain Paymaster* and how it utilizes *Hyperlane*. The preOp and postOp utilize the overpaid funds to ensure the *Hyperlane* message including userop and tx.origin data is successfully submitted to the *Hyperlane Mailbox*. At the end of the postOp the *Crosschain Paymaster* will redeposit stake used to the *EntryPoint* and send any residual ETH to the tx.origin. Once the message is confirmed on the *Hyperlane Network*, a *Hyperlane Validator* will pickup and execute the message on the *Hyperlane Mailbox* to directly execute the handle function on the signer's *Escrow* contract. *** ## Escrow Resolution: Hyperlane - Escrow Payout Validation

Figure 5a The user's escrow handles the Hyperlane message to payout the solver.

Figure 5b User Escrow - Solver payout callgraph

Figure 5a shows how *Hyperlane Mailbox* executes the handle function on the signer *Escrow* contract. The *Escrow* will validate the hashed data and payout funds to the solver. The payment includes the estimated user costs + the signer original bid. # Glossary ### Crosschain **Crosschain API** - Lamina’s forward-facing API interface. Protocols talk to the Crosschain API by sending transaction calldata and target information (chain, address, cost). Crosschain does the heavy lifting on the backend, wrapping userops and calculating the overall transaction cost, then returns data for the protocol to sign before forwarding said signed data as a blob to the Crosschain Client. ```go // UserOp Operation Structure: type UserOperation struct { Sender string `json:"sender"` Nonce string `json:"nonce"` InitCode string `json:"initCode"` CallData string `json:"callData"` CallGasLimit string `json:"callGasLimit"` VerificationGasLimit string `json:"verificationGasLimit"` PreVerificationGas string `json:"preVerificationGas"` MaxFeePerGas string `json:"maxFeePerGas"` MaxPritorityFeePerGas string `json:"maxPriorityFeePerGas"` PaymasterAndData string `json:"paymasterAndData"` Signature string `json:"signature"` } // Execution Data Structure: type ExecutionData struct { DestinationChain string `json:"destinationChain"` TargetAddress string `json:"targetAddress"` Asset string `json:"asset"` Amount string `json:"amount"` Calldata string `json:"calldata"` } // Protocol's Request Transaction Format: type RequestTransaction struct { Signer string `json:"signer"` ExecutionRequest ExecutionData `json:"executionRequest"` } // Protocol's Request Transaction Response // (calldata and userop are to be signed): type RequestTransactionResponse struct { Signer string `json:"signer"` Escrow string `json:"escrow"` Deadline string `json:"deadline"` Calldata string `json:"calldata"` UserOp UserOperation `json:"userop"` } // Protocol's Signed Format: type SubmitTransaction struct { Signer string `json:"signer"` Escrow string `json:"escrow"` Deadline string `json:"deadline"` Calldata string `json:"calldata"` Signature string `json:"signature"` Hash string `json:"hash"` UserOp UserOperation `json:"userop"` } ``` **Crosschain Client** - Lamina's backend infrastructure responsible for lock request execution and userop validation. This client currently comprises of a private bundler and relayer but is expected to scale by offering a reward-based model to bring new bundlers and relayers into the fold. **Crosschain Mempool** - Lamina’s Crosschain Mempool is a currently a private mempool with custom blobs of data. These blobs include a proposed bid, execution cost, and userop. Solvers digest these blobs and execute an array of userops on the destination chain’s ERC4337 EntryPoint contract. ```go type ExecutableBlob struct { ExecutionRequest ExecutionData `json:"execution"` UserOp UserOperation `json:"userop"` } ``` **Crosschain Paymaster** - Lamina's userop paymaster. During preOp the paymaster validates the userop and digests the paymasterAndData field. Then constructs the Hyperlane message for later authentication on the origin chain. Extra data from the paymasterAndData field will be appended with the Solver's address. During postOp the paymaster will pay for the Hyperlane IGP and redeposit used funds to it's own stake and send residual funds back to the Solver. ```solidity // PaymasterAndData Field (generated by Crosschain API): struct PaymasterAndData { address paymaster; address owner; uint256 chainId; address asset; uint256 amount; } // preOp execution: function _validatePaymasterUserOp( UserOperation calldata userOp, bytes32, uint256 requiredPreFund ) internal override returns (bytes memory context, uint256 validationResult) { unchecked { bytes calldata data = userOp.paymasterAndData; uint256 paymasterAndDataLength = data.length; // 124 == crosschain non-payable if (paymasterAndDataLength != 124 && paymasterAndDataLength != 176) { revert InvalidDataLength(paymasterAndDataLength); } address paymaster_ = address(bytes20(data[:20])); address owner_ = address(bytes20(data[20:40])); uint256 chainId_ = uint256(bytes32(data[40:72])); address paymentAsset_ = address(bytes20(data[72:92])); uint256 paymentAmount_ = uint256(bytes32(data[92:124])); bytes32 messageId_; uint256 gasAmount_ = 100000; uint32 destinationDomain_ = uint32(chainId_); if (!acceptedChain[destinationDomain_]) { revert InvalidChainId(destinationDomain_); } // enabled only for MVP; tbh we don't care about the assets used, network is P2P if (!acceptedAsset[destinationDomain_][paymentAsset_]) { revert InvalidAsset(destinationDomain_, paymentAsset_); } // withdraw funds for oracle call to paymaster // nope, let it fail if the paymaster has insufficent funds, solver should know better // entryPoint.withdrawTo(payable(address(this)), 0.1 ether); // the bundler/ solver that submits the tx from the uomempool // in reality we don't care who executes, but they are burdened with refinding the paymaster and tx cost address receiver = tx.origin; bytes32 recipientAddress_ = bytes32(uint256(uint160(receiver))); IMailbox(hyperlane_mailbox).dispatch( destinationDomain_, recipientAddress_, abi.encode(userOp, receiver) ); uint256 igpQuote_ = IIGP(hyperlane_igp).quoteGasPayment( destinationDomain_, gasAmount_ ); context = abi.encode( receiver, messageId_, destinationDomain_, gasAmount_, igpQuote_ ); } } // postOp refund function _postOp( PostOpMode mode, bytes calldata context, uint256 actualGasCost ) internal override { // don't care about the mode, solver fronts the gas (mode); bytes32 messageId_; uint32 destinationDomain_; uint256 gasAmount_; uint256 igpQuote_; address refundAddress_; ( refundAddress_, messageId_, destinationDomain_, gasAmount_, igpQuote_ ) = abi.decode(context, (address, bytes32, uint32, uint256, uint256)); IIGP(hyperlane_igp).payForGas{value: address(this).balance}( messageId_, destinationDomain_, gasAmount_, address(this) ); entryPoint{ value: gasAmount_ }.addStake(0); // shouldn't revert, but doesn't matter payable(refundAddress_).call{ value: address(this).balance }(""); } ``` *** #### Hyperlane Hyperlane Mailbox - The mailbox, for Hyperlane messages, acts as either the receiver contract on destination chains, or the sender contract on origin chains. Hyperlane messages transmitted or received include: target chain, target address, value, and message. When a valid message received on the origin chain it will be added to the Hyperlane network with a pending state until payment is accepted by the Hyperlane IGP. When a valid message is received on the destination chain it will use the message data to call the target contract. **Learn more** [**here**](https://docs.hyperlane.xyz/docs/reference/messaging/messaging-interface). **Hyperlane IGP (Interchain Gas Paymaster)** - The gas paymaster estimates this native currency cost required to process the submitted Hyperlane message. The gas requirements must be quoted after the Hyperlane message is submitted. Crosschain Paymaster quotes the cost of a Hyperlane message during preOp and submits payment during postOp. This approach ensures that the Hyperlane message is triggered only if the userop is executed successfully. **Learn more** [**here**](https://docs.hyperlane.xyz/docs/reference/hooks/interchain-gas)**.** **Hyperlane Validator** - The Hyperlane network on any chain includes a series of validators that process transactions on destination chains. **Learn more** [**here**](https://docs.hyperlane.xyz/docs/operate/validators/run-validators). **Hyperlane Handler** - The handle function on the target contract accepting a message from the Hyperlane Mailbox on the destination chain. **Learn more** [**here**](https://docs.hyperlane.xyz/docs/reference/messaging/receive)**.** *** #### Escrow **Escrow** - Every signer has a create2 escrow address. The Escrow is a lightweight ERC1967 proxy that supports tracking of any lock or unlocked token. Only the signers locked funds are used for paying solvers. When receiving a Hyperlane message to handle it will validate and then execute the Solver payout. **Escrow Factory** - Factory contract for initializing a signer’s ERC1967 Escrow. Copy ```solidity // ERC1967 Escrow Initialization function createEscrow(bytes memory _initializer, bytes32 _salt) external returns (address proxy) { bytes memory deploymentData = abi.encodePacked(type(EscrowProxy).creationCode, _ESCROWIMPL); bytes32 salt = _calcSalt(_initializer, _salt); assembly ("memory-safe") { proxy := create2(0x0, add(deploymentData, 0x20), mload(deploymentData), salt) } if (proxy == address(0)) { revert(); } assembly ("memory-safe") { let succ := call(gas(), proxy, 0, add(_initializer, 0x20), mload(_initializer), 0, 0) if eq(succ, 0) { revert(0, 0) } } return proxy; } ``` **Escrow Simpleton** - Escrow current logic contract deployment. # Solvers A solver is a computer algorithm that takes the orderbook as input and calculates the optimal prices and traded amounts for all orders and liquidity sources (such as AMMs), ensuring the best overall trading experience. In our context, solvers are actors that find blobs of data in the Crosschain mempool and execute them in bundles. When executing these bundles the solver is required to have three userops submitted in order: 1. Send funds to the Lamina Crosschain Paymaster to execute any crosschain calls 2. Send funds to the signer's smart contract wallet (SCW) to execute the signer's userop 3. Execute the signer's userop Blob data format: ```go // UserOp Operation Structure: type UserOperation struct { Sender string `json:"sender"` Nonce string `json:"nonce"` InitCode string `json:"initCode"` CallData string `json:"callData"` CallGasLimit string `json:"callGasLimit"` VerificationGasLimit string `json:"verificationGasLimit"` PreVerificationGas string `json:"preVerificationGas"` MaxFeePerGas string `json:"maxFeePerGas"` MaxPritorityFeePerGas string `json:"maxPriorityFeePerGas"` PaymasterAndData string `json:"paymasterAndData"` Signature string `json:"signature"` } // Execution Data Structure: type ExecutionData struct { DestinationChain string `json:"destinationChain"` TargetAddress string `json:"targetAddress"` Asset string `json:"asset"` Amount string `json:"amount"` Calldata string `json:"calldata"` } // Executable Blob type ExecutableBlob struct { ExecutionRequest ExecutionData `json:"execution"` UserOp UserOperation `json:"userop"` } ``` *** ## Becoming a solver In Lamina, anyone can be a solver. \ \ Sophisticated and tech-savvy solver teams with their own proprietary solver algorithm can join our solver network by integrating their solvers post testing in a risk-free environment. To join Lamina's solver network please fill out the following [form](https://forms.gle/8cdzWD2pWJmFMECaA).\ \ For the less tech-savvy, you can just commit liquidity to our solver network without having to develop your own algorithms and start earning rewards.
# Cryptography Lamina's crosschain architecture facilitates operations on various blockchains' virtual machines. Each virtual machine has tradeoffs, inter alia each have their own best-suited signature algorithms. As such, forcing all chains to share the same signature algorithm is reductive for both a gas overhead costs and wallet exclusion. Instead we make use of the best security practices on all chains, this means we can accept any signature type/size, and thus accept any wallet. ## Signature Types #### Type-1 Signatures – ECDSA ECDSA, or elliptic curve digital signature algorithm, is the standard public-private key signature architecture used by Ethereum/Bitcoin wallets. Takes 32-byte hash as uint256 `hash`; 65-byte signature as uint8 `v` and uint256 `r`, `s`.\ Returns `0` on failure, public key and `-1` on success.\ 65-byte public key is returned as uint8 `h`, uint256 `x1`, `x2`. #### Type-2 Signature – SECP256K1 SECP256K1, or Standards for Efficient Cryptography Prime-256 K1, is one key signature architecture used by TON. This signature curve algorithm allows for ECDSA compatibility by allowing users to use the same 256 bit private key. #### Type-3 Signature – SECP256R1 SECP256K1, or Standards for Efficient Cryptography Prime-256 R1, is another key signature architecture used by TON. This signature type enables Apple OpenSSL signing which helps abstract away superfluous action away from the user blockchain experiences. This key is normally 33 bytes but for cases like TON there are comparability assembler commands to sign under a 32 bytes scheme (`P256_CHKSIGNU` instead of `P256_CHKSIGNS`). #### Type-4 Signature – EDDSA EDDSA, or Edwards-curve Digital Signature algorithm, is a signature proof borrowing elements from ED25519 and ECDSA and is the key signature architecture used by Solana. *** The signature type will be appended to our domain header along with info on blockchain chain ID. Our API expects the structure will be of the format rlp\[chainId, opId, sigType, sigHash, packedUserOp]. #### ERC-4337 (AA) Hashing and Signatures In all signature methods for packedUserOp, the hashed data is signed by the signer private key, yielding a hash and signature pair. ```solidity struct PackedUserOperation { address sender; uint256 nonce; bytes initCode; bytes callData; bytes32 accountGasLimits; uint256 preVerificationGas; bytes32 gasFees; bytes paymasterAndData; bytes signature; } ``` ERC-4337 generates a domain specific hash utilizing the data on the EntryPoint contract. ```solidity function getUserOpHash( PackedUserOperation calldata userOp ) public view returns (bytes32) { return keccak256(abi.encode(userOp.hash(), address(this), block.chainid)); } function hash( PackedUserOperation calldata userOp ) internal pure returns (bytes32) { return keccak256(encode(userOp)); } function encode( PackedUserOperation calldata userOp ) internal pure returns (bytes memory ret) { address sender = getSender(userOp); uint256 nonce = userOp.nonce; bytes32 hashInitCode = calldataKeccak(userOp.initCode); bytes32 hashCallData = calldataKeccak(userOp.callData); bytes32 accountGasLimits = userOp.accountGasLimits; uint256 preVerificationGas = userOp.preVerificationGas; bytes32 gasFees = userOp.gasFees; bytes32 hashPaymasterAndData = calldataKeccak(userOp.paymasterAndData); return abi.encode( sender, nonce, hashInitCode, hashCallData, accountGasLimits, preVerificationGas, gasFees, hashPaymasterAndData ); } ``` In the above hashing method we are able to calculate on chain from the userOp: ``` sha3( rlp[ sha3( rlp[ sender.nonce .sha3(initCode) .sha3(callData) .accountGasLimit .preVerificationGas .gasFees .sha3(paymasterAndData) ] ) .EntryPoint .chainId ] ) ``` Naturally the signature is not hashed in the packedUserOp, so how can we pass the data? We are able to store additional information in any byte field outside the range of the specified byte length value. ```solidity struct PackedPaymasterAndData { address paymaster; uint256 packedGas; address owner; uint256 destinationId; address asset; uint256 amount; uint8 sigType; } struct PaymasterAndData2 { address paymaster; uint128 paymasterVerificationGasLimit; uint128 paymasterPostOpGasLimit; address owner; uint256 destinationId; address paymentAsset; uint256 paymentAmount; address transferAsset; uint256 transferAmount; uint8 sigType; } ``` In both our type-1 and type-2 paymasterAndData objects it can be seen we have a uint8 value sigType, or signature type. The signature type, like the packedUserOp signature field, is not used for the calculated userOp hash or paymasterAndData signature. Instead, we make use of extra bytes. The sigType specifies the signature data length. The paymasterAndData hash is: ``` sha3( rlp[ paymaster .owner .destinationId .paymentAsset .paymentAmount .transferAsset .transferAmount .sigType ] ) ``` Since the signature object of the packedUserOp is the last dynamic memory object of the userOp object, any data after the length of the signature field will not be read into an object. But to our benefit this data is still accessible. This allows us to limit the required validation data crosschain, since we do not need the full userOp validation on the target chain but require the payment to validated. This remains deterministic still since the called Escrow must also validate the crosschain sender origin, chainId, and crosschainHandler. # Account Abstraction Account abstraction (AA), or more formally known as ERC-4337 in the EVM ecosystem, is the means of execution on the blockchain through smart contract wallet. This wallet's signature validation and execution flow differs depending on the chain's architecture. In general, the user-signed userop are added to to a dedicated mempool and executed on-chain by solvers. ## Ethereum Virtual Machine (EVM) Lamina base uses a simple account wallet provided by eth-infinitism's ERC-4337 repo. Lamina has also been tested and has proven compatibility with other smart contract wallet schema such as Banana Wallet, Soul Wallet, SAFE, Forum Wallet, and others. aour analysis showed the most gas efficient design for Lamina base user operations was semi or full custodial smart contract wallets deployed with a ERC-1967 proxy. The key difference between AA wallets regarding execution are plugin/hooks/preOp/postOp calls, paymaster integration, function selectors, and initialization code (initCode). This means the protocol API does the heavy lifting to route the user's calldata and wrap it to be executed on the respective AA wallet. Plugins/hooks/preOps/postOps calls are operations that executes similarly to of a solidity modifier on the smart contract level. These can execute before the body code of userOp callData or afterwards. Lamina route it's hooks in the most compatible way. These operations can be embedded on the smart contract level or can be the AA wallet calling a multicall that calls preOp/postOp calls around the primary call target. The later is preferred since we can use 100% of the existing architecture or ERC-4337 EntryPoint. *** ## TON Virtual Machine (TVM) Through our research we have found that TVM operates transactional operations non-atomically. This differs from the EVM and SVM architectures. But why does this matter? Normally to call crosschain we use a callback executed after the execution of the userops calldata execution on the smart contract wallet. Since we can not do this we need to be creative with both our smart contracts and infrastructure. \ \ The current transaction structure is a 267 bit domain, 124 bit nonce, 256 bit hash, dynamic calldata, and 65 bytes signature. ```c cell slice1 = begin_cell() .store_uint(domain, 256) ;; upper 267 .store_uint(escrow_tx_id, 256) ;; lower 267 . 124 bit .store_uint(user_op_hash, 256) .end_cell(); ``` 1. The solver executes the transaction on the EntryPoint contract, for now only a simple whitelist for solvers. 2. The EntryPoint then calls the smart wallet proxy, which will validate the transaction and then execute. 3. Once the transaction completes execution on a future block the state of the relevant contracts will be tested for the correct new values within acceptable range, then call the EntryPoint to execute a callback call on the PayMaster contract. 4. Our backend listens to and digests messages to this contract to call crosschain to our other supported blockchains. 5. The solver will then get paid out as normal # Security Our architecture incorporates robust validations, ensuring security and integrity. As solvers commit liquidity on each chain, we don't have liquidity pool contracts on each chain. This eliminate risks associated with LP exploits and is more capital efficient. Furthermore, our built-in real-time monitoring solutions provide a secure environment, making it the safest option for retail traders, LPs, and institutions to transact on-chain. These measures collectively foster trust and reliability within our network. Retail traders benefit from seamless and secure transactions, while liquidity providers enjoy peace of mind knowing their assets are protected. Institutions, with their stringent security requirements, can transact with confidence, ensuring compliance and safeguarding their interests at all times. ### How is this secure for LPs? On Lamina, there are no liquidity pools, this way we are not susceptible to LP exploits. This is also better from a capital efficiency perspective. Users and LPs can commit liquidity to our cross-chain solver network which has built-in realtime monitoring solutions that prevent malicious solvers from participating in the network. # Use Cases ## How can protocols integrate with Lamina? Lamina's key use cases are geared towards protocols involving orderflow aggregation, liquidity (DEX) aggregation, bridging, crosschain liquidity, multichain marketplaces etc. ### Bridging Bridging is a daunting and potentially dangerous endeavor for protocols and end-users. Since our execution flow is funded by our solver layer, they are the liquidity provider for native execution. After completing execution of the users transaction, the solver is deterministically paid out of the users lock. This completely circumvents any traditional bridging layer. For Lamina the risk is not for the end-users, since our execution flow is validated to be in a canonical order flow, rather the solver. It is theorized that the solvers in our network are potentially vulnerable to reorgs and thus the MEV from bids in their userop bundle execution could potentially be stolen. How can a protocol (or user) create a bridge request using Lamina? ``` // Execution orderflow of the Bridge is transfer of asset(s) from the signers SCW to the users EOA address // Below is the exact bytecode submitted to the Lamina Crosschain API for a bridge request of native assets 0xb61d27f6000000000000000000000000[target][amount]0000000000000000000000000000000000000000000000000000000000000000000600000000000000000000000000000000000000000000000000000000000000000 ``` The Crosschain API call request can be referenced [here](/technology/crosschain-system-overview). ### Native Execution (Multi-Chain Execution/Marketplaces) Normally protocols require multiple deployments to have a market presence on different blockchains. Lamina allows for native execution using the solvers. Protocols like Magic Eden and OpenSea operate on multiple chains (OpenSea is particular operates on 10 chains). To interact on a new chain, their infrastructure needs to be redeployed on new chains (not including modification to their backend, which is also required). By deliberately executing through Lamina for new chains, users can execute natively using existing infrastructure while users utilize funds from any chain. This execution is seamless to the user. From the users prospective, they are executing on their native chain, but in-fact will execute on the protocols selected native chain. ### Crosschain Liquidity Crosschain liquidity is maintained through warp routes and is fragmented across chains. Warp routes burn tokens on the native chain to supply tokens (or synthetic assets) on the target chain (see [OHM](https://docs.olympusdao.finance/main/overview/cross-chain)). This is an inefficient use of liquidity. Liquidity can be concentrated on a single chain using Lamina. ### Crosschain Execution DEX aggregators like Sushiswap unify liquidity across multiple DEX. With Lamina this system is extendable to liquidity across multiple chains, while maintaining the same atomic execution. Orderflow aggregator like CowSwap can expand price matching to more chains. For chains connected to obscure bridges like Wanchain but have active liquidity of CEXs, Lamina enables instant atomic P2P bridging without the use of a bridge. Marketplaces like Magic Eden and OpenSea operate on multiple blockchains but require more resources to port over to new chains. Lamina allows their users on new chains to use liquidity from new chains. # Lamina SDK ## **Overview** The Lamina SDK provides developers with a suite of tools to integrate their applications with Lamina's decentralized execution and liquidity network. By leveraging the SDK, developers can enable native cross-chain functionalities, streamline liquidity management, and access Lamina's solver network for efficient, atomic transactions. This documentation covers the architecture, key components, and usage examples for the SDK, empowering developers to build robust, multi-chain applications. ## **Key Features** 1. **Cross-Chain Execution**: Execute transactions across multiple blockchains without redeploying infrastructure. 2. **Unified Liquidity Access**: Aggregate liquidity from multiple DEXs and CEXs across different chains. 3. **Atomic Transactions**: Ensure atomic execution of transactions, providing security and reliability. 4. **P2P Bridging**: Enable peer-to-peer bridging without relying on traditional bridge infrastructure. 5. **SDK Integration**: Easy-to-use interfaces and comprehensive documentation for seamless integration. ## **SDK Components** 1. **Core Library** * Provides the primary interfaces and functions for interacting with Lamina's network. * Handles cross-chain communication and transaction execution. 2. **Liquidity Module** * Facilitates access to liquidity across multiple chains. * Includes functions for liquidity aggregation and management. 3. **Order Matching Module** * Extends functionalities for orderflow aggregators, enabling cross-chain price matching. * Integrates with various DEXs and CEXs to find optimal prices. 4. **P2P Bridging Module** * Enables instant, atomic peer-to-peer bridging between different blockchains. * Supports obscure bridges and enables liquidity utilization from CEXs. 5. **SDK Utilities** * Helper functions for transaction signing, gas estimation, and more. * Includes monitoring and logging tools for tracking and debugging. ## **Installation** {% hint style="info" %} We are whitelisting a limited number of developers to access the SDK while its under development. Please contact the Lamina team if you would like access. {% endhint %} For whitelisted accounts, the Lamina SDK can be installed via npm for JavaScript/TypeScript projects. Other language support is available through separate packages. ```bash npm install lamina-sdk ``` ## **Initialization** To use the SDK, initialize it with your project's credentials and configuration options. ```javascript const Lamina = require('lamina-sdk'); const lamina = new Lamina({ apiKey: 'your-api-key', network: 'mainnet', // or 'testnet' defaultChain: 'ethereum', }); ``` ## **Best Practices** * **Security**: Always keep your API keys and private keys secure. Use environment variables to manage sensitive information. * **Error Handling**: Implement comprehensive error handling for all SDK functions to ensure robustness. * **Testing**: Thoroughly test your integration on a testnet before deploying to mainnet. ## **Summary** The Lamina SDK provides a powerful and flexible framework for building multi-chain applications. By leveraging the SDK, developers can simplify their infrastructure, access liquidity from multiple chains, and ensure secure, atomic transactions. For further assistance, contact our support team.