Plugin-evm tests and multichain support #864
Conversation
|
Hey @nicky-ru! :) This is cool! One thing tho is that transfer, swap and bridge do not work in this plugin, check issue #735 There's also the GOAT plugin which you could add multi-chain support to if you want to take a stab at it. The GOAT library supports all EVM chains (and Solana): https://github.com/ai16z/eliza/tree/main/packages/plugin-goat |
Hey @0xaguspunk! I noticed the issues with transfer, swap, and bridge functionality (#735) and mentioned in the PR that they will be addressed in a follow-up. This PR focuses on enabling multichain support and making the plugin more test-friendly via TDD + a foundation to extend the plugin with more features. The GOAT plugin does look interesting, and I’ll take a closer look to see if it aligns with the goals here. Let me know if you think it’s better to pivot entirely to GOAT, or if continuing with this plugin (and fixing the mentioned issues) is a good path forward! |
|
Ah got it! Thanks for the context! :) Then it makes sense knowing it will be fixed on another PR. No, no need to pivot to goat. PR is fine, neat having the tests there too! 🙏 |
Hi @0xaguspunk , Just to clarify—are there any additional steps or changes you’d like me to make before the PR is ready for merging? It would be great to have it merged as a base to continue working on improvements and fixes for Issue #735. Let me know if there’s anything else I should address! Thanks again! |
| this.currentChain = chain; | ||
| }; | ||
| private createHttpTransport = (chain: SupportedChain) => { | ||
| return http(this.chains[chain].rpcUrls.default.http[0]); |
There was a problem hiding this comment.
My concern with this is that the public RPCs can be quite unreliable. Here I'm not able to override the RPC with one I want to use (for instance, from Alchemy).
Maybe you can infer the RPC from the env variables through the chain name having the env variable be ETHEREUM_PROVIDER_<CHAIN_NAME> (e.g if I have base as a supported chain, I will look for an ETHEREUM_PROVIDER_BASE env variable to set up the RPC)
There was a problem hiding this comment.
@0xaguspunk totally agree, let me push some fixes in a bit
There was a problem hiding this comment.
@0xaguspunk This has been fixed in commit ee6663e.
You can now configure the mainnet custom RPC URL by setting the EVM_PROVIDER_URL value. For other chains, use the template ETHEREUM_PROVIDER_<CHAIN_NAME>.
Additionally, the current version supports adding custom chains, even if they are not part of viem/chains.
| const walletProvider = new WalletProvider( | ||
| privateKey as `0x${string}`, | ||
| chainNames | ||
| ); | ||
| const address = walletProvider.getAddress(); | ||
| const balance = await walletProvider.getWalletBalance(); | ||
| return `EVM Wallet Address: ${address}\nBalance: ${balance} ETH`; |
There was a problem hiding this comment.
Maybe I'd add the chain you are getting the balance for
There was a problem hiding this comment.
Maybe I'd add the chain you are getting the balance for
The current behavior defaults to Ethereum mainnet unless another chain is provided, in which case it uses the first chain in the list (see tests on lines 24-29 and 36-40). Next, we plan to add a switch chain action and a separate action to fetch the balance for a specific chain.
Does this approach make sense?
|
Hi @odilitime, Thanks for visiting the PR! I noticed it was marked as “new plugin,” but just to clarify, this PR is actually an improvement to the existing plugin, not a new one. The changes add multichain support, refactor the code for better testability, and introduce tests that were previously missing. Additionally, my latest commits address Issue #735 and fix the transfer functionality that was mentioned there as seen on the next screenshot: 
Let me know if there’s anything else needed for this PR or if further clarification is required! 😊 Thanks again for your time! |
|
think this is on good track, using viem chains for chain data, also what was missing for transfer to work (generating object with LLM) is here. I was thinking to do the same, but found out this was already here, so no point in repeating this. currently I had some problems running this, there was RPC error, not sure why and now both claud and openai are timing out for response so I cant test it, will try it out more as I want to use it for transferring eth/tokens and other EVM things. Will report back asap |
Thanks for your feedback! Yeah the rpc url is a headache if the fromChain is not in viem/chain list. I've added a console log for transfer for better debugging. Also since ethereum mainnet is just "mainnet" in viem/chains most probably the issue originated from that, also pushed a fix for the template. We'll need to make it more robust in the next iteration 😁 |
nicky-ru
force-pushed
the
plugin-evm-multichain
branch
from
1cf47be to
8c15447
Compare
having 504 today all the time with my installations. not sure what is happening, eager to test this but just cant :( actually my problem before was on sepolia but good point about "mainnet" nobody would write that in a message. as its very important chain, should be some casting, if someone writes ETh or ethereum or even L1 should load "mainnet" chain from viem IMO. Also wonder how would code pick between arbitrum and arbitrum nova, maybe there would be needed another LLM call that would compare message and find proper chain name from list of all the chains.... I tried this regex, didn't implement it but please check this kind of pattern, could help In matching |
|
Hey @n00b21337 , Thanks for sharing your solution! The regex and normalization approach makes a lot of sense. I ended up taking a slightly different route by limiting the options to just the supported chains that were intentionally included. This way, I'm only checking a predefined list instead of scanning through all the const chains = Object.keys(wp.chains);
// Replace the placeholder with supported chain names
const contextWithChains = context.replace("SUPPORTED_CHAINS", chains.toString());Maybe a mix of both approaches could make this even better. What do you think? |
ok, sounds good. |
|
@n00b21337 Yeah, no problem! The template basically provides an instruction and an example of how the returned data should look. It gets combined with the current state to create a context, which the model uses to generate the transferDetails object. The "fromChain": SUPPORTED_CHAINS part is a placeholder in the template. Before passing the context to the model, I replace SUPPORTED_CHAINS with the actual list of connected chains (from wp.chains). This way, the model knows which chains to consider when generating the output. so in short, the template shows the structure, and by swapping in the real chain list, the model sticks to that structure and uses the valid chains. let me know if it helps! |
thnx for nice explanation. so what I see as another problem is this. think the provider is checking wallet on ethereum and its funds with get_balance but i have a wallet with 0 funds on ethereum but I do have on sepolia, so this happens all the time. Think the provider also needs to get proper context from message, select that chain and then check balance there. After that it can go to actions |
|
closing this in favor of #1009 |
|
@n00b21337 weird.., just tried it on my side both mainnet and sepolia work. I never created a doc, but the character json should include this: "chains": {
"evm": [
"sepolia"
]
} |
I just literally made a new installation, made a check out of this branch and run Tate bot with anthropic. I didn't know I need to add chains, like this I belive? and you sure you are running on this same branch here? :) I don't see what I could have be do wrong here anymore Two notes on
|
|
@n00b21337 its the same as in the previous version, but instead of passing chain config, only need to pass chain name: "settings": {
"secrets": {},
"voice": {
"model": "en_US-male-medium"
},
"chains": {
"evm": [
"sepolia"
]
}
}then
|
|
yes, this works. is this added anywhere in docs or how can ppl know they need to set it up there in character? yes, you are right, think actions should be modular, but how to chain them then? is it possible that AI first finds check balance action, runs that, then uses output context and insert it into next action like transfer? |
Relates to:
#303
Risks
Low, dependent on viem chains.
Background
What does this PR do?
This PR initiates support for testing the EVM plugin, which was previously unsupported. Added multichain support, the current version of the plugin only supported mainnet and Base, and there have been several requests for additional EVM chain support.
What kind of change is this?
Why are we doing this? Any context or related work?
Initially, the goal was to add IoTeX EVM chain support. However, the scope was expanded to include general multichain support, given the demand for broader compatibility. Transfers are not yet fully functional, as noted in Issue #735. This will be addressed in a follow-up PR.
Documentation changes needed?
No.
Currently, the project documentation does not cover blockchain configurations, including EVM plugin setup. No changes are required at this time.
Testing
How was it tested
Where should a reviewer start?
File: packages/plugin-evm/src/tests/wallet.test.ts
Detailed testing steps
No manual testing is required; automated tests have been implemented and cover the new functionality.
Discord username
nikita_zhou