Hi from Hendobox — web3 / DeFi skills

[Hendobox]

Hey — Hendobox here.

Mostly on the web3 / DeFi lane: defi/evm_tx_handler, and currently defi/token_security_scanner (GoPlus pre-trade scan, #365 / PR #368), plus earlier wallet_screening work under #115.

I use Skillware for agent-side due diligence before trades — scan → optional wallet screen → preview/execute — as hard skills with stable JSON (Hermes3 capabilities, split and modernized).

Happy to help point people at open DeFi proposals if useful. Questions / chaining ideas welcome.

[rosspeili]

🫂- web3 lane is growing fast, and have like 20+ skill proposals in the catalogue around defi, finance, monitoring etc. Besides destilling H3, I believe defi skills will be one of the core categories based the amount of web3 x ai users. <3

[unassassinnumerique]

hi @Hendobox I am also use Hermes3 and Skillware Web3 Skill. I am not a programming but use Hermes for trade and want to use Skillware for make my other agent on my computer to trade. Can you teach me?

[imMamdouhaboammar]

@Hendobox @rosspeili The weakest link in this skill chain might end up being a single if between scan and execute 😄

Looking through #368, I'd love to see a host-side gate that fails closed on unknown, incomplete critical signals, API failures, or stale scan results

GoPlus itself treats missing fields as unknown, especially with unverified or proxy contracts, so even a low risk label needs its evidence and timestamp attached when the next agent picks it up

There's an interesting preview-to-execute edge case here too. Since evm_tx_handler re-quotes before broadcast, human approval should be bound to the exact chain, token, spender, amount, and slippage the user reviewed. Change any of those, and the agent should re-preview and request approval again

Otherwise, we could end up with an agent that does excellent due diligence on one transaction and confidently executes another 😅

@unassassinnumerique I'd start with an unfunded demo: scan → optional wallet_screening → preview → stop, inspecting the JSON at each step before introducing a signing key. A copy-paste Hermes example demonstrating that exact flow would make a great starting point for non-developers

One regression test I'd particularly like to see: a successful scan followed by a changed spender between preview and execute, with execution explicitly blocked

That handoff is where I'd spend the testing budget

[rosspeili]

Hey @imMamdouhaboammar, welcome and thanks for the thoughts.

Quick clarifications on our side:

“Host-side gate / single if”, that’s intentional in Skillware: skills stay single-purpose JSON tools, the host (agent loop, SkillContext, or a chains: YAML step) owns scan → gate → quote/preview → execute. We’re already asking for a small chaining snippet on #368 for that reason, not a missing in-skill orchestrator. Remember, Skillware is only a hard-skill registry, not the host, not the runtime that owns orchestration.

GoPlus unknowns / evidence + timestamp, fair concern for pre-trade scans, worth checking against what #368 actually returns (risk_tier, signals, warnings) once merged. If something critical is unknown, the host should treat that as block, not “low risk because label says so.” Still what we're looking here is not trust or not trust token, arguably most should not be trusted, but more about technical limitations, eg. if I buy this token, can I sell it later, or is it a honeypot?

Preview → execute binding, evm_tx_handler already documents that execute re-quotes at broadcast and preview amounts can drift, today confirmed: true is human-in-the-loop, not a cryptographic bind to the exact preview payload. So yes: if chain/token/amount/slippage change after approval, the agent should re-preview, but that’s host discipline unless we add an explicit approval token / param-equality check later (which is in the plan), and it is up to operator to remove the HITL on tgeir own risk if they want frictionless transactions.

Changed-spender regression test, helpful as an end-to-end host integration test (scan says contract A, execute tries B → must not sign). Less clear as a unit test inside evm_tx_handler alone, since router/spender is config-derived and cross-step validation isn’t in scope yet.

For @unassassinnumerique, agree on unfunded demo first. In-repo starting points: EVM_TX_HANDLER_EXAMPLE_DEMO=1 + examples/gemini_evm_tx_handler.py / claude_evm_tx_handler.py (resolve → quote → preview → optional execute). A Hermes3 copy-paste would be great from someone running that stack daily, we don’t ship Hermes configs in this repo, even tho a lot of Web3 skills will derive from the original H3 agent.

Hope that helps separate what’s already architectural vs what’s a good follow-up (host gate examples, optional approval binding, etc.). Feel free to pick relevant issues or suggest issues <3

[Hendobox]

Thanks @rosspeili — and welcome @unassassinnumerique / @imMamdouhaboammar.

Host gate / unknowns: Agree with Ross — skills stay atomic; the host owns scan → gate → quote/preview → execute. Treat risk_tier in (critical, high, unknown) or status != ok as block, not “label says low so we’re fine.” #368 already surfaces signals, warnings, and sources[].fetched_at for that check.

Preview → execute binding / changed spender: Host discipline today (confirmed: true is HITL, not a crypto bind). Worth a follow-up issue on evm_tx_handler if we want param-equality / approval tokens — not in-skill orchestration on the scanner.

@unassassinnumerique: Best start is unfunded: install the DeFi extras, run EVM_TX_HANDLER_EXAMPLE_DEMO=1 with examples/gemini_evm_tx_handler.py (or Claude), and inspect JSON at each step before any signing key. Catalog: DeFi hub. Happy to point at docs; I’m not a 1:1 trading tutor — Skillware is the tool layer.

Pushing the #368 doc/chaining nits Ross asked for shortly.