Embedded Wallets

[thearyanag]

Is your feature request related to a problem? Please describe. Feature
Ideally, at scale - it's not feasible in many cases to create a unique wallet for each agent per user

Describe the solution you'd like
A solution, where an embedded wallet is created for the agent, linked to a identity - can be a user's wallet address, or any field in database

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context

Just for reference purposes

1. https://passkeys.foundation/docs
2. https://privy.io/blog/introducing-server-wallets

[Rudrakc]

Hey was just going through the code base and I saw that the wallet is being created from the private key Keypair.fromSecretKey(bs58.decode(private_key));, so where exactly are unique wallet for each agent are being created. From this code it will get the particular wallet from a given private key.

[skushagra9]

Hey was just going through the code base and I saw that the wallet is being created from the private key Keypair.fromSecretKey(bs58.decode(private_key));, so where exactly are unique wallet for each agent are being created. From this code it will get the particular wallet from a given private key.

Ig, its created on the browser

[thearyanag]

hey @Rudrakc - not sure what your question here is, and how it's related to embedded wallet

[skushagra9]

Hey @thearyanag ,
I have gone through the flow of creating wallets for the agents, and I see, we are taking in the private key of the users address, and then we make a wallet for that private key
We can link this embedded wallet to a user's identity

We can do it in this way - (considering, we could also change the inputs):

Take in the users address as the input and provide the access to the private key for the embedded wallet - we can make it a child wallet which is approved by the parent wallet, in our case - its the user's address
Over here, I would also need access to the Database for more clarity
We can even abstract out most of the logic for approval and confirmations, as all of it could be delegated to the child-wallet

Let me know if we can go with this approach

[0xNoushad]

Hey @thearyanag key idea is to streamline wallet interactions by allowing users to connect their own wallets directly to the agent. Once connected, the agent will interact seamlessly with the user wallet, which is linked to their identity (via wallet address or email address). The Solana-Agent-Kit will act as a single, unified framework for all users—staying consistent across the platform while still enabling personalized wallet usage.

1-Agent Keypair: The agent will maintain its own unique keypair for processing and enhanced security, ensuring robust operation across all interactions.
2-User Wallets: Each user connects their wallet to the agent for their transactions and actions. The agent does not create separate wallets for individual users, simplifying wallet management.

[thearyanag]

I was thinking, we can change the keypair being passed to something like wallet interface, which could be something like

{
 public_address : PubKey,
 sendTransaction(): => string, 
 sendAllTransaction() => string,
}

this way we could use any embedded wallet, or private key

wdyt @0xNoushad / @skushagra9

[HaranK007]

@thearyanag Can we have 2 approaches?

1. The existing keypair method.
2. Passing the custom wallet object. (pubkey, signtx, sendtx, signandsendtx, sendalltx).

and a new parameter to choose the wallet method 1/2.

[michaelessiet]

I think a better approach would be to add a flag/parameter that allows for the agent kit to be wallet independent. All it needs is an address and it's able to create and compile transactions/messages into a serializable string or object, then send that as a response for the integrator's users to sign themselves. That way the toolkit accounts for integrators building server or on-device autonomous agents and wallets and also accounts for integrators that want the agent on the server and user keys on their device (for security and liability reasons). Of course, this would involve a big refactor but I think it's worth it, I wouldn't mind opening a PR for it

[HaranK007]

I think a better approach would be to add a flag/parameter that allows for the agent kit to be wallet independent. All it needs is an address and it's able to create and compile transactions/messages into a serializable string or object, then send that as a response for the integrator's users to sign themselves. That way the toolkit accounts for integrators building server or on-device autonomous agents and wallets and also accounts for integrators that want the agent on the server and user keys on their device (for security and liability reasons). Of course, this would involve a big refactor but I think it's worth it, I wouldn't mind opening a PR for it

Although this requires a refactor of the current implementation of the tools, I think it will open up direct client side integration and many more as they can integrate without revealing security (private keys). Moreover, it copes up with the most of the embedded wallet services available as they also expect the versioned tx or a buffer.

[skushagra9]

I was thinking, we can change the keypair being passed to something like wallet interface, which could be something like

{
 public_address : PubKey,
 sendTransaction(): => string, 
 sendAllTransaction() => string,
}

this way we could use any embedded wallet, or private key

wdyt @0xNoushad / @skushagra9

Yes, this makes much more sense

[askwhyharsh]

interesting, is someone working on this?

[michaelessiet]

Why does this seem like it's AI generated

[UnclePhil1]

Why does this seem like it's AI generated

Refining words

[00x4A]

Will this not work ?
keypair = Keypair.generate();

To generate a new key and wallet when initializing a bot or after an action

Or have agent ask u to input a wallet before a task that requires wallet

[slimeonmyhead]

I think a better approach would be to add a flag/parameter that allows for the agent kit to be wallet independent. All it needs is an address and it's able to create and compile transactions/messages into a serializable string or object, then send that as a response for the integrator's users to sign themselves. That way the toolkit accounts for integrators building server or on-device autonomous agents and wallets and also accounts for integrators that want the agent on the server and user keys on their device (for security and liability reasons). Of course, this would involve a big refactor but I think it's worth it, I wouldn't mind opening a PR for it

Any update or more discussions regarding this approach? I feel like this is the most useful way to build the tooling in this repo

[thearyanag]

hey @michaelessiet - can you attach a dummy implementation on how are you thinking to implement it?

[slimeonmyhead]

A simple example would be to just return the transaction variable from the Jupiter trade function
https://github.com/sendaifun/solana-agent-kit/blob/main/src/tools/jupiter/trade.ts#L84

My hacky approach was to sign the transaction from a wallet property on the agent. This allowed me to sign transactions with the Privy server-side client (example)

But the solution proposed by @michaelessiet would be more ergonomic allowing for any method of transaction signing such as the Phantom chrome extension

[thearyanag]

@slimeonmyhead do you then think this would cover all the cases?

{
 public_address : PubKey,
 sendTransaction(): => string, 
 sendAllTransaction() => string,
}

[slimeonmyhead]

@thearyanag Ideally, the agent constructor would only require public_address: PublicKey

Then you could use

const transaction = await agent.transfer(toAddress, 1);
// sign and send from a server
await wallet.sendTransaction(transaction)
// or you could return the transaction all the way back to a client browser
return transaction

[michaelessiet]

hey @michaelessiet - can you attach a dummy implementation on how are you thinking to implement it?

Will do. I'm currently working on a drift integration. I'll do this once I'm done with that