Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add svm keypair wallet provider #246

Open
wants to merge 9 commits into
base: master
Choose a base branch
from

Conversation

ngundotra
Copy link

@ngundotra ngundotra commented Feb 2, 2025

What changed? Why?

Add Solana wallet provider abstract class called svmWalletProvider in order to pave the way for Solana integration with Coinbase's AgentKit. There is a concrete implementation called SvmKeypairWalletProvider that performs the basic functions to implement Solana actions.

This PR updates the WalletProvider instance from abstract getNetwork() -> Network to abstract getNetwork() -> Promise<Network> in order to support Solana network retrieval, which requires a network request to check genesis hash.

Qualified Impact

  • this change may have to be rolled back to prevent breaking changes to the WalletProvider interface

@cb-heimdall
Copy link

cb-heimdall commented Feb 2, 2025

🟡 Heimdall Review Status

Requirement Status More Info
Reviews 🟡 0/1
Denominator calculation
Show calculation
1 if user is bot 0
1 if user is external 0
From .codeflow.yml 1
Additional review requirements
Show calculation
Max 0
0
From CODEOWNERS 0
Global minimum 0
Max 1
1
1 if commit is unverified 1
Sum 2

@ngundotra ngundotra marked this pull request as ready for review February 2, 2025 23:54
Comment on lines 82 to 84
// Assumes `to` is a hex encoded address that we'll convert to a Solana PublicKey
async nativeTransfer(to: `0x${string}`, value: string): Promise<`0x${string}`> {
const toPubkey = new PublicKey(Buffer.from(to.slice(2), "hex"));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We will weaken the WalletProvider#nativeTransfer abstract method signature to support string instead of 0x${string}. It doesn't break anything explicitly yet to weaken the type and I would prefer to have solana feel native from day 0

Comment on lines 39 to 43
return {
protocolFamily: SOLANA_PROTOCOL_FAMILY,
chainId: String(SOLANA_MAINNET_CHAIN_ID),
networkId: SOLANA_MAINNET_NETWORK_ID,
};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: can we make Network typed objects for each of these and a map from genesisHash to network object

Comment on lines 2 to 5
export const SOLANA_MAINNET_CHAIN_ID = 101;
export const SOLANA_TESTNET_CHAIN_ID = 102;
export const SOLANA_DEVNET_CHAIN_ID = 103;

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

are these standard? Is there a more canonical chain identifier that we can use for solana?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are not standard - I stole this from ankr, but looks like it differs provider to provider.

Technically the most canonical chain identifier is the result of the getGenesisHash rpc call: solana genesis-hash.

* @param transaction - The transaction to sign.
* @returns The signed transaction.
*/
abstract signTransaction(transaction: VersionedTransaction): VersionedTransaction;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
abstract signTransaction(transaction: VersionedTransaction): VersionedTransaction;
abstract signTransaction(transaction: VersionedTransaction): Promise<VersionedTransaction>;

Signing will be async with some wallet provider implementations

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants