Rl-HackathonFeedback

# Hackathon Feedback — MetaMask Smart Accounts Kit × 1Shot API × Venice AI Dev Cook Off

**Project:** Redelegator Finance — an autonomous agent-to-agent (A2A) DeFi portfolio manager on Base. One EIP-7715 grant → an AI orchestrator (Venice) plans a capped strategy → a chain of specialist agents re-signs delegations that narrow authority at every hop (`parentDelegation`) → the 1Shot public relayer redeems the whole chain on-chain with gas paid in USDC → the asset lands in the user's own wallet.

We shipped end-to-end on **Base mainnet** using all three sponsor stacks (real USDC in → real wstETH back). Feedback below is grounded both in what we hit while building **and** in a read-through of the official resources linked from this hackathon — it points out specific gaps, not generic praise.

---

## MetaMask Smart Accounts Kit (ERC-7715 / ERC-7710 / EIP-7702)

**What worked well**
- EIP-7715 scoped permissions + redelegation via `parentDelegation` on `createDelegation` is a clean, composable primitive. "One scoped, expiring, revocable grant → a chain that only narrows" mapped perfectly to an agent use case, and the `Erc20TransferAmount` caveat enforced on-chain is exactly the trust model we wanted.

**Friction + concrete suggestions**
1. **Docs are fragmented across namespaces and versions.** The same concepts live under both `docs.metamask.io/delegation-toolkit/...` and `docs.metamask.io/smart-accounts-kit/...`, across versioned paths (`0.12.0`, `0.13.0`) and `/experimental/` routes. It's genuinely hard to tell which is current/canonical. *Suggestion:* one canonical path with a clear "stable vs experimental" banner and a redirect from the old `delegation-toolkit` URLs.
2. **ERC-7715 method naming is inconsistent.** The concept docs describe the RPC as `wallet_grantPermissions`, while the kit exposes a `requestExecutionPermissions` wallet-client action (what we actually called). A one-line mapping ("`requestExecutionPermissions` → `wallet_grantPermissions`") would save confusion.
3. **Multi-wallet provider conflict is a silent footgun.** With MetaMask + Phantom + Flow Wallet installed, a generic wagmi `injected()` connector grabbed the wrong provider, and a competing wallet's content script spammed `console.error("Error checking default wallet status: {}")` that Next.js surfaced as a full error overlay. Our fix: `injected({ target: "metaMask" })`. *Suggestion:* the ERC-7715 quickstart should recommend pinning the MetaMask target / EIP-6963 discovery and warn about `window.ethereum` hijack.
4. **The 7715 prompt timeout error is opaque.** Approving the permission slowly fails with `An internal error was received. Details: Timeout waiting for user decision Version: viem@2.52.2` — unactionable for a developer or end-user. *Suggestion:* a clearer, documented error + a configurable decision window.
5. **Version gate needs to be louder.** EIP-7715 needs a recent MetaMask (≥ 13.23 / Flask) and is still under `/experimental/`. *Suggestion:* a prominent supported-versions callout + a runtime capability check snippet.

---

## 1Shot API — Permissionless Relayer

**What worked well**
- **No signup, no tier management, pure JSON-RPC** is the best DX decision in this stack. We wired `relayer_getCapabilities → relayer_getFeeData → relayer_estimate7710Transaction → relayer_send7710Transaction → relayer_getStatus` and shipped same-day. Gas in USDC removed the "user must hold ETH" friction entirely — ideal for agents. Pulling `feeCollector`/`targetAddress`/tokens from `getCapabilities` (not hardcoding) is well-signposted.

**Friction + concrete suggestions (verified against the EIP-7710 gas-sponsorship quickstart)**
1. **Status representation mismatch.** The quickstart describes task states as `Pending / Submitted / Confirmed / Rejected / Reverted`, but the actual `relayer_getStatus` response we polled returned **numeric codes** (we had to map 200/400/500 → done/failed/running ourselves). *Suggestion:* document the exact `status` field type + a value→meaning table so builders don't reverse-engineer it.
2. **Fee mechanics are documented, but the failure path isn't.** `feeAmount = max(convertedFee, minFee)` and the ~45-second `context` lock are clear; what's missing is the **re-sign + re-estimate loop when the quote expires mid-signing** (exactly the case we hit on a slow MetaMask prompt). *Suggestion:* a short "quote expired, now what" recipe.
3. **Error codes aren't enumerated.** `relayer_estimate7710Transaction` returns an `error` field on validation failure, but the specific codes/messages aren't listed — hard to branch on. *Suggestion:* publish an error-code table.
4. **Webhook verification is underspecified.** The docs mention verifying Ed25519 signatures against the relayer JWKS for `destinationUrl` push updates, but give no JWKS endpoint URL or verification example. *Suggestion:* add the JWKS URL + a 10-line verify snippet.
5. **No mention of rate limits or task retention** (how long a `TaskId` stays queryable). Useful to document for production polling.

---

## Venice AI

**What worked well**
- OpenAI-compatible behind one key, and **strict `response_format: { type: "json_schema" }`** + `venice_parameters: { strip_thinking_response: true }` gave us reliable, schema-validated strategy JSON from a plain-language intent — perfect for an "intent → validated plan" step. The `llms.txt` they publish is a nice touch for AI coding agents.

**Friction + concrete suggestions**
1. **Structured-output support isn't discoverable.** The overview/about page (and the highlighted models — Claude Opus 4.7, GPT-5.5, Kimi K2.6) say nothing about `json_schema`, `strip_thinking_response`, or which models reliably honor structured output. We only got it working by digging into the API reference. *Suggestion:* an "Agentic / Structured JSON" guide that lists which models support `response_format: json_schema` and shows the `venice_parameters` pattern.
2. **Recommended model for agentic JSON is unclear.** Our env default (`qwen-2.5-qwq-32b`) differed from the model the templates referenced (`qwen3-235b-a22b-instruct-2507`); neither is surfaced as "the one to use for tool/JSON output." *Suggestion:* a clearly recommended default + an expected-latency note per model (our large-model reasoning call took ~5–9 s).

---

## Documentation, Skills & Resources (cross-cutting)

- **Skill-based onboarding (install a skill into your AI IDE) is the standout** across all three sponsors — keep investing here; it was the fastest path to a working integration.
- **Stamp API references with a "verified on <date>" + a smoke-test snippet.** While adding an extra agent we followed a documented hosted REST endpoint (a third-party LP API) that turned out to be **deprecated/unreachable with a standard developer key** — the host returned `530` on those routes while sibling routes worked, the alternate host returned `ACCESS_DENIED`, and the reference page 301-redirected away. We only found this by live-probing. A freshness stamp + one-line curl would have saved hours. (We pivoted that agent to the official SDK instead.)
- **A single "minimum-viable A2A" reference repo** wiring all three — 7715 grant → relayer redeem → Venice plan — would be a fantastic anchor for the "Best A2A coordination" track.

---

## HackQuest platform & process

- The **"Prepare with AI" prompt**, **to-do checklist**, and **countdown** lower onboarding anxiety — good.
- *Suggestion:* show a prominent **submission checklist** (working Smart-Accounts integration **in the main flow** + demo-video requirement) well before the deadline, so teams don't discover a hard requirement late.
- *Suggestion:* clarify the **demo-video** expectation up front (length + must show the 7715/Smart-Accounts step).

---

## Top 4 actionable asks (TL;DR)

1. **MetaMask docs:** consolidate `delegation-toolkit` vs `smart-accounts-kit` (+ versions/experimental), map `requestExecutionPermissions` ↔ `wallet_grantPermissions`, and add a multi-wallet provider-pinning warning.
2. **1Shot docs:** publish the exact `relayer_getStatus` field type + value table (docs say strings, the API returned numbers for us), an error-code table, and the webhook JWKS URL.
3. **Venice docs:** an "Agentic / Structured JSON" guide — which models support `json_schema`, the `strip_thinking_response` pattern, and a recommended default + latency.
4. **All sponsors:** "verified on <date>" stamps + smoke-test snippets on API references (we hit a deprecated third-party endpoint the hard way).

Overall: 1Shot's zero-signup relayer + EIP-7715 scoped permissions + Venice structured output are a genuinely strong agentic stack. The highest-leverage, cheapest wins are in **doc consolidation, status/error specs, and structured-output discoverability** — small fixes that compound for every future builder.

---

### Resources reviewed
- MetaMask: [Advanced Permissions (ERC-7715)](https://docs.metamask.io/smart-accounts-kit/concepts/advanced-permissions/) · [Create a redelegation](https://docs.metamask.io/smart-accounts-kit/development/guides/delegation/create-redelegation/) · [ERC-7710 redeem](https://docs.metamask.io/smart-accounts-kit/0.13.0/experimental/erc-7710-redeem-delegations/)
- 1Shot: [EIP-7710 gas sponsorship quickstart](https://1shotapi.com/docs/quickstarts/gas-sponsorship-eip7710)
- Venice: [About Venice](https://docs.venice.ai/overview/about-venice) · [Skills](https://github.com/veniceai/skills)

We designed and shipped Redelegator Finance — an agent-to-agent DeFi portfolio manager on Base — using all three sponsor stacks: MetaMask Smart Accounts Kit (EIP-7715 grant + ERC-7710 redelegation + EIP-7702 agent accounts), the 1Shot Permissionless Relayer (gasless redemption, gas paid in USDC), and Venice AI (intent → schema-validated strategy). We ran the full flow live on Base mainnet (real USDC → wstETH back to the user's wallet). This feedback distills what we learned building against each stack, plus a read-through of the official docs linked from the hackathon.

Not fundraising — hackathon submission.