Unveiling Solana Signature SDK: Enabling Solana Users to Access EVM dApps

The Solana Signature SDK is a developer-centric toolkit designed to integrate Solana wallets—such as Phantom, Backpack, and Solflare—into Ethereum-compatible dApps deployed on Solana via Neon EVM.

Key Takeaways:

• Unified user experience: Use Solana-compatible wallets and transaction signing with Ethereum-compatible dApps.
• Technical innovation: Support Solana-native ed25519 signatures for Ethereum transactions via on-chain signature verification.
• Simplified development: Rapid integration of wallets and transaction management through SDK, enabling setup and functionality within minutes.
• Lifecycle transparency: Detailed overview of transaction flow from wallet to execution on Neon EVM.
• Advanced features: Support for Solana program calls, ERC20-SPL asset management, and transaction scheduling.

With the release of the Solana Signature Wallet SDK, we take an important transformative step toward enabling Solana-native integration and simplifying user interactions on the Solana environment for Ethereum-compatible dApps, as is highlighted in our whitepaper.

Introduction to Neon EVM and Wallet Integration

The Solana Signature Wallet SDK toolkit enables developers to build dApps that allow Solana users to interact with smart contracts deployed on Neon EVM. Ethereum-compatible dApps have historically depended on Ethereum-like signatures (secp256k1) for transaction authentication. This dependency has created obstacles for Solana users, requiring them to use additional tools like MetaMask and engage in complex liquidity transfers. The Solana Signature Wallet SDK together with Neon Proxy, resolves this. By matching Solana’s ed25519 signature scheme and Ethereum’s transaction requirements, this SDK simplifies wallet integration and asset accessibility across ecosystems.

At its core, this SDK simplifies transaction management as follows:

1. Creation of EVM transactions within Solana wallets.
   
2. Packaging and submitting transactions via Neon EVM’s on-chain mempool
   
3. Execution and state management through Neon Proxy
   
4. State updates on both Neon and Solana.

By abstracting the complexity of transaction conversion and enhancing compatibility between the two networks, it allows developers to focus on building and interacting with decentralized applications (dApps) without worrying about underlying infrastructural hurdles.

Let’s dive into the details, technical overview, token management flow, benefits, limitations, and future prospects.

Detailed Overview of Solana Signature Wallet SDK

The Neon EVM Solana Signature Wallet SDK is a modular and flexible solution designed to benefit both developers and users.

Benefits:

For users

• Streamlined experience: Use existing Solana wallets to interact with Ethereum-compatible dApps.
• Reduced complexity: No need for additional wallets or intricate liquidity transfers.

For developers

• Quick integration: Simplify wallet connections and transaction workflows with comprehensive SDK tools.
• Ecosystem compatibility: Build dApps catering to both Solana and Ethereum users without extra development overhead.

Solana Signature Validation: Functionality

A standout feature of the Neon EVM Solana Signature Wallet SDK is its ability to validate Solana transactions using Solana’s ed25519 signature system. This enhancement is crucial for ensuring that transactions initiated via Solana wallets—such as Phantom, Solflare, and Backpack—are processed accurately and securely on the Neon EVM network.

The validation process occurs in real-time within the Neon Proxy, which checks the authenticity of Solana signatures before executing any transaction on the Neon EVM. By validating Solana’s ed25519 signatures natively, the Neon Proxy eliminates the need for manual signature verification or the use of intermediary layers. This means transactions are securely processed with minimal delay, ensuring that every transaction is authenticated and recorded properly.

This real-time validation mechanism is integral to enabling Solana wallet users to interact directly with Ethereum-compatible dApps deployed on Neon EVM without needing separate authentication methods or additional tools like MetaMask.

For the SDK, to ensure a smooth user experience, two key focus areas include:

• Technical functionality via Neon Proxy, and;
• Asset management with ERC20ForSPL management for token transfers between the Ethereum and Solana networks.

Read on to see how Neon Proxy supports this and how the ERC20ForSPL contract manages token balances and transfers between Solana and an Ethereum-compatible environment.

Neon Proxy Changes: Enhancing Infrastructure Capabilities

Neon Proxy is pivotal for facilitating interactions. It packs Ethereum-like transactions into Solana transactions, removing the burden of implementing conversion logic. Recent updates to the proxy architecture introduce new functionalities, optimize transaction handling, and ensure compatibility with existing systems while incorporating Solana-signature infra.

Key Proxy Enhancements for Solana Signature SDK

• Solana Signature Validation:The Neon Proxy now validates Solana's ed25519 signatures, enabling Solana wallets (Phantom, Backpack, Solflare and others) to sign and submit transactions directly to Neon EVM. This eliminates intermediary layers, streamlining the process and ensuring security.

• On-Chain mempool Integration: With on-chain mempool support, Solana wallet transactions are stored, validated, and executed transparently and efficiently within the Neon EVM ecosystem. This improvement enhances scalability and removes reliance on off-chain operations for transaction scheduling.

To implement an on-chain mempool, Neon introduces the concept of a tree of NeonTxs. This splits a single large transaction into smaller, manageable units (NeonTxs) while maintaining overall logic.

How It Works

1. Tree of Transactions:

• A Neon contract creates a "tree" of transactions, where smaller units (branches) can execute independently.
• Each transaction is atomic, meaning its changes only apply if it completes successfully.

2. Parallel Execution:

• Independent transactions can run in parallel, speeding up the process.

3. Error Handling:

• If one transaction in the tree fails, it doesn’t ruin the whole process. The logic of the Neon contract can decide how to handle failures.

4. Final Aggregation:

• After all transactions in the tree finish, their results are combined (aggregated) into a final transaction.

Proxy Workflow with Solana Signature SDK

Transaction Creation:

• Solana users initiate a transaction by signing it with their native wallets (Phantom, Backpack, Solflare) using the Solana Signature SDK.
• The transaction is packaged into a Neon-compatible format via the SDK and sent to Neon Proxy.

On-Chain Scheduling and Mapping:

• The Neon Proxy maps the user’s Solana wallet address to an Ethereum-compatible address, ensuring proper integration with Ethereum-based smart contracts on Neon EVM.
• The transaction is scheduled on-chain in the Neon EVM mempool, awaiting execution.

Transaction Execution:

• The Neon Proxy scans the mempool for scheduled transactions and validates them using Solana’s ed25519 signatures.
• The transaction is executed on Neon EVM, triggering smart contract interactions and updating the state on both Solana and Neon networks.

Post-Execution Cleanup:

• The Neon Proxy ensures efficient system maintenance by cleaning up temporary resources, thus optimizing future transactions.

While the Neon Proxy works as the enabler for interaction between Solana wallets and the Neon EVM ecosystem, unlocking the full market potential requires eliminating asset management fragmentation. Unified asset management across networks is key to driving adoption and a more integrated user experience.

ERC20ForSPL Updates: Unified Token Management

A primary feature of the SDK is its refined ERC20ForSPL contract logic, addressing interoperability challenges between Ethereum and Solana. The contract bridges the two networks by enabling ERC-20 tokens to function within the Solana environment. The focus is to refine the ERC20ForSPL contract logic for unifying balances, maintaining backward compatibility, and introducing robust tools for developers. Here’s how:

Unified Balance Management

• PDA and ATA Integration: Neon EVM currently utilized Program Derived Addresses (PDAs) to manage balances. With the implementation of Associated Token Accounts (ATAs) usage, the contract will bring together these two key Solana components to manage balances in one unified way.
• Transfer prioritization: When transferring tokens, the contract first uses the PDA balance. If that balance is not enough, it uses the ATA balance.
• Elimination of fragmentation: This unification makes token management simpler and less fragmented, providing users with a unified token management experience.

The transfer logic here is simple as:

• Recipient address verification: Before sending tokens, the contract checks if the recipient’s address is compatible with Ethereum (EVM) and ensures that their ATA (Solana's version of a wallet) is initialized.
• Conditional transfers: If the ATA is ready, tokens go there. If not, they are sent to the PDA by default.
• Combined balance view: The balanceOfmethod now provides a unified view of both the PDA and ATA balances, ensuring accurate representation of a user's total holdings.

Backward Compatibility and Safety

While the ERC20ForSPL contract has been updated, it remains paramount to maintain backward compatibility (ensuring existing implementations continue to work without disruption) while adding new features to enhance capabilities.

For this, the contract maintains compatibility with existing implementations by preserving state variables, method signatures, and event parameters. It introduces new precompile methods under 0xFf00000000000000000000000000000000000007, enhancing developer capabilities. isSolanaUser determines if an EVM address corresponds to a Solana account while solanaAddress retrieves the Solana public key associated with an EVM address.

A Builder Preview: Lifecycle of a Neon Transaction Created with the SDK

Step 1: Transaction Creation in the Front-End

1.1 Use ethers.js, web3.js or any other tool to create a Neon EVM transaction.
1.2 Package the transaction into a Solana transaction using the Native Wallet SDK, fetching requisite metadata via Neon Proxy.
1.3 (Optional): Add instructions for Solana asset approval, enabling direct access by Neon EVM smart contracts.

Step 2: Solana Wallet Signs and Submits the Transaction

2.1 dApp front-end sends the packaged transaction to the user's Solana wallet.
2.2 The user reviews and signs the transaction through their wallet UI.
2.3 The wallet submits the signed transaction to the Solana network, scheduling it in Neon’s on-chain mempool.

Step 3: Neon Proxy Executes the Scheduled Transaction

3.1 Neon Proxy scans the on-chain mempool and identifies ready-to-execute transactions.
3.2 Executes the transaction on Neon EVM, resulting in state updates on both Neon and Solana.
3.3 Removes the transaction from the mempool after execution.

Get Started with the SDK

• Access the Repository: Dive into the Neon Solana Signature SDK on GitHub.
• Developer Documentation: Explore comprehensive docs.
• Community Developer Support: Join our Discord. Look up the Discord dev channel for real-time help and seek our invite-only access to Telegram Builder’s chat.

For those interested in building, we are happy to discuss it. You may reach out to us on Discord or email our BD Lead at [email protected]. Don’t miss a beat: follow Twitter for the latest updates.