{"id":"4eacd628-d592-46d8-8e40-4d18f27d69b1","entityType":"agent","slug":"clawhub-daav3-api3-feed-manager","name":"Api3 Feed Manager","canonicalUrl":"https://www.xpersona.co/agent/clawhub-daav3-api3-feed-manager","canonicalPath":"/agent/clawhub-daav3-api3-feed-manager","generatedAt":"2026-10-11T14:13:05.998Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T10:35:10.643Z","emptyReason":null},"description":"Discover, activate, fund, and maintain Api3 data feeds permissionlessly for downstream agent projects. Use when an agent needs a decentralized data feed pric...","descriptionLabel":"Source description","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 1.1K downloads reported by the source. Last updated 10/11/2026.","installCommand":"clawhub skill install s176sa2svdwgks5ycz1yngewb184yand:api3-feed-manager","sourceUrl":"https://clawhub.ai/daav3/api3-feed-manager","homepage":"https://clawhub.ai/daav3/skills/api3-feed-manager","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/daav3/api3-feed-manager","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/daav3/skills/api3-feed-manager","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":61,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"Api3 Feed Manager technical dossier on Xpersona with agent coverage, OPENCLEW support, and live trust metadata."},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-11T10:35:10.643Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T10:35:10.643Z","emptyReason":null},"stars":null,"forks":null,"downloads":1086,"packageName":null,"latestVersion":"0.4.4","tractionLabel":"1.1K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T10:35:10.636Z","emptyReason":null},"lastUpdatedAt":"2026-10-11T10:35:10.643Z","lastCrawledAt":"2026-10-11T10:35:10.636Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-12T10:35:10.636Z","lastVerifiedAt":null,"highlights":[{"version":"0.4.4","createdAt":"2026-05-19T13:38:58.664Z","changelog":"Sync the published runtime to the latest repo feed-manager implementation, add scripted deploy-communal-proxy support with communal-proxy-aware post-funding behavior, and tighten downstream readiness guidance without relaxing the guarded execution boundary.","fileCount":11,"zipByteSize":43977},{"version":"0.4.3","createdAt":"2026-05-06T12:28:39.685Z","changelog":"Remove the public env/private-key credential patterns from Api3 feed execution and keep the guarded execution contract explicit.","fileCount":10,"zipByteSize":35633},{"version":"0.4.2","createdAt":"2026-05-06T12:26:15.070Z","changelog":"Harden the public signer contract for Api3 feed execution, prefer env-based signer handling, and clarify guarded execution boundaries.","fileCount":10,"zipByteSize":35930},{"version":"0.4.1","createdAt":"2026-05-06T12:18:03.406Z","changelog":"Bundle the borrow-proof executor into the EVK public artifact and harden the live-proof contract with explicit swap protection and opt-in unlimited approvals.","fileCount":10,"zipByteSize":35163},{"version":"0.4.0","createdAt":"2026-04-28T15:57:48.712Z","changelog":"## api3-feed-manager v0.4.0 - Expanded README and SKILL documentation with explicit implementation status, operating modes, and executable state classification for funding and feed activation. - Added CHANGELOG.md file. - Improved handling and reporting for browser-assisted funding and automation cases. - Output now includes concrete, machine-usable state for funding execution (e.g., `not-needed`, `executable`, `browser-assisted`, `unsupported`). - Strengthened guidance and checks for downstream agent workflows, dry-runs, and maintenance operations. - Broadened automation capabilities for funding and feed activation flows; unsupported cases now fail closed and report clearly.","fileCount":10,"zipByteSize":34251},{"version":"0.2.1","createdAt":"2026-04-16T16:08:38.359Z","changelog":"Update SKILL.md from the latest GitHub version.","fileCount":9,"zipByteSize":30369},{"version":"0.2.0","createdAt":"2026-04-16T15:13:14.239Z","changelog":"Initial public release.","fileCount":9,"zipByteSize":30377}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s176sa2svdwgks5ycz1yngewb184yand:api3-feed-manager","setupComplexity":"low","setupSteps":["Install using `clawhub skill install s176sa2svdwgks5ycz1yngewb184yand:api3-feed-manager` in an isolated environment before connecting it to live workloads.","No published capability contract is available yet, so validate auth and request/response behavior manually.","Review the upstream CLAWHUB listing at https://clawhub.ai/daav3/api3-feed-manager before using production credentials."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-daav3-api3-feed-manager/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-daav3-api3-feed-manager/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-daav3-api3-feed-manager/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-daav3-api3-feed-manager/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-daav3-api3-feed-manager/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-daav3-api3-feed-manager/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-11T14:13:05.991Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-daav3-api3-feed-manager/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-daav3-api3-feed-manager/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-daav3-api3-feed-manager/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-daav3-api3-feed-manager/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T10:35:10.643Z","emptyReason":null},"readme":"Skill: Api3 Feed Manager\n\nOwner: daav3\n\nSummary: Discover, activate, fund, and maintain Api3 data feeds permissionlessly for downstream agent projects. Use when an agent needs a decentralized data feed pric...\n\nTags: latest:0.4.4\n\nVersion history:\n\nv0.4.4 | 2026-05-19T13:38:58.664Z | user\n\nSync the published runtime to the latest repo feed-manager implementation, add scripted deploy-communal-proxy support with communal-proxy-aware post-funding behavior, and tighten downstream readiness guidance without relaxing the guarded execution boundary.\n\nv0.4.3 | 2026-05-06T12:28:39.685Z | user\n\nRemove the public env/private-key credential patterns from Api3 feed execution and keep the guarded execution contract explicit.\n\nv0.4.2 | 2026-05-06T12:26:15.070Z | user\n\nHarden the public signer contract for Api3 feed execution, prefer env-based signer handling, and clarify guarded execution boundaries.\n\nv0.4.1 | 2026-05-06T12:18:03.406Z | user\n\nBundle the borrow-proof executor into the EVK public artifact and harden the live-proof contract with explicit swap protection and opt-in unlimited approvals.\n\nv0.4.0 | 2026-04-28T15:57:48.712Z | auto\n\n## api3-feed-manager v0.4.0\n\n- Expanded README and SKILL documentation with explicit implementation status, operating modes, and executable state classification for funding and feed activation.\n- Added CHANGELOG.md file.\n- Improved handling and reporting for browser-assisted funding and automation cases.\n- Output now includes concrete, machine-usable state for funding execution (e.g., `not-needed`, `executable`, `browser-assisted`, `unsupported`).\n- Strengthened guidance and checks for downstream agent workflows, dry-runs, and maintenance operations.\n- Broadened automation capabilities for funding and feed activation flows; unsupported cases now fail closed and report clearly.\n\nv0.2.1 | 2026-04-16T16:08:38.359Z | user\n\nUpdate SKILL.md from the latest GitHub version.\n\nv0.2.0 | 2026-04-16T15:13:14.239Z | user\n\nInitial public release.\n\nArchive index:\n\nArchive v0.4.4: 11 files, 43977 bytes\n\nFiles: _meta.json (136b), CHANGELOG.md (1346b), package.json (834b), README.md (2018b), references/part1-architecture-update.md (2479b), references/part1-research.md (14366b), references/part1-skill-spec.md (2977b), scripts/api3-feed-manager.js (124309b), scripts/bin/api3-feed-manager.js (191b), skill-card.md (2962b), SKILL.md (9821b)\n\nFile v0.4.4:SKILL.md\n\n---\nname: api3-feed-manager\ndescription: Discover, activate, fund, and maintain Api3 data feeds permissionlessly for downstream agent projects. Use when an agent needs a decentralized data feed pricing a blockchain based asset on a supported chain, needs to ensure feed runway for a build or deployment, or must maintain an already-enabled feed over time. Default to discovery, readiness checks, and dry-run planning first, and only use signer-backed execution when the user explicitly asks for it.\nmetadata:\n  clawdis:\n    homepage: https://github.com/daav3/agentic-lending-project\n    author: daav3\n    requires:\n      bins:\n        - node\n      config:\n        - request.ensure-feeds.json\n        - request.execute-buy-subscription.json\n---\n\n# Api3 Feed Manager\n\nThis skill is the oracle-enablement layer for agent-built projects that need reliable, decentralized, onchain data feeds.\n\nIt is designed to let agents:\n- find the correct Api3 feed\n- distinguish between feeds that are merely discoverable and feeds that are currently active\n- determine whether a feed is already usable\n- fund/activate it when possible\n- deploy the deterministic communal Api3 reader proxy when frontend/integration readiness depends on it\n- maintain runway for continued operation\n\nwithout requiring manual coordination with the Api3 team.\n\n## When to use\n\nUse this skill when:\n- a project needs a reliable, onchain, decentralized price feed\n- an agent wants to deploy something that depends on a live oracle\n- an existing feed may need a top-up or runway check\n- a downstream skill or app needs feed activation as a prerequisite\n\n## Core modes\n\n### 1. discover-feed\nUse when you need to identify the best Api3 data feed for:\n- an asset\n- a pair\n- a chain\n- a specific oracle use case\n\nExpected output:\n- feed identity\n- chain availability\n- whether it is discoverable\n- whether it appears active/usable\n- whether activation may be needed\n- any ambiguity or missing mapping\n\n### 2. ensure-feed-active\nUse when you know the required feed and want to ensure it has enough funding/runway.\n\nDefault target runway:\n- 90 days\n\nExpected output:\n- current funding/liveness status\n- estimated runway\n- whether funding/top-up is needed\n- execution path or exact transaction instructions\n\n### 3. check-feed-runway\nUse to inspect an already-known feed and estimate maintenance needs.\n\nExpected output:\n- current status\n- remaining runway estimate\n- whether action is required soon\n\n### 4. top-up-feed\nUse when a feed exists but needs more runway.\n\nExpected output:\n- required funding token/amount\n- top-up execution plan\n- resulting status if executed\n\n### 5. maintain-feed\nUse for maintenance mode when one or more project feeds must remain alive.\n\nExpected output:\n- current state per feed\n- top-up recommendation or actions taken\n- next maintenance checkpoint recommendation\n\n## Inputs to gather before acting\n\nCollect these first when available:\n- target chain\n- asset or pair required\n- use case (e.g. lending collateral pricing, borrow asset pricing)\n- desired runway in days\n- whether execution is allowed or discovery-only\n- signer/funder available to the agent\n- explicit operator approval if any real transaction submission is requested\n\n## Operating rules\n\n1. Do not pretend a feed is active without checking.\n2. Distinguish clearly between:\n   - feed missing\n   - feed present but unfunded\n   - feed available on another chain only\n   - feed exists but agent lacks execution capability\n3. Prefer permissionless operation paths.\n4. If a step cannot be done permissionlessly, say exactly why.\n5. Return concrete feed identifiers and maintenance recommendations.\n6. If discovery is ambiguous, surface the ambiguity instead of guessing.\n7. Treat signer-backed execution as a guarded operator action, not a default background step.\n8. Prefer signer material from local runtime setup, never from committed files.\n\n## Suggested workflow\n\n### For a new project\n1. Discover feed\n2. Confirm chain/feed suitability\n3. Check whether active/funded\n4. Ensure 90-day runway\n5. Return feed details to downstream builder/deployer\n\n### For an existing project\n1. Check current runway\n2. If below threshold, top up\n3. Return next maintenance recommendation\n\n## Output contract\n\nAim to return structured results containing:\n- `feedFound`\n- `discoverable`\n- `active`\n- `activationPossible`\n- `statusClassification`\n- `feedName`\n- `feedAddressOrId`\n- `chain`\n- `funded`\n- `runwayEstimateDays`\n- `requiredFundingAsset`\n- `estimatedFundingAmount`\n- `actionsTaken`\n- `transactions`\n- `nextMaintenanceRecommendation`\n- `warnings`\n\n## Current implementation status\n\nCurrent honest state:\n- feed discovery and readiness inspection: implemented\n- exact guarded `buySubscription(...)` execution: implemented\n- execution modes:\n  - `direct`\n  - `wrapper` when exact wrapper calldata is derivable safely\n  - `auto`\n- machine-usable funding state classification: implemented\n  - `not-needed`\n  - `executable`\n  - `browser-assisted`\n  - `unsupported`\n- browser-assisted funding should stay automatable where safe\n  - use `browser-plan` to produce the exact Market flow\n  - if the required UI is reachable, execute that plan with the browser tool instead of downgrading to a vague manual handoff\n  - after any funding execution, re-run feed readiness before claiming the feed is ready for downstream oracle or EVK steps\n- browser-assisted funding planning: implemented via `browser-plan`\n\nStill not universal:\n- not every funding path is exact onchain-executable yet\n- some flows still require browser-assisted automation\n- unsupported cases must still fail closed and be reported explicitly\n\nCurrent priorities:\n1. broaden executable funding coverage beyond the first exact family\n2. keep browser-assisted flows automatable where safe\n3. preserve explicit state classification instead of overclaiming support\n4. improve maintenance-mode and multi-feed workflows\n5. keep downstream EVK and Morpho handoffs aligned with the live planner behavior proven in canaries\n6. keep communal proxy deployment and downstream readiness checks aligned with the packaged runtime\n\n## Feed-name matching guardrails for downstream lending flows\n\nWhen this skill is used as a prerequisite for EVK or Morpho deployment:\n- prefer a literal exact dAPI name match before any alias-normalized match\n- treat symbol-family aliases as fallback discovery aids, not as reasons to block a live literal feed that already matches the requested asset pair\n- preserve the original requested dAPI name for live readiness checks; only use canonicalized symbols for fallback route derivation when no literal match exists\n- if a literal match is live and readable on-chain, classify that feed as ready even when alias-equivalent feeds also exist\n- only surface ambiguity when the literal-exact bucket itself is ambiguous\n- keep this logic asset-agnostic: the same path should work for whichever supported collateral and borrow assets the planner selects, not just previously tested majors\n\n## Downstream EVK canary handoff\n\nWhen this skill hands off to downstream EVK deployment tooling or canary execution:\n- require a signer-backed dry-run before any real send\n- treat multi-transaction deployment plans as sequential, not parallel\n- if later transactions depend on contracts created earlier in the same plan, wait for each receipt before sending the next transaction\n- if funding landed through the `browser-assisted` branch, execute the returned `browser-plan` when the Market flow is reachable and then re-run readiness before continuing\n- if the funded feed still lacks code at its deterministic communal proxy address, deploy that proxy before treating the integration path as complete\n- do not collapse `fundingExecutionClassification.state` into a generic “ready”; preserve the exact branch all the way into downstream reporting\n- do not assume `real-send ready` means “safe to fire blind”, it only means the plan has executable payloads and still needs a final operator check\n- if downstream EVK work needs proof of real borrowability, treat that as a separate post-deploy milestone rather than equating deployment success with borrowability\n- if the operator intentionally wants a duplicate or near-duplicate market attempt, require `duplicatePolicy: \"warn-only\"` so the planner keeps the path deployable and emits an explicit warning instead of silently bypassing duplicate protection\n- if the direct pair is unavailable but a supported composition route is live (for example through a shared unit of account such as USD), allow the EVK path to use that composed oracle route rather than failing prematurely\n- keep deployment and verification rules generic across supported asset pairs; do not special-case only the pairs used in earlier canaries\n- after a real send, verify more than submission: confirm nonce movement, status=1 receipts, deployed contract addresses for each oracle leg/wrapper, and final market deployment success before reporting the canary as successful\n\n## Downstream Morpho handoff\n\nWhen this skill hands off to downstream Morpho deployment tooling:\n- keep proxy-first ordering when a communal proxy deploy is required before adapter deploy or market creation\n- keep the same signer, RPC, and nonce assumptions across deploy + verify steps in a single live run\n- support the planner selecting whichever supported collateral/borrow pair is requested, as long as the oracle path resolves cleanly and verification invariants hold\n- do not treat a mined market-create transaction as success unless downstream verification confirms the market exists, params match, `price()` succeeds, and the oracle price is positive\n- persist enough artifact context for the next operator turn: tx hashes, market id, final oracle address, and a short failure-before / success-after note\n\nFile v0.4.4:README.md\n\n# Api3 Feed Manager\n\nAn OpenClaw skill for discovering Api3 feeds, checking whether they are live, classifying the activation/funding path, and executing the currently supported funding flows when possible. Default to discovery, readiness checks, and dry-run planning first; only use signer-backed execution when the operator explicitly asks for it.\n\n## What it helps with\n\n- find supported Api3 chain aliases\n- audit feed coverage across chains\n- separate activatable feeds from retired or delisted ones\n- inspect queue tiers and default activation choices\n- prepare exact `buySubscription(...)` Market contract calls for the supported narrow family\n- execute guarded funding in the supported exact path\n  - `direct`\n  - `wrapper` when exact wrapper calldata is derivable safely\n  - `auto`\n- deploy the deterministic communal Api3 reader proxy when runtime or downstream integration readiness depends on it\n- treat signer material as local runtime input rather than committed skill data\n- expose machine-usable funding states:\n  - `not-needed`\n  - `executable`\n  - `browser-assisted`\n  - `unsupported`\n- prepare browser-assisted funding plans when exact execution is not yet available\n\n## What it does not do\n\n- provide universal pure-onchain automation for every funding case\n- pretend retired feeds are still available\n- replace `SKILL.md` as the agent-facing instruction file\n\n## Main files\n\n- `SKILL.md` - instructions for the agent\n- `scripts/bin/api3-feed-manager.js` - local CLI entrypoint\n- `scripts/api3-feed-manager.js` - bundled runtime\n\n## Quick examples\n\n```bash\nnode ./scripts/bin/api3-feed-manager.js supported-chains\nnode ./scripts/bin/api3-feed-manager.js coverage-audit --chain arbitrum --limit 20\nnode ./scripts/bin/api3-feed-manager.js queue-plan --dapi-name ETH/USD --rpc-url https://arb1.arbitrum.io/rpc --chain arbitrum\nnode ./scripts/bin/api3-feed-manager.js deploy-communal-proxy --dapi-name ETH/USD --rpc-url https://arb1.arbitrum.io/rpc --chain arbitrum --private-key <private-key-hex>\n```\n\nFile v0.4.4:_meta.json\n\n{\n  \"ownerId\": \"kn79961pqqa20q5jwn60zjkxzs84yc3w\",\n  \"slug\": \"api3-feed-manager\",\n  \"version\": \"0.4.4\",\n  \"publishedAt\": 1779197938664\n}\n\nFile v0.4.4:references/part1-architecture-update.md\n\n# Part 1 Architecture Update\n\n## Important correction\n\nFurther review shows the Part 1 skill should not be modeled only as a generic \"feed funding helper\".\n\nHowever, for the agent use case in this project, the correct practical model is **not** per-dApp proxy deployment.\n\n## Agent-specific constraint\n\nFor these agents, we should use the **generic proxy on Api3 Market**.\n\nReason:\n- OEV can accrue to Api3 in this mode\n- permissionless deployment of individual dApp-specific proxies is not currently available for our intended fully permissionless agent flow\n\nSo the skill should optimize for what agents can actually do today, not for a cleaner but unavailable theoretical path.\n\n## Revised role of the skill\n\nThe skill should primarily do four things:\n\n1. discover the relevant feed on Api3 Market\n2. classify whether the feed is active / usable / non-operational\n3. return the correct **generic Market proxy** or integration artifact for downstream agents\n4. when needed, help move a known but inactive feed toward usability through funding/activation paths\n\n## Why this matters\n\nA downstream agent using this skill should be able to ask:\n- \"I need an Api3 price feed for asset X on chain Y\"\n\nand get back:\n- whether the feed is known on Market\n- whether it appears operational\n- the generic Market proxy / feed integration details to use\n- whether the feed is already usable\n- if not usable, what is missing (e.g. activation/funding)\n\n## What the skill should not assume\n\nThe skill should **not** assume:\n- that a dApp-specific Api3ReaderProxyV1 can be permissionlessly deployed for the agent today\n- that the ideal OEV-capturing deployment pattern is available to agent users right now\n\n## Design implication\n\nThe architecture should now prioritize:\n1. live feed discovery from Api3 Market metadata\n2. readiness classification\n3. generic proxy resolution / integration artifact return\n4. non-operational feed activation/funding support\n\n## Updated implementation direction\n\nNear-term implementation should focus on:\n- improving live discovery matching\n- extracting/returning the generic Market proxy path where possible\n- identifying discoverable but non-operational feeds\n- only then extending toward activation/funding workflows\n\n## Why this is the correct compromise\n\nThis design is less theoretically perfect than per-dApp proxy deployment, but it matches the actual permissionless capability available to agent users now.\n\nThat is the right tradeoff for this project.\n\nFile v0.4.4:references/part1-research.md\n\n# Part 1 Research: Api3 Market discovery, readiness, and funding flows\n\n## Objective\n\nMap what an agent can discover, verify, fund, and maintain today through Api3 Market, and turn that into a concrete MVP contract for `api3-feed-manager`.\n\n## Sources reviewed\n\nPrimary docs and surfaces reviewed for this pass:\n- https://docs.api3.org/dapps/quickstart/\n- https://docs.api3.org/dapps/integration/\n- https://docs.api3.org/dapps/integration/contract-integration.html\n- https://docs.api3.org/dapps/oev-rewards/\n- https://docs.api3.org/oev-searchers/in-depth/data-feeds/\n- `@api3/contracts` in this repo's dependencies\n- live Api3 Market pages in browser\n\n## Executive summary\n\nThe good news is that Part 1 is more concrete than the earlier draft suggested.\n\nA workable agent flow already exists:\n1. discover candidate feeds on Api3 Market by chain and pair\n2. determine whether the feed is already active on that network\n3. if active, return the integration proxy and avoid paying again\n4. if inactive, purchase a 3-month plan through Api3 Market\n5. return the proxy, active state, and renewal recommendation\n\nThe most important implementation decision is to use a **layered source-of-truth model**:\n- **Api3 Market** for human-readable discovery and commercial state\n- **Api3 contracts** for canonical dAPI to data-feed resolution\n- **AirseekerRegistry + Signed APIs** for underlying beacon composition and off-chain signed data inspection\n- **Api3ReaderProxyV1 read()** for the final integration-ready state check\n\nFor the project, the safest MVP remains:\n- default to the **communal/generic Api3ReaderProxyV1 path** for agents\n- treat dApp-specific OEV-enabled proxies as a later enhancement unless we explicitly verify the self-serve path end to end\n\n## Confirmed findings\n\n### 1. Api3 Market is the primary discovery surface\n\nFrom the quickstart and live Market UI:\n- Api3 Market serves a catalog of feeds by network\n- the network page includes search, featured active feeds, and a full catalog\n- **all feeds are inactive by default**\n- if a feed is already active, the user lands on the data-feed page directly\n- if a feed is inactive, the user lands on the activation page first\n\nThis gives us a practical first discovery model:\n- search by `chain + pair`\n- determine whether the feed is already active\n- only enter purchase flow when activation is required\n\n### 2. Activation is a plan purchase, not a low-level oracle-admin flow\n\nApi3 Market exposes activation as a commercial subscription flow:\n- mainnets use **3-month plans**\n- testnets use **7-day plans**\n- plan purchase immediately activates a feed if inactive\n- if active already, purchase extends or upgrades the queued operating plan\n- the user chooses the deviation threshold subscription tier\n- the heartbeat is fixed at **24 hours**\n\nAdditional clarification from an Api3 developer:\n- each data feed has its **own wallet setup**, but there is only **one sponsor wallet per feed**\n- the effective deviation threshold is determined by the feed's **subscriptions queue**, where **smaller thresholds get priority**\n- this means the skill should model deviation selection as a queue/subscription concern, not as a separate per-wallet configuration surface\n\nOffered deviation thresholds in docs:\n- 5%\n- 2.5%\n- 1%\n- 0.5%\n- 0.25%\n\nImportant operational behavior from docs:\n- once a plan is purchased, Api3 guarantees those update parameters for the purchased plan duration\n- after expiry, the feed stops being upheld\n- users are responsible for renewing plans if they want continuous service\n- if a feed is already active, leftover prepaid value can roll into the next purchase as a discount\n\n### 3. The pricing model is concrete enough for an MVP\n\nDocs state that prices are based on estimated operational cost:\n- historical gas cost of updates\n- expected update frequency for the chosen deviation threshold\n- operating duration\n\nDocs also state:\n- prices are charged at estimated operating cost, with a minimum of `$0.05/day`\n- overestimates roll into future discounts for the same network-feed pair\n- on testnets, updates may stop if payment runs out even before plan expiry\n\nLive Market inspection on Arbitrum showed an activation page quoting total cost directly in **ETH** for that chain.\n\nWorking conclusion for the skill:\n- we can treat funding as a **time-bound plan purchase**\n- the skill should target **90 days on mainnets** by default\n- the exact payment asset appears to be the chain-native gas token in the UI at least on Arbitrum, but that still needs explicit per-chain confirmation before we hardcode it as universal behavior\n\n### 4. There are two proxy integration modes\n\nThe docs are very clear that integrations consume **Api3ReaderProxyV1**.\n\nFrom the integration docs:\n- `read()` returns `(int224 value, uint32 timestamp)`\n- Api3 data feeds have **18 decimals**\n- `Api3ReaderProxyV1` also implements Chainlink's `AggregatorV2V3Interface`\n\nFrom the Market integration docs:\n- **Skip OEV Rewards** shows one `Api3ReaderProxyV1` address\n- **Earn OEV Rewards** shows a different `Api3ReaderProxyV1` address, and may require a proxy deployment step\n\nFrom `@api3/contracts` in this repo's dependencies:\n- the package exposes **`computeCommunalApi3ReaderProxyV1Address`**\n- it also exposes **`computeDappSpecificApi3ReaderProxyV1Address`**\n- and **`unsafeComputeDappId`**\n\nThat is strong evidence that the product surface really does distinguish between:\n- a **communal/generic proxy path**\n- a **dApp-specific OEV-enabled proxy path**\n\nFor this project, that means the Part 1 MVP should:\n- return the **communal proxy** by default\n- treat dApp-specific OEV enrollment as optional/advanced\n- avoid assuming that the OEV-specific path is the universal default for agent users\n\n### 5. Canonical data-feed resolution is contract-driven under the hood\n\nThe strongest technical resolution path came from the Api3 data-feed docs.\n\nThe canonical path is:\n1. encode the dAPI name, e.g. `ETH/USD`\n2. hash it\n3. call `Api3ServerV1.dapiNameHashToDataFeedId(...)`\n4. call `AirseekerRegistry.dataFeedIdToDetails(...)`\n5. decode the result as either:\n   - a single beacon `(address airnode, bytes32 templateId)`, or\n   - a beacon set `(address[] airnodes, bytes32[] templateIds)`\n\nThis gives the skill a proper technical backplane behind Market discovery.\n\nMeaning:\n- Market should be used to find the likely feed and active/inactive state\n- contract reads should be used to canonicalize the underlying feed identity\n- AirseekerRegistry gives the underlying beacon composition for deeper verification\n\n### 6. Signed APIs give a public off-chain inspection surface\n\nApi3 exposes public Signed API endpoints:\n- base feed: `https://signed-api.api3.org/public/<airnode>`\n- OEV feed: `https://signed-api.api3.org/public-oev/<airnode>`\n\nThe docs show the response includes:\n- `count`\n- `data`\n- per-entry fields including `airnode`, `templateId`, `timestamp`, `encodedValue`, and `signature`\n\nDocs also state:\n- base feeds are publicly updateable with signed data\n- OEV feeds are real-time and tied to the OEV mechanism\n- base feed data is served with delay in the OEV design\n\nFor the MVP, Signed APIs are useful for:\n- inspecting whether the underlying beacon data exists publicly\n- checking that the expected airnode/template pairs are live\n- validating that the feed is not merely listed but has recent signed data underneath it\n\n### 7. Sponsor-wallet complexity does not appear to be the user-facing activation primitive\n\nEarlier thinking over-indexed on sponsor wallets.\n\nAfter this pass, the more accurate framing is:\n- sponsor-wallet concepts are part of underlying Airnode request sponsorship mechanics\n- **Api3 Market activation docs do not present sponsor-wallet management as the normal user workflow for activating a Market feed**\n- an Api3 developer clarified that there is **one sponsor wallet per feed**, not one sponsor wallet per subscription tier or deviation choice\n- the user-facing flow is still purchase-based: choose parameters, connect wallet, buy plan\n\nSo for Part 1:\n- sponsor-wallet logic should **not** be treated as the main agent UX\n- but the internal model should assume a **stable sponsor wallet per feed**\n- deviation thresholds should be modeled as subscription-queue priorities, where smaller thresholds can win precedence\n- if sponsor-wallet logic becomes relevant, it should be treated as protocol background or an implementation detail, not the first-class interaction model\n\n## Recommended readiness model for the skill\n\nThe skill should classify feeds into these states.\n\n### `unavailable`\nUse when:\n- the feed is not discoverable on Market for the target chain, and/or\n- canonical contract resolution does not produce usable data-feed details\n\n### `listed_inactive`\nUse when:\n- the feed is listed on Market for the target chain\n- but no active plan is currently upholding it\n- the next required action is purchase/activation\n\n### `active_communal_usable`\nUse when:\n- the feed is active on Market\n- the communal/generic `Api3ReaderProxyV1` path is available\n- a contract-level read succeeds and returns a sane positive value\n\n### `active_but_needs_deeper_verification`\nUse when:\n- Market suggests the feed is active\n- but proxy resolution or on-chain verification is incomplete\n- the feed should not yet be reported as safely integration-ready\n\n### `dapp_specific_oev_path_available`\nUse when:\n- the feed is active or activatable\n- and the dApp-specific OEV path is available\n- but this should be modeled as optional and separate from the communal default\n\n### `non_operational_or_inconsistent`\nUse when:\n- the feed is listed or resolvable\n- but the proxy read, data-feed details, or signed-data checks do not line up cleanly\n\n## Recommended MVP source-of-truth strategy\n\n### Discovery layer\nUse Api3 Market as the first pass for:\n- chain availability\n- pair naming\n- active vs inactive state\n- current commercial plan options\n\n### Canonical resolution layer\nUse on-chain contract reads for:\n- dAPI name to data-feed ID resolution\n- data-feed details decoding\n- beacon vs beacon-set composition\n\n### Verification layer\nUse two checks:\n1. Signed API inspection for underlying beacon freshness\n2. `Api3ReaderProxyV1.read()` for integration-ready consumption\n\nThis is much better than relying only on either:\n- the UI, or\n- raw contracts without Market context\n\n## Activation and maintenance flow for the skill\n\n### `discover-feed`\nShould return:\n- requested chain and pair\n- whether the feed is listed on Market\n- whether it is active now\n- communal proxy address if derivable\n- whether the dApp-specific OEV path is available or intentionally skipped\n- any ambiguity in naming or chain coverage\n\n### `ensure-feed-active`\nShould do this sequence:\n1. discover the feed on Market\n2. if already active, skip purchase and return the proxy\n3. if inactive, direct the user or wallet-capable execution path into Market purchase flow\n4. target a **3-month mainnet plan** by default\n5. after purchase, verify proxy readability before reporting success\n\n### `check-feed-runway`\nThe docs clearly describe expiration behavior, but this pass did **not** uncover a documented stable API for querying remaining runway programmatically.\n\nSo the current implementation assumption should be:\n- Market UI is the visible source for expiration today\n- a programmatic runway check still needs to be pinned down before the skill can claim full automation here\n\n### `maintain-feed`\nFor MVP, this should be conservative:\n- if expiry information is available, recommend renewal before expiry\n- if expiry information is not yet programmatically available, report that limitation explicitly instead of pretending the skill can automate it safely\n\n## Blockers and unresolved questions\n\nThese are the real blockers that remain after this pass.\n\n### 1. Programmatic Market API stability is still unclear\nWe now know how the UI behaves, but we do **not** yet have a confirmed, documented Market API contract that the skill can safely depend on for catalog and expiry queries.\n\n### 2. Exact programmatic expiry/runway path is not yet pinned down\nDocs describe expiry and renewal behavior clearly, but I have not yet confirmed the stable underlying API or contract field that exposes remaining runway for automation.\n\n### 3. Exact per-chain payment asset still needs confirmation\nThe Arbitrum activation flow clearly quoted cost in ETH, which strongly suggests native gas-token payment on that chain. But I have not yet confirmed the rule across all supported networks.\n\n### 4. OEV self-serve flow needs a stricter go/no-go decision\nDocs imply that self-serve OEV-enabled integration can be completed through Api3 Market, but the project should still default to the communal path until we explicitly test and trust the dApp-specific flow for agent usage.\n\n### 5. Contract address sourcing needs to be nailed down in implementation\nWe have the resolution functions and proxy computation helpers, but the implementation still needs a clean source for the correct chain-specific `Api3ServerV1` and `AirseekerRegistry` addresses.\n\n## Implications for issue #5\n\nIssue `#5` should now be built around this narrower MVP:\n- default to communal proxy resolution\n- use Market for discovery and active/inactive classification\n- use contract reads for canonical mapping and verification\n- only support purchase guidance or execution once the Market transaction path is confirmed cleanly in code\n- keep dApp-specific OEV mode behind an explicit opt-in\n\n## Recommended immediate next implementation steps\n\n1. build a small discovery probe that accepts `chain + pair` and returns Market match candidates\n2. wire canonical resolution using `dapiNameHashToDataFeedId` and `dataFeedIdToDetails`\n3. add communal proxy computation using `@api3/contracts`\n4. add a verification step that calls `read()` on the resolved proxy\n5. defer full maintenance automation until expiry/runway can be queried programmatically with confidence\n\n## Bottom line\n\nIssue `#4` is now concrete enough to unblock MVP design.\n\nThe Part 1 skill should not be a vague \"feed funding helper\".\nIt should be a **discovery + resolution + activation-decision + proxy-return** tool with a conservative verification layer.\n\nThat is enough to move into implementation without hand-waving, while keeping the remaining unknowns explicit instead of burying them.\n\nFile v0.4.4:references/part1-skill-spec.md\n\n# Part 1 Skill Spec: Api3 Feed Activation Skill\n\n## Skill name (working)\n`api3-feed-manager`\n\n## Purpose\nEnable OpenClaw agents to discover, activate, fund, and maintain Api3 data feeds permissionlessly for downstream applications.\n\n## User stories\n\n### Story 1\nAs an agent building an app that needs a price feed,\nI want to discover the correct Api3 feed on a target chain,\nso I can use it without human oracle coordination.\n\n### Story 2\nAs an agent deploying a lending market,\nI want to ensure the required Api3 feed is active and funded for ~3 months,\nso my market can operate continuously.\n\n### Story 3\nAs an agent maintaining deployed systems,\nI want to check runway and top up feed funding before expiration,\nso dependent systems do not silently degrade.\n\n## Inputs\n\n### Required core inputs\n- `chain`\n- `asset` or `pair`\n- `useCase`\n\n### Optional inputs\n- `quoteAsset`\n- `runwayDays` (default 90)\n- `minimumRunwayDays`\n- `walletReference`\n- `execute` (boolean, default false for discovery/check flows)\n- `allowTopUp` (boolean)\n\n## Outputs\n- `feedFound`\n- `feedName`\n- `feedAddressOrId`\n- `chain`\n- `active`\n- `funded`\n- `runwayEstimateDays`\n- `requiredFundingAsset`\n- `estimatedFundingAmount`\n- `actionsTaken`\n- `transactions`\n- `nextMaintenanceRecommendation`\n- `warnings`\n\n## Commands / modes\n\n### discover-feed\nReturn the best matching feed and its state.\n\n### ensure-feed-active\nEnsure feed is active and funded for target runway.\n\n### check-feed-runway\nInspect runway and return top-up recommendation.\n\n### top-up-feed\nExtend funding for an existing feed.\n\n### maintain-feed\nCheck one or more feeds and top up if allowed.\n\n## Safety requirements\n- Never claim a feed is active without a concrete check.\n- Never claim coequal feeds are interchangeable without evidence.\n- Distinguish:\n  - feed exists but unfunded\n  - feed missing\n  - feed exists on another chain only\n  - feed exists but requires manual wallet capability not currently available\n- Log exact blockers instead of vague failure text.\n\n## MVP build plan\n\n### MVP scope\n- single-feed discovery\n- single-feed status inspection\n- single-feed ensure/top-up flow\n- maintenance recommendation output\n\n### Not required in MVP\n- batch optimization across many feeds\n- advanced treasury strategy\n- multi-wallet policy orchestration\n- automatic cron creation\n\n## Dependencies to confirm\n- exact Api3 Market/API access path\n- exact contract or API method to read feed funding/runway\n- exact activation/funding execution flow\n- exact token/payment route for feed funding on supported chains\n\n## Acceptance criteria\n- Given an asset/pair and chain, the skill can identify whether a usable Api3 feed exists.\n- Given a feed and wallet capability, the skill can determine whether it is sufficiently funded.\n- Given insufficient runway and execution rights, the skill can top up or produce exact execution instructions.\n- The skill can report back the resulting active/funded state and next maintenance recommendation.\n\nFile v0.4.4:CHANGELOG.md\n\n# Changelog\n\n## 0.4.4 - 2026-05-19\n\n- sync the published feed manager runtime with the latest repo implementation\n- add scripted `deploy-communal-proxy` support and communal-proxy-aware post-funding execution\n- preserve the guarded execution boundary while improving downstream EVK/Morpho readiness guidance\n\n## 0.4.0 - 2026-04-28\n\n- clarified that `browser-assisted` funding should hand off to `browser-plan` plus browser execution when the Api3 Market flow is reachable\n- documented that feed readiness must be re-checked after any direct, wrapper, or browser-assisted funding execution before downstream EVK steps continue\n- tightened downstream handoff guidance so agents preserve `fundingExecutionClassification.state` and do not blur deployment success into borrowability proof\n\n## 0.3.0 - 2026-04-22\n\n- synced the packaged skill runtime with the latest repo `api3-feed-manager` implementation\n- added guarded `execute-buy-subscription` support for the first exact executable funding path\n- added execution-mode selection:\n  - `auto`\n  - `direct`\n  - `wrapper` when exact wrapper calldata is safely derivable\n- added machine-usable funding state classification:\n  - `not-needed`\n  - `executable`\n  - `browser-assisted`\n  - `unsupported`\n- updated the skill docs to reflect the current automation boundary and browser-assisted fallback path\n\nFile v0.4.4:skill-card.md\n\n## Description:\n\nDiscover, activate, fund, and maintain Api3 data feeds permissionlessly for downstream agent projects.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[daav3](https://clawhub.ai/user/daav3)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and agents use this skill to discover Api3 oracle feeds, inspect whether they are active and funded, plan maintenance runway, and execute guarded feed activation or top-up flows when explicitly approved.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Signer-backed execution can expose private keys when raw key material is passed as a command argument.\n\nMitigation: Use dry-run planning first and prefer an isolated test wallet or safer signer flow; avoid passing valuable wallet private keys on the command line.\n\nRisk: A submitted blockchain transaction can be reported before final confirmation or before feed readiness is independently verified.\n\nMitigation: Treat submitted transaction hashes as pending until receipt status and on-chain feed readiness are confirmed.\n\nRisk: Not every Api3 funding path is fully executable by the bundled runtime.\n\nMitigation: Review the funding classification and use browser-assisted or unsupported-path guidance where exact execution is not available.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/daav3/skills/api3-feed-manager)\n- [Project homepage](https://github.com/daav3/agentic-lending-project)\n- [Api3 dApp quickstart](https://docs.api3.org/dapps/quickstart/)\n- [Api3 dApp integration](https://docs.api3.org/dapps/integration/)\n- [Api3 contract integration](https://docs.api3.org/dapps/integration/contract-integration.html)\n- [Api3 OEV rewards](https://docs.api3.org/dapps/oev-rewards/)\n- [Api3 data feeds for OEV searchers](https://docs.api3.org/oev-searchers/in-depth/data-feeds/)\n- [Api3 Market](https://market.api3.org)\n- [Api3 dAPI pricing data feeds](https://api3dao.github.io/data-feeds/market/dapi-pricing)\n- [Part 1 Architecture Update](references/part1-architecture-update.md)\n- [Part 1 Research](references/part1-research.md)\n- [Part 1 Skill Spec](references/part1-skill-spec.md)\n\n## Skill Output:\n\n**Output Type(s):** [text, markdown, shell commands, configuration, guidance]\n\n**Output Format:** [Markdown with structured status fields and inline shell commands]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [May include feed identifiers, chain status, funding estimates, transaction plans, submitted transaction hashes, maintenance recommendations, and warnings.]\n\n## Skill Version(s):\n\n0.4.4 (source: release evidence, package.json, changelog released 2026-05-19)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nFile v0.4.4:package.json\n\n{\n  \"name\": \"api3-feed-manager-skill\",\n  \"version\": \"0.4.4\",\n  \"private\": true,\n  \"description\": \"OpenClaw skill and bundled CLI for Api3 feed discovery, funding-state classification, guarded activation execution, and browser-assisted fallback planning.\",\n  \"type\": \"commonjs\",\n  \"bin\": {\n    \"api3-feed-manager\": \"scripts/bin/api3-feed-manager.js\"\n  },\n  \"files\": [\n    \"SKILL.md\",\n    \"README.md\",\n    \"CHANGELOG.md\",\n    \"references\",\n    \"scripts\"\n  ],\n  \"keywords\": [\n    \"openclaw\",\n    \"skill\",\n    \"api3\",\n    \"oracle\",\n    \"feeds\"\n  ],\n  \"engines\": {\n    \"node\": \">=20\"\n  },\n  \"scripts\": {\n    \"check\": \"node --check scripts/api3-feed-manager.js && node --check scripts/bin/api3-feed-manager.js\"\n  },\n  \"dependencies\": {\n    \"@api3/contracts\": \"^37.0.0\",\n    \"@api3/dapi-management\": \"^4.15.0\",\n    \"ethers\": \"^6.15.0\"\n  }\n}\n\nArchive v0.4.3: 10 files, 35633 bytes\n\nFiles: CHANGELOG.md (1050b), package.json (834b), README.md (1731b), references/part1-architecture-update.md (2479b), references/part1-research.md (14366b), references/part1-skill-spec.md (2977b), scripts/api3-feed-manager.js (90917b), scripts/bin/api3-feed-manager.js (191b), SKILL.md (9467b), _meta.json (136b)\n\nFile v0.4.3:SKILL.md\n\n---\nname: api3-feed-manager\ndescription: Discover, activate, fund, and maintain Api3 data feeds permissionlessly for downstream agent projects. Use when an agent needs a decentralized data feed pricing a blockchain based asset on a supported chain, needs to ensure feed runway for a build or deployment, or must maintain an already-enabled feed over time. Default to discovery, readiness checks, and dry-run planning first, and only use signer-backed execution when the user explicitly asks for it.\nmetadata:\n  clawdis:\n    homepage: https://github.com/daav3/agentic-lending-project\n    author: daav3\n    requires:\n      bins:\n        - node\n      config:\n        - request.ensure-feeds.json\n        - request.execute-buy-subscription.json\n---\n\n# Api3 Feed Manager\n\nThis skill is the oracle-enablement layer for agent-built projects that need reliable, decentralized, onchain data feeds.\n\nIt is designed to let agents:\n- find the correct Api3 feed\n- distinguish between feeds that are merely discoverable and feeds that are currently active\n- determine whether a feed is already usable\n- fund/activate it when possible\n- maintain runway for continued operation\n\nwithout requiring manual coordination with the Api3 team.\n\n## When to use\n\nUse this skill when:\n- a project needs a reliable, onchain, decentralized price feed\n- an agent wants to deploy something that depends on a live oracle\n- an existing feed may need a top-up or runway check\n- a downstream skill or app needs feed activation as a prerequisite\n\n## Core modes\n\n### 1. discover-feed\nUse when you need to identify the best Api3 data feed for:\n- an asset\n- a pair\n- a chain\n- a specific oracle use case\n\nExpected output:\n- feed identity\n- chain availability\n- whether it is discoverable\n- whether it appears active/usable\n- whether activation may be needed\n- any ambiguity or missing mapping\n\n### 2. ensure-feed-active\nUse when you know the required feed and want to ensure it has enough funding/runway.\n\nDefault target runway:\n- 90 days\n\nExpected output:\n- current funding/liveness status\n- estimated runway\n- whether funding/top-up is needed\n- execution path or exact transaction instructions\n\n### 3. check-feed-runway\nUse to inspect an already-known feed and estimate maintenance needs.\n\nExpected output:\n- current status\n- remaining runway estimate\n- whether action is required soon\n\n### 4. top-up-feed\nUse when a feed exists but needs more runway.\n\nExpected output:\n- required funding token/amount\n- top-up execution plan\n- resulting status if executed\n\n### 5. maintain-feed\nUse for maintenance mode when one or more project feeds must remain alive.\n\nExpected output:\n- current state per feed\n- top-up recommendation or actions taken\n- next maintenance checkpoint recommendation\n\n## Inputs to gather before acting\n\nCollect these first when available:\n- target chain\n- asset or pair required\n- use case (e.g. lending collateral pricing, borrow asset pricing)\n- desired runway in days\n- whether execution is allowed or discovery-only\n- signer/funder available to the agent\n- explicit operator approval if any real transaction submission is requested\n\n## Operating rules\n\n1. Do not pretend a feed is active without checking.\n2. Distinguish clearly between:\n   - feed missing\n   - feed present but unfunded\n   - feed available on another chain only\n   - feed exists but agent lacks execution capability\n3. Prefer permissionless operation paths.\n4. If a step cannot be done permissionlessly, say exactly why.\n5. Return concrete feed identifiers and maintenance recommendations.\n6. If discovery is ambiguous, surface the ambiguity instead of guessing.\n7. Treat signer-backed execution as a guarded operator action, not a default background step.\n8. Prefer signer material from local runtime setup, never from committed files.\n\n## Suggested workflow\n\n### For a new project\n1. Discover feed\n2. Confirm chain/feed suitability\n3. Check whether active/funded\n4. Ensure 90-day runway\n5. Return feed details to downstream builder/deployer\n\n### For an existing project\n1. Check current runway\n2. If below threshold, top up\n3. Return next maintenance recommendation\n\n## Output contract\n\nAim to return structured results containing:\n- `feedFound`\n- `discoverable`\n- `active`\n- `activationPossible`\n- `statusClassification`\n- `feedName`\n- `feedAddressOrId`\n- `chain`\n- `funded`\n- `runwayEstimateDays`\n- `requiredFundingAsset`\n- `estimatedFundingAmount`\n- `actionsTaken`\n- `transactions`\n- `nextMaintenanceRecommendation`\n- `warnings`\n\n## Current implementation status\n\nCurrent honest state:\n- feed discovery and readiness inspection: implemented\n- exact guarded `buySubscription(...)` execution: implemented\n- execution modes:\n  - `direct`\n  - `wrapper` when exact wrapper calldata is derivable safely\n  - `auto`\n- machine-usable funding state classification: implemented\n  - `not-needed`\n  - `executable`\n  - `browser-assisted`\n  - `unsupported`\n- browser-assisted funding should stay automatable where safe\n  - use `browser-plan` to produce the exact Market flow\n  - if the required UI is reachable, execute that plan with the browser tool instead of downgrading to a vague manual handoff\n  - after any funding execution, re-run feed readiness before claiming the feed is ready for downstream oracle or EVK steps\n- browser-assisted funding planning: implemented via `browser-plan`\n\nStill not universal:\n- not every funding path is exact onchain-executable yet\n- some flows still require browser-assisted automation\n- unsupported cases must still fail closed and be reported explicitly\n\nCurrent priorities:\n1. broaden executable funding coverage beyond the first exact family\n2. keep browser-assisted flows automatable where safe\n3. preserve explicit state classification instead of overclaiming support\n4. improve maintenance-mode and multi-feed workflows\n5. keep downstream EVK and Morpho handoffs aligned with the live planner behavior proven in canaries\n\n## Feed-name matching guardrails for downstream lending flows\n\nWhen this skill is used as a prerequisite for EVK or Morpho deployment:\n- prefer a literal exact dAPI name match before any alias-normalized match\n- treat symbol-family aliases as fallback discovery aids, not as reasons to block a live literal feed that already matches the requested asset pair\n- preserve the original requested dAPI name for live readiness checks; only use canonicalized symbols for fallback route derivation when no literal match exists\n- if a literal match is live and readable on-chain, classify that feed as ready even when alias-equivalent feeds also exist\n- only surface ambiguity when the literal-exact bucket itself is ambiguous\n- keep this logic asset-agnostic: the same path should work for whichever supported collateral and borrow assets the planner selects, not just previously tested majors\n\n## Downstream EVK canary handoff\n\nWhen this skill hands off to downstream EVK deployment tooling or canary execution:\n- require a signer-backed dry-run before any real send\n- treat multi-transaction deployment plans as sequential, not parallel\n- if later transactions depend on contracts created earlier in the same plan, wait for each receipt before sending the next transaction\n- if funding landed through the `browser-assisted` branch, execute the returned `browser-plan` when the Market flow is reachable and then re-run readiness before continuing\n- do not collapse `fundingExecutionClassification.state` into a generic “ready”; preserve the exact branch all the way into downstream reporting\n- do not assume `real-send ready` means “safe to fire blind”, it only means the plan has executable payloads and still needs a final operator check\n- if downstream EVK work needs proof of real borrowability, treat that as a separate post-deploy milestone rather than equating deployment success with borrowability\n- if the operator intentionally wants a duplicate or near-duplicate market attempt, require `duplicatePolicy: \"warn-only\"` so the planner keeps the path deployable and emits an explicit warning instead of silently bypassing duplicate protection\n- if the direct pair is unavailable but a supported composition route is live (for example through a shared unit of account such as USD), allow the EVK path to use that composed oracle route rather than failing prematurely\n- keep deployment and verification rules generic across supported asset pairs; do not special-case only the pairs used in earlier canaries\n- after a real send, verify more than submission: confirm nonce movement, status=1 receipts, deployed contract addresses for each oracle leg/wrapper, and final market deployment success before reporting the canary as successful\n\n## Downstream Morpho handoff\n\nWhen this skill hands off to downstream Morpho deployment tooling:\n- keep proxy-first ordering when a communal proxy deploy is required before adapter deploy or market creation\n- keep the same signer, RPC, and nonce assumptions across deploy + verify steps in a single live run\n- support the planner selecting whichever supported collateral/borrow pair is requested, as long as the oracle path resolves cleanly and verification invariants hold\n- do not treat a mined market-create transaction as success unless downstream verification confirms the market exists, params match, `price()` succeeds, and the oracle price is positive\n- persist enough artifact context for the next operator turn: tx hashes, market id, final oracle address, and a short failure-before / success-after note\n\nFile v0.4.3:README.md\n\n# Api3 Feed Manager\n\nAn OpenClaw skill for discovering Api3 feeds, checking whether they are live, classifying the activation/funding path, and executing the currently supported funding flows when possible. Default to discovery, readiness checks, and dry-run planning first; only use signer-backed execution when the operator explicitly asks for it.\n\n## What it helps with\n\n- find supported Api3 chain aliases\n- audit feed coverage across chains\n- separate activatable feeds from retired or delisted ones\n- inspect queue tiers and default activation choices\n- prepare exact `buySubscription(...)` Market contract calls for the supported narrow family\n- execute guarded funding in the supported exact path\n  - `direct`\n  - `wrapper` when exact wrapper calldata is derivable safely\n  - `auto`\n- treat signer material as local runtime input rather than committed skill data\n- expose machine-usable funding states:\n  - `not-needed`\n  - `executable`\n  - `browser-assisted`\n  - `unsupported`\n- prepare browser-assisted funding plans when exact execution is not yet available\n\n## What it does not do\n\n- provide universal pure-onchain automation for every funding case\n- pretend retired feeds are still available\n- replace `SKILL.md` as the agent-facing instruction file\n\n## Main files\n\n- `SKILL.md` - instructions for the agent\n- `scripts/bin/api3-feed-manager.js` - local CLI entrypoint\n- `scripts/api3-feed-manager.js` - bundled runtime\n\n## Quick examples\n\n```bash\nnode ./scripts/bin/api3-feed-manager.js supported-chains\nnode ./scripts/bin/api3-feed-manager.js coverage-audit --chain arbitrum --limit 20\nnode ./scripts/bin/api3-feed-manager.js queue-plan --dapi-name ETH/USD --rpc-url https://arb1.arbitrum.io/rpc --chain arbitrum\n```\n\nFile v0.4.3:_meta.json\n\n{\n  \"ownerId\": \"kn79961pqqa20q5jwn60zjkxzs84yc3w\",\n  \"slug\": \"api3-feed-manager\",\n  \"version\": \"0.4.3\",\n  \"publishedAt\": 1778070519685\n}\n\nFile v0.4.3:references/part1-architecture-update.md\n\n# Part 1 Architecture Update\n\n## Important correction\n\nFurther review shows the Part 1 skill should not be modeled only as a generic \"feed funding helper\".\n\nHowever, for the agent use case in this project, the correct practical model is **not** per-dApp proxy deployment.\n\n## Agent-specific constraint\n\nFor these agents, we should use the **generic proxy on Api3 Market**.\n\nReason:\n- OEV can accrue to Api3 in this mode\n- permissionless deployment of individual dApp-specific proxies is not currently available for our intended fully permissionless agent flow\n\nSo the skill should optimize for what agents can actually do today, not for a cleaner but unavailable theoretical path.\n\n## Revised role of the skill\n\nThe skill should primarily do four things:\n\n1. discover the relevant feed on Api3 Market\n2. classify whether the feed is active / usable / non-operational\n3. return the correct **generic Market proxy** or integration artifact for downstream agents\n4. when needed, help move a known but inactive feed toward usability through funding/activation paths\n\n## Why this matters\n\nA downstream agent using this skill should be able to ask:\n- \"I need an Api3 price feed for asset X on chain Y\"\n\nand get back:\n- whether the feed is known on Market\n- whether it appears operational\n- the generic Market proxy / feed integration details to use\n- whether the feed is already usable\n- if not usable, what is missing (e.g. activation/funding)\n\n## What the skill should not assume\n\nThe skill should **not** assume:\n- that a dApp-specific Api3ReaderProxyV1 can be permissionlessly deployed for the agent today\n- that the ideal OEV-capturing deployment pattern is available to agent users right now\n\n## Design implication\n\nThe architecture should now prioritize:\n1. live feed discovery from Api3 Market metadata\n2. readiness classification\n3. generic proxy resolution / integration artifact return\n4. non-operational feed activation/funding support\n\n## Updated implementation direction\n\nNear-term implementation should focus on:\n- improving live discovery matching\n- extracting/returning the generic Market proxy path where possible\n- identifying discoverable but non-operational feeds\n- only then extending toward activation/funding workflows\n\n## Why this is the correct compromise\n\nThis design is less theoretically perfect than per-dApp proxy deployment, but it matches the actual permissionless capability available to agent users now.\n\nThat is the right tradeoff for this project.\n\nFile v0.4.3:references/part1-research.md\n\n# Part 1 Research: Api3 Market discovery, readiness, and funding flows\n\n## Objective\n\nMap what an agent can discover, verify, fund, and maintain today through Api3 Market, and turn that into a concrete MVP contract for `api3-feed-manager`.\n\n## Sources reviewed\n\nPrimary docs and surfaces reviewed for this pass:\n- https://docs.api3.org/dapps/quickstart/\n- https://docs.api3.org/dapps/integration/\n- https://docs.api3.org/dapps/integration/contract-integration.html\n- https://docs.api3.org/dapps/oev-rewards/\n- https://docs.api3.org/oev-searchers/in-depth/data-feeds/\n- `@api3/contracts` in this repo's dependencies\n- live Api3 Market pages in browser\n\n## Executive summary\n\nThe good news is that Part 1 is more concrete than the earlier draft suggested.\n\nA workable agent flow already exists:\n1. discover candidate feeds on Api3 Market by chain and pair\n2. determine whether the feed is already active on that network\n3. if active, return the integration proxy and avoid paying again\n4. if inactive, purchase a 3-month plan through Api3 Market\n5. return the proxy, active state, and renewal recommendation\n\nThe most important implementation decision is to use a **layered source-of-truth model**:\n- **Api3 Market** for human-readable discovery and commercial state\n- **Api3 contracts** for canonical dAPI to data-feed resolution\n- **AirseekerRegistry + Signed APIs** for underlying beacon composition and off-chain signed data inspection\n- **Api3ReaderProxyV1 read()** for the final integration-ready state check\n\nFor the project, the safest MVP remains:\n- default to the **communal/generic Api3ReaderProxyV1 path** for agents\n- treat dApp-specific OEV-enabled proxies as a later enhancement unless we explicitly verify the self-serve path end to end\n\n## Confirmed findings\n\n### 1. Api3 Market is the primary discovery surface\n\nFrom the quickstart and live Market UI:\n- Api3 Market serves a catalog of feeds by network\n- the network page includes search, featured active feeds, and a full catalog\n- **all feeds are inactive by default**\n- if a feed is already active, the user lands on the data-feed page directly\n- if a feed is inactive, the user lands on the activation page first\n\nThis gives us a practical first discovery model:\n- search by `chain + pair`\n- determine whether the feed is already active\n- only enter purchase flow when activation is required\n\n### 2. Activation is a plan purchase, not a low-level oracle-admin flow\n\nApi3 Market exposes activation as a commercial subscription flow:\n- mainnets use **3-month plans**\n- testnets use **7-day plans**\n- plan purchase immediately activates a feed if inactive\n- if active already, purchase extends or upgrades the queued operating plan\n- the user chooses the deviation threshold subscription tier\n- the heartbeat is fixed at **24 hours**\n\nAdditional clarification from an Api3 developer:\n- each data feed has its **own wallet setup**, but there is only **one sponsor wallet per feed**\n- the effective deviation threshold is determined by the feed's **subscriptions queue**, where **smaller thresholds get priority**\n- this means the skill should model deviation selection as a queue/subscription concern, not as a separate per-wallet configuration surface\n\nOffered deviation thresholds in docs:\n- 5%\n- 2.5%\n- 1%\n- 0.5%\n- 0.25%\n\nImportant operational behavior from docs:\n- once a plan is purchased, Api3 guarantees those update parameters for the purchased plan duration\n- after expiry, the feed stops being upheld\n- users are responsible for renewing plans if they want continuous service\n- if a feed is already active, leftover prepaid value can roll into the next purchase as a discount\n\n### 3. The pricing model is concrete enough for an MVP\n\nDocs state that prices are based on estimated operational cost:\n- historical gas cost of updates\n- expected update frequency for the chosen deviation threshold\n- operating duration\n\nDocs also state:\n- prices are charged at estimated operating cost, with a minimum of `$0.05/day`\n- overestimates roll into future discounts for the same network-feed pair\n- on testnets, updates may stop if payment runs out even before plan expiry\n\nLive Market inspection on Arbitrum showed an activation page quoting total cost directly in **ETH** for that chain.\n\nWorking conclusion for the skill:\n- we can treat funding as a **time-bound plan purchase**\n- the skill should target **90 days on mainnets** by default\n- the exact payment asset appears to be the chain-native gas token in the UI at least on Arbitrum, but that still needs explicit per-chain confirmation before we hardcode it as universal behavior\n\n### 4. There are two proxy integration modes\n\nThe docs are very clear that integrations consume **Api3ReaderProxyV1**.\n\nFrom the integration docs:\n- `read()` returns `(int224 value, uint32 timestamp)`\n- Api3 data feeds have **18 decimals**\n- `Api3ReaderProxyV1` also implements Chainlink's `AggregatorV2V3Interface`\n\nFrom the Market integration docs:\n- **Skip OEV Rewards** shows one `Api3ReaderProxyV1` address\n- **Earn OEV Rewards** shows a different `Api3ReaderProxyV1` address, and may require a proxy deployment step\n\nFrom `@api3/contracts` in this repo's dependencies:\n- the package exposes **`computeCommunalApi3ReaderProxyV1Address`**\n- it also exposes **`computeDappSpecificApi3ReaderProxyV1Address`**\n- and **`unsafeComputeDappId`**\n\nThat is strong evidence that the product surface really does distinguish between:\n- a **communal/generic proxy path**\n- a **dApp-specific OEV-enabled proxy path**\n\nFor this project, that means the Part 1 MVP should:\n- return the **communal proxy** by default\n- treat dApp-specific OEV enrollment as optional/advanced\n- avoid assuming that the OEV-specific path is the universal default for agent users\n\n### 5. Canonical data-feed resolution is contract-driven under the hood\n\nThe strongest technical resolution path came from the Api3 data-feed docs.\n\nThe canonical path is:\n1. encode the dAPI name, e.g. `ETH/USD`\n2. hash it\n3. call `Api3ServerV1.dapiNameHashToDataFeedId(...)`\n4. call `AirseekerRegistry.dataFeedIdToDetails(...)`\n5. decode the result as either:\n   - a single beacon `(address airnode, bytes32 templateId)`, or\n   - a beacon set `(address[] airnodes, bytes32[] templateIds)`\n\nThis gives the skill a proper technical backplane behind Market discovery.\n\nMeaning:\n- Market should be used to find the likely feed and active/inactive state\n- contract reads should be used to canonicalize the underlying feed identity\n- AirseekerRegistry gives the underlying beacon composition for deeper verification\n\n### 6. Signed APIs give a public off-chain inspection surface\n\nApi3 exposes public Signed API endpoints:\n- base feed: `https://signed-api.api3.org/public/<airnode>`\n- OEV feed: `https://signed-api.api3.org/public-oev/<airnode>`\n\nThe docs show the response includes:\n- `count`\n- `data`\n- per-entry fields including `airnode`, `templateId`, `timestamp`, `encodedValue`, and `signature`\n\nDocs also state:\n- base feeds are publicly updateable with signed data\n- OEV feeds are real-time and tied to the OEV mechanism\n- base feed data is served with delay in the OEV design\n\nFor the MVP, Signed APIs are useful for:\n- inspecting whether the underlying beacon data exists publicly\n- checking that the expected airnode/template pairs are live\n- validating that the feed is not merely listed but has recent signed data underneath it\n\n### 7. Sponsor-wallet complexity does not appear to be the user-facing activation primitive\n\nEarlier thinking over-indexed on sponsor wallets.\n\nAfter this pass, the more accurate framing is:\n- sponsor-wallet concepts are part of underlying Airnode request sponsorship mechanics\n- **Api3 Market activation docs do not present sponsor-wallet management as the normal user workflow for activating a Market feed**\n- an Api3 developer clarified that there is **one sponsor wallet per feed**, not one sponsor wallet per subscription tier or deviation choice\n- the user-facing flow is still purchase-based: choose parameters, connect wallet, buy plan\n\nSo for Part 1:\n- sponsor-wallet logic should **not** be treated as the main agent UX\n- but the internal model should assume a **stable sponsor wallet per feed**\n- deviation thresholds should be modeled as subscription-queue priorities, where smaller thresholds can win precedence\n- if sponsor-wallet logic becomes relevant, it should be treated as protocol background or an implementation detail, not the first-class interaction model\n\n## Recommended readiness model for the skill\n\nThe skill should classify feeds into these states.\n\n### `unavailable`\nUse when:\n- the feed is not discoverable on Market for the target chain, and/or\n- canonical contract resolution does not produce usable data-feed details\n\n### `listed_inactive`\nUse when:\n- the feed is listed on Market for the target chain\n- but no active plan is currently upholding it\n- the next required action is purchase/activation\n\n### `active_communal_usable`\nUse when:\n- the feed is active on Market\n- the communal/generic `Api3ReaderProxyV1` path is available\n- a contract-level read succeeds and returns a sane positive value\n\n### `active_but_needs_deeper_verification`\nUse when:\n- Market suggests the feed is active\n- but proxy resolution or on-chain verification is incomplete\n- the feed should not yet be reported as safely integration-ready\n\n### `dapp_specific_oev_path_available`\nUse when:\n- the feed is active or activatable\n- and the dApp-specific OEV path is available\n- but this should be modeled as optional and separate from the communal default\n\n### `non_operational_or_inconsistent`\nUse when:\n- the feed is listed or resolvable\n- but the proxy read, data-feed details, or signed-data checks do not line up cleanly\n\n## Recommended MVP source-of-truth strategy\n\n### Discovery layer\nUse Api3 Market as the first pass for:\n- chain availability\n- pair naming\n- active vs inactive state\n- current commercial plan options\n\n### Canonical resolution layer\nUse on-chain contract reads for:\n- dAPI name to data-feed ID resolution\n- data-feed details decoding\n- beacon vs beacon-set composition\n\n### Verification layer\nUse two checks:\n1. Signed API inspection for underlying beacon freshness\n2. `Api3ReaderProxyV1.read()` for integration-ready consumption\n\nThis is much better than relying only on either:\n- the UI, or\n- raw contracts without Market context\n\n## Activation and maintenance flow for the skill\n\n### `discover-feed`\nShould return:\n- requested chain and pair\n- whether the feed is listed on Market\n- whether it is active now\n- communal proxy address if derivable\n- whether the dApp-specific OEV path is available or intentionally skipped\n- any ambiguity in naming or chain coverage\n\n### `ensure-feed-active`\nShould do this sequence:\n1. discover the feed on Market\n2. if already active, skip purchase and return the proxy\n3. if inactive, direct the user or wallet-capable execution path into Market purchase flow\n4. target a **3-month mainnet plan** by default\n5. after purchase, verify proxy readability before reporting success\n\n### `check-feed-runway`\nThe docs clearly describe expiration behavior, but this pass did **not** uncover a documented stable API for querying remaining runway programmatically.\n\nSo the current implementation assumption should be:\n- Market UI is the visible source for expiration today\n- a programmatic runway check still needs to be pinned down before the skill can claim full automation here\n\n### `maintain-feed`\nFor MVP, this should be conservative:\n- if expiry information is available, recommend renewal before expiry\n- if expiry information is not yet programmatically available, report that limitation explicitly instead of pretending the skill can automate it safely\n\n## Blockers and unresolved questions\n\nThese are the real blockers that remain after this pass.\n\n### 1. Programmatic Market API stability is still unclear\nWe now know how the UI behaves, but we do **not** yet have a confirmed, documented Market API contract that the skill can safely depend on for catalog and expiry queries.\n\n### 2. Exact programmatic expiry/runway path is not yet pinned down\nDocs describe expiry and renewal behavior clearly, but I have not yet confirmed the stable underlying API or contract field that exposes remaining runway for automation.\n\n### 3. Exact per-chain payment asset still needs confirmation\nThe Arbitrum activation flow clearly quoted cost in ETH, which strongly suggests native gas-token payment on that chain. But I have not yet confirmed the rule across all supported networks.\n\n### 4. OEV self-serve flow needs a stricter go/no-go decision\nDocs imply that self-serve OEV-enabled integration can be completed through Api3 Market, but the project should still default to the communal path until we explicitly test and trust the dApp-specific flow for agent usage.\n\n### 5. Contract address sourcing needs to be nailed down in implementation\nWe have the resolution functions and proxy computation helpers, but the implementation still needs a clean source for the correct chain-specific `Api3ServerV1` and `AirseekerRegistry` addresses.\n\n## Implications for issue #5\n\nIssue `#5` should now be built around this narrower MVP:\n- default to communal proxy resolution\n- use Market for discovery and active/inactive classification\n- use contract reads for canonical mapping and verification\n- only support purchase guidance or execution once the Market transaction path is confirmed cleanly in code\n- keep dApp-specific OEV mode behind an explicit opt-in\n\n## Recommended immediate next implementation steps\n\n1. build a small discovery probe that accepts `chain + pair` and returns Market match candidates\n2. wire canonical resolution using `dapiNameHashToDataFeedId` and `dataFeedIdToDetails`\n3. add communal proxy computation using `@api3/contracts`\n4. add a verification step that calls `read()` on the resolved proxy\n5. defer full maintenance automation until expiry/runway can be queried programmatically with confidence\n\n## Bottom line\n\nIssue `#4` is now concrete enough to unblock MVP design.\n\nThe Part 1 skill should not be a vague \"feed funding helper\".\nIt should be a **discovery + resolution + activation-decision + proxy-return** tool with a conservative verification layer.\n\nThat is enough to move into implementation without hand-waving, while keeping the remaining unknowns explicit instead of burying them.\n\nFile v0.4.3:references/part1-skill-spec.md\n\n# Part 1 Skill Spec: Api3 Feed Activation Skill\n\n## Skill name (working)\n`api3-feed-manager`\n\n## Purpose\nEnable OpenClaw agents to discover, activate, fund, and maintain Api3 data feeds permissionlessly for downstream applications.\n\n## User stories\n\n### Story 1\nAs an agent building an app that needs a price feed,\nI want to discover the correct Api3 feed on a target chain,\nso I can use it without human oracle coordination.\n\n### Story 2\nAs an agent deploying a lending market,\nI want to ensure the required Api3 feed is active and funded for ~3 months,\nso my market can operate continuously.\n\n### Story 3\nAs an agent maintaining deployed systems,\nI want to check runway and top up feed funding before expiration,\nso dependent systems do not silently degrade.\n\n## Inputs\n\n### Required core inputs\n- `chain`\n- `asset` or `pair`\n- `useCase`\n\n### Optional inputs\n- `quoteAsset`\n- `runwayDays` (default 90)\n- `minimumRunwayDays`\n- `walletReference`\n- `execute` (boolean, default false for discovery/check flows)\n- `allowTopUp` (boolean)\n\n## Outputs\n- `feedFound`\n- `feedName`\n- `feedAddressOrId`\n- `chain`\n- `active`\n- `funded`\n- `runwayEstimateDays`\n- `requiredFundingAsset`\n- `estimatedFundingAmount`\n- `actionsTaken`\n- `transactions`\n- `nextMaintenanceRecommendation`\n- `warnings`\n\n## Commands / modes\n\n### discover-feed\nReturn the best matching feed and its state.\n\n### ensure-feed-active\nEnsure feed is active and funded for target runway.\n\n### check-feed-runway\nInspect runway and return top-up recommendation.\n\n### top-up-feed\nExtend funding for an existing feed.\n\n### maintain-feed\nCheck one or more feeds and top up if allowed.\n\n## Safety requirements\n- Never claim a feed is active without a concrete check.\n- Never claim coequal feeds are interchangeable without evidence.\n- Distinguish:\n  - feed exists but unfunded\n  - feed missing\n  - feed exists on another chain only\n  - feed exists but requires manual wallet capability not currently available\n- Log exact blockers instead of vague failure text.\n\n## MVP build plan\n\n### MVP scope\n- single-feed discovery\n- single-feed status inspection\n- single-feed ensure/top-up flow\n- maintenance recommendation output\n\n### Not required in MVP\n- batch optimization across many feeds\n- advanced treasury strategy\n- multi-wallet policy orchestration\n- automatic cron creation\n\n## Dependencies to confirm\n- exact Api3 Market/API access path\n- exact contract or API method to read feed funding/runway\n- exact activation/funding execution flow\n- exact token/payment route for feed funding on supported chains\n\n## Acceptance criteria\n- Given an asset/pair and chain, the skill can identify whether a usable Api3 feed exists.\n- Given a feed and wallet capability, the skill can determine whether it is sufficiently funded.\n- Given insufficient runway and execution rights, the skill can top up or produce exact execution instructions.\n- The skill can report back the resulting active/funded state and next maintenance recommendation.\n\nFile v0.4.3:CHANGELOG.md\n\n# Changelog\n\n## 0.4.0 - 2026-04-28\n\n- clarified that `browser-assisted` funding should hand off to `browser-plan` plus browser execution when the Api3 Market flow is reachable\n- documented that feed readiness must be re-checked after any direct, wrapper, or browser-assisted funding execution before downstream EVK steps continue\n- tightened downstream handoff guidance so agents preserve `fundingExecutionClassification.state` and do not blur deployment success into borrowability proof\n\n## 0.3.0 - 2026-04-22\n\n- synced the packaged skill runtime with the latest repo `api3-feed-manager` implementation\n- added guarded `execute-buy-subscription` support for the first exact executable funding path\n- added execution-mode selection:\n  - `auto`\n  - `direct`\n  - `wrapper` when exact wrapper calldata is safely derivable\n- added machine-usable funding state classification:\n  - `not-needed`\n  - `executable`\n  - `browser-assisted`\n  - `unsupported`\n- updated the skill docs to reflect the current automation boundary and browser-assisted fallback path\n\nFile v0.4.3:package.json\n\n{\n  \"name\": \"api3-feed-manager-skill\",\n  \"version\": \"0.4.0\",\n  \"private\": true,\n  \"description\": \"OpenClaw skill and bundled CLI for Api3 feed discovery, funding-state classification, guarded activation execution, and browser-assisted fallback planning.\",\n  \"type\": \"commonjs\",\n  \"bin\": {\n    \"api3-feed-manager\": \"scripts/bin/api3-feed-manager.js\"\n  },\n  \"files\": [\n    \"SKILL.md\",\n    \"README.md\",\n    \"CHANGELOG.md\",\n    \"references\",\n    \"scripts\"\n  ],\n  \"keywords\": [\n    \"openclaw\",\n    \"skill\",\n    \"api3\",\n    \"oracle\",\n    \"feeds\"\n  ],\n  \"engines\": {\n    \"node\": \">=20\"\n  },\n  \"scripts\": {\n    \"check\": \"node --check scripts/api3-feed-manager.js && node --check scripts/bin/api3-feed-manager.js\"\n  },\n  \"dependencies\": {\n    \"@api3/contracts\": \"^37.0.0\",\n    \"@api3/dapi-management\": \"^4.13.0\",\n    \"ethers\": \"^6.15.0\"\n  }\n}\n\nArchive v0.4.2: 10 files, 35930 bytes\n\nFiles: CHANGELOG.md (1050b), package.json (834b), README.md (1762b), references/part1-architecture-update.md (2479b), references/part1-research.md (14366b), references/part1-skill-spec.md (2977b), scripts/api3-feed-manager.js (91464b), scripts/bin/api3-feed-manager.js (191b), SKILL.md (9561b), _meta.json (136b)\n\nFile v0.4.2:SKILL.md\n\n---\nname: api3-feed-manager\ndescription: Discover, activate, fund, and maintain Api3 data feeds permissionlessly for downstream agent projects. Use when an agent needs a decentralized data feed pricing a blockchain based asset on a supported chain, needs to ensure feed runway for a build or deployment, or must maintain an already-enabled feed over time. Default to discovery, readiness checks, and dry-run planning first, and only use signer-backed execution when the user explicitly asks for it.\nmetadata:\n  clawdis:\n    homepage: https://github.com/daav3/agentic-lending-project\n    author: daav3\n    requires:\n      bins:\n        - node\n      env:\n        - LIVE_SIGNER_ENV\n      config:\n        - request.ensure-feeds.json\n        - request.execute-buy-subscription.json\n    primaryEnv: LIVE_SIGNER_ENV\n---\n\n# Api3 Feed Manager\n\nThis skill is the oracle-enablement layer for agent-built projects that need reliable, decentralized, onchain data feeds.\n\nIt is designed to let agents:\n- find the correct Api3 feed\n- distinguish between feeds that are merely discoverable and feeds that are currently active\n- determine whether a feed is already usable\n- fund/activate it when possible\n- maintain runway for continued operation\n\nwithout requiring manual coordination with the Api3 team.\n\n## When to use\n\nUse this skill when:\n- a project needs a reliable, onchain, decentralized price feed\n- an agent wants to deploy something that depends on a live oracle\n- an existing feed may need a top-up or runway check\n- a downstream skill or app needs feed activation as a prerequisite\n\n## Core modes\n\n### 1. discover-feed\nUse when you need to identify the best Api3 data feed for:\n- an asset\n- a pair\n- a chain\n- a specific oracle use case\n\nExpected output:\n- feed identity\n- chain availability\n- whether it is discoverable\n- whether it appears active/usable\n- whether activation may be needed\n- any ambiguity or missing mapping\n\n### 2. ensure-feed-active\nUse when you know the required feed and want to ensure it has enough funding/runway.\n\nDefault target runway:\n- 90 days\n\nExpected output:\n- current funding/liveness status\n- estimated runway\n- whether funding/top-up is needed\n- execution path or exact transaction instructions\n\n### 3. check-feed-runway\nUse to inspect an already-known feed and estimate maintenance needs.\n\nExpected output:\n- current status\n- remaining runway estimate\n- whether action is required soon\n\n### 4. top-up-feed\nUse when a feed exists but needs more runway.\n\nExpected output:\n- required funding token/amount\n- top-up execution plan\n- resulting status if executed\n\n### 5. maintain-feed\nUse for maintenance mode when one or more project feeds must remain alive.\n\nExpected output:\n- current state per feed\n- top-up recommendation or actions taken\n- next maintenance checkpoint recommendation\n\n## Inputs to gather before acting\n\nCollect these first when available:\n- target chain\n- asset or pair required\n- use case (e.g. lending collateral pricing, borrow asset pricing)\n- desired runway in days\n- whether execution is allowed or discovery-only\n- signer/funder available to the agent\n- explicit operator approval if any real transaction submission is requested\n\n## Operating rules\n\n1. Do not pretend a feed is active without checking.\n2. Distinguish clearly between:\n   - feed missing\n   - feed present but unfunded\n   - feed available on another chain only\n   - feed exists but agent lacks execution capability\n3. Prefer permissionless operation paths.\n4. If a step cannot be done permissionlessly, say exactly why.\n5. Return concrete feed identifiers and maintenance recommendations.\n6. If discovery is ambiguous, surface the ambiguity instead of guessing.\n7. Treat signer-backed execution as a guarded operator action, not a default background step.\n8. Prefer signer material from environment variables or local runtime setup, never from committed files.\n\n## Suggested workflow\n\n### For a new project\n1. Discover feed\n2. Confirm chain/feed suitability\n3. Check whether active/funded\n4. Ensure 90-day runway\n5. Return feed details to downstream builder/deployer\n\n### For an existing project\n1. Check current runway\n2. If below threshold, top up\n3. Return next maintenance recommendation\n\n## Output contract\n\nAim to return structured results containing:\n- `feedFound`\n- `discoverable`\n- `active`\n- `activationPossible`\n- `statusClassification`\n- `feedName`\n- `feedAddressOrId`\n- `chain`\n- `funded`\n- `runwayEstimateDays`\n- `requiredFundingAsset`\n- `estimatedFundingAmount`\n- `actionsTaken`\n- `transactions`\n- `nextMaintenanceRecommendation`\n- `warnings`\n\n## Current implementation status\n\nCurrent honest state:\n- feed discovery and readiness inspection: implemented\n- exact guarded `buySubscription(...)` execution: implemented\n- execution modes:\n  - `direct`\n  - `wrapper` when exact wrapper calldata is derivable safely\n  - `auto`\n- machine-usable funding state classification: implemented\n  - `not-needed`\n  - `executable`\n  - `browser-assisted`\n  - `unsupported`\n- browser-assisted funding should stay automatable where safe\n  - use `browser-plan` to produce the exact Market flow\n  - if the required UI is reachable, execute that plan with the browser tool instead of downgrading to a vague manual handoff\n  - after any funding execution, re-run feed readiness before claiming the feed is ready for downstream oracle or EVK steps\n- browser-assisted funding planning: implemented via `browser-plan`\n\nStill not universal:\n- not every funding path is exact onchain-executable yet\n- some flows still require browser-assisted automation\n- unsupported cases must still fail closed and be reported explicitly\n\nCurrent priorities:\n1. broaden executable funding coverage beyond the first exact family\n2. keep browser-assisted flows automatable where safe\n3. preserve explicit state classification instead of overclaiming support\n4. improve maintenance-mode and multi-feed workflows\n5. keep downstream EVK and Morpho handoffs aligned with the live planner behavior proven in canaries\n\n## Feed-name matching guardrails for downstream lending flows\n\nWhen this skill is used as a prerequisite for EVK or Morpho deployment:\n- prefer a literal exact dAPI name match before any alias-normalized match\n- treat symbol-family aliases as fallback discovery aids, not as reasons to block a live literal feed that already matches the requested asset pair\n- preserve the original requested dAPI name for live readiness checks; only use canonicalized symbols for fallback route derivation when no literal match exists\n- if a literal match is live and readable on-chain, classify that feed as ready even when alias-equivalent feeds also exist\n- only surface ambiguity when the literal-exact bucket itself is ambiguous\n- keep this logic asset-agnostic: the same path should work for whichever supported collateral and borrow assets the planner selects, not just previously tested majors\n\n## Downstream EVK canary handoff\n\nWhen this skill hands off to downstream EVK deployment tooling or canary execution:\n- require a signer-backed dry-run before any real send\n- treat multi-transaction deployment plans as sequential, not parallel\n- if later transactions depend on contracts created earlier in the same plan, wait for each receipt before sending the next transaction\n- if funding landed through the `browser-assisted` branch, execute the returned `browser-plan` when the Market flow is reachable and then re-run readiness before continuing\n- do not collapse `fundingExecutionClassification.state` into a generic “ready”; preserve the exact branch all the way into downstream reporting\n- do not assume `real-send ready` means “safe to fire blind”, it only means the plan has executable payloads and still needs a final operator check\n- if downstream EVK work needs proof of real borrowability, treat that as a separate post-deploy milestone rather than equating deployment success with borrowability\n- if the operator intentionally wants a duplicate or near-duplicate market attempt, require `duplicatePolicy: \"warn-only\"` so the planner keeps the path deployable and emits an explicit warning instead of silently bypassing duplicate protection\n- if the direct pair is unavailable but a supported composition route is live (for example through a shared unit of account such as USD), allow the EVK path to use that composed oracle route rather than failing prematurely\n- keep deployment and verification rules generic across supported asset pairs; do not special-case only the pairs used in earlier canaries\n- after a real send, verify more than submission: confirm nonce movement, status=1 receipts, deployed contract addresses for each oracle leg/wrapper, and final market deployment success before reporting the canary as successful\n\n## Downstream Morpho handoff\n\nWhen this skill hands off to downstream Morpho deployment tooling:\n- keep proxy-first ordering when a communal proxy deploy is required before adapter deploy or market creation\n- keep the same signer, RPC, and nonce assumptions across deploy + verify steps in a single live run\n- support the planner selecting whichever supported collateral/borrow pair is requested, as long as the oracle path resolves cleanly and verification invariants hold\n- do not treat a mined market-create transaction as success unless downstream verification confirms the market exists, params match, `price()` succeeds, and the oracle price is positive\n- persist enough artifact context for the next operator turn: tx hashes, market id, final oracle address, and a short failure-before / success-after note\n\nFile v0.4.2:README.md\n\n# Api3 Feed Manager\n\nAn OpenClaw skill for discovering Api3 feeds, checking whether they are live, classifying the activation/funding path, and executing the currently supported funding flows when possible. Default to discovery, readiness checks, and dry-run planning first; only use signer-backed execution when the operator explicitly asks for it.\n\n## What it helps with\n\n- find supported Api3 chain aliases\n- audit feed coverage across chains\n- separate activatable feeds from retired or delisted ones\n- inspect queue tiers and default activation choices\n- prepare exact `buySubscription(...)` Market contract calls for the supported narrow family\n- execute guarded funding in the supported exact path\n  - `direct`\n  - `wrapper` when exact wrapper calldata is derivable safely\n  - `auto`\n- prefer signer material from environment variables or local runtime setup instead of inline command arguments\n- expose machine-usable funding states:\n  - `not-needed`\n  - `executable`\n  - `browser-assisted`\n  - `unsupported`\n- prepare browser-assisted funding plans when exact execution is not yet available\n\n## What it does not do\n\n- provide universal pure-onchain automation for every funding case\n- pretend retired feeds are still available\n- replace `SKILL.md` as the agent-facing instruction file\n\n## Main files\n\n- `SKILL.md` - instructions for the agent\n- `scripts/bin/api3-feed-manager.js` - local CLI entrypoint\n- `scripts/api3-feed-manager.js` - bundled runtime\n\n## Quick examples\n\n```bash\nnode ./scripts/bin/api3-feed-manager.js supported-chains\nnode ./scripts/bin/api3-feed-manager.js coverage-audit --chain arbitrum --limit 20\nnode ./scripts/bin/api3-feed-manager.js queue-plan --dapi-name ETH/USD --rpc-url https://arb1.arbitrum.io/rpc --chain arbitrum\n```\n\nFile v0.4.2:_meta.json\n\n{\n  \"ownerId\": \"kn79961pqqa20q5jwn60zjkxzs84yc3w\",\n  \"slug\": \"api3-feed-manager\",\n  \"version\": \"0.4.2\",\n  \"publishedAt\": 1778070375070\n}\n\nFile v0.4.2:references/part1-architecture-update.md\n\n# Part 1 Architecture Update\n\n## Important correction\n\nFurther review shows the Part 1 skill should not be modeled only as a generic \"feed funding helper\".\n\nHowever, for the agent use case in this project, the correct practical model is **not** per-dApp proxy deployment.\n\n## Agent-specific constraint\n\nFor these agents, we should use the **generic proxy on Api3 Market**.\n\nReason:\n- OEV can accrue to Api3 in this mode\n- permissionless deployment of individual dApp-specific proxies is not currently available for our intended fully permissionless agent flow\n\nSo the skill should optimize for what agents can actually do today, not for a cleaner but unavailable theoretical path.\n\n## Revised role of the skill\n\nThe skill should primarily do four things:\n\n1. discover the relevant feed on Api3 Market\n2. classify whether the feed is active / usable / non-operational\n3. return the correct **generic Market proxy** or integration artifact for downstream agents\n4. when needed, help move a known but inactive feed toward usability through funding/activation paths\n\n## Why this matters\n\nA downstream agent using this skill should be able to ask:\n- \"I need an Api3 price feed for asset X on chain Y\"\n\nand get back:\n- whether the feed is known on Market\n- whether it appears operational\n- the generic Market proxy / feed integration details to use\n- whether the feed is already usable\n- if not usable, what is missing (e.g. activation/funding)\n\n## What the skill should not assume\n\nThe skill should **not** assume:\n- that a dApp-specific Api3ReaderProxyV1 can be permissionlessly deployed for the agent today\n- that the ideal OEV-capturing deployment pattern is available to agent users right now\n\n## Design implication\n\nThe architecture should now prioritize:\n1. live feed discovery from Api3 Market metadata\n2. readiness classification\n3. generic proxy resolution / integration artifact return\n4. non-operational feed activation/funding support\n\n## Updated implementation direction\n\nNear-term implementation should focus on:\n- improving live discovery matching\n- extracting/returning the generic Market proxy path where possible\n- identifying discoverable but non-operational feeds\n- only then extending toward activation/funding workflows\n\n## Why this is the correct compromise\n\nThis design is less theoretically perfect than per-dApp proxy deployment, but it matches the actual permissionless capability available to agent users now.\n\nThat is the right tradeoff for this project.\n\nFile v0.4.2:references/part1-research.md\n\n# Part 1 Research: Api3 Market discovery, readiness, and funding flows\n\n## Objective\n\nMap what an agent can discover, verify, fund, and maintain today through Api3 Market, and turn that into a concrete MVP contract for `api3-feed-manager`.\n\n## Sources reviewed\n\nPrimary docs and surfaces reviewed for this pass:\n- https://docs.api3.org/dapps/quickstart/\n- https://docs.api3.org/dapps/integration/\n- https://docs.api3.org/dapps/integration/contract-integration.html\n- https://docs.api3.org/dapps/oev-rewards/\n- https://docs.api3.org/oev-searchers/in-depth/data-feeds/\n- `@api3/contracts` in this repo's dependencies\n- live Api3 Market pages in browser\n\n## Executive summary\n\nThe good news is that Part 1 is more concrete than the earlier draft suggested.\n\nA workable agent flow already exists:\n1. discover candidate feeds on Api3 Market by chain and pair\n2. determine whether the feed is already active on that network\n3. if active, return the integration proxy and avoid paying again\n4. if inactive, purchase a 3-month plan through Api3 Market\n5. return the proxy, active state, and renewal recommendation\n\nThe most important implementation decision is to use a **layered source-of-truth model**:\n- **Api3 Market** for human-readable discovery and commercial state\n- **Api3 contracts** for canonical dAPI to data-feed resolution\n- **AirseekerRegistry + Signed APIs** for underlying beacon composition and off-chain signed data inspection\n- **Api3ReaderProxyV1 read()** for the final integration-ready state check\n\nFor the project, the safest MVP remains:\n- default to the **communal/generic Api3ReaderProxyV1 path** for agents\n- treat dApp-specific OEV-enabled proxies as a later enhancement unless we explicitly verify the self-serve path end to end\n\n## Confirmed findings\n\n### 1. Api3 Market is the primary discovery surface\n\nFrom the quickstart and live Market UI:\n- Api3 Market serves a catalog of feeds by network\n- the network page includes search, featured active feeds, and a full catalog\n- **all feeds are inactive by default**\n- if a feed is already active, the user lands on the data-feed page directly\n- if a feed is inactive, the user lands on the activation page first\n\nThis gives us a practical first discovery model:\n- search by `chain + pair`\n- determine whether the feed is already active\n- only enter purchase flow when activation is required\n\n### 2. Activation is a plan purchase, not a low-level oracle-admin flow\n\nApi3 Market exposes activation as a commercial subscription flow:\n- mainnets use **3-month plans**\n- testnets use **7-day plans**\n- plan purchase immediately activates a feed if inactive\n- if active already, purchase extends or upgrades the queued operating plan\n- the user chooses the deviation threshold subscription tier\n- the heartbeat is fixed at **24 hours**\n\nAdditional clarification from an Api3 developer:\n- each data feed has its **own wallet setup**, but there is only **one sponsor wallet per feed**\n- the effective deviation threshold is determined by the feed's **subscriptions queue**, where **smaller thresholds get priority**\n- this means the skill should model deviation selection as a queue/subscription concern, not as a separate per-wallet configuration surface\n\nOffered deviation thresholds in docs:\n- 5%\n- 2.5%\n- 1%\n- 0.5%\n- 0.25%\n\nImportant operational behavior from docs:\n- once a plan is purchased, Api3 guarantees those update parameters for the purchased plan duration\n- after expiry, the feed stops being upheld\n- users are responsible for renewing plans if they want continuous service\n- if a feed is already active, leftover prepaid value can roll into the next purchase as a discount\n\n### 3. The pricing model is concrete enough for an MVP\n\nDocs state that prices are based on estimated operational cost:\n- historical gas cost of updates\n- expected update frequency for the chosen deviation threshold\n- operating duration\n\nDocs also state:\n- prices are charged at estimated operating cost, with a minimum of `$0.05/day`\n- overestimates roll into future discounts for the same network-feed pair\n- on testnets, updates may stop if payment runs out even before plan expiry\n\nLive Market inspection on Arbitrum showed an activation page quoting total cost directly in **ETH** for that chain.\n\nWorking conclusion for the skill:\n- we can treat funding as a **time-bound plan purchase**\n- the skill should target **90 days on mainnets** by default\n- the exact payment asset appears to be the chain-native gas token in the UI at least on Arbitrum, but that still needs explicit per-chain confirmation before we hardcode it as universal behavior\n\n### 4. There are two proxy integration modes\n\nThe docs are very clear that integrations consume **Api3ReaderProxyV1**.\n\nFrom the integration docs:\n- `read()` returns `(int224 value, uint32 timestamp)`\n- Api3 data feeds have **18 decimals**\n- `Api3ReaderProxyV1` also implements Chainlink's `AggregatorV2V3Interface`\n\nFrom the Market integration docs:\n- **Skip OEV Rewards** shows one `Api3ReaderProxyV1` address\n- **Earn OEV Rewards** shows a different `Api3ReaderProxyV1` address, and may require a proxy deployment step\n\nFrom `@api3/contracts` in this repo's dependencies:\n- the package exposes **`computeCommunalApi3ReaderProxyV1Address`**\n- it also exposes **`computeDappSpecificApi3ReaderProxyV1Address`**\n- and **`unsafeComputeDappId`**\n\nThat is strong evidence that the product surface really does distinguish between:\n- a **communal/generic proxy path**\n- a **dApp-specific OEV-enabled proxy path**\n\nFor this project, that means the Part 1 MVP should:\n- return the **communal proxy** by default\n- treat dApp-specific OEV enrollment as optional/advanced\n- avoid assuming that the OEV-specific path is the universal default for agent users\n\n### 5. Canonical data-feed resolution is contract-driven under the hood\n\nThe strongest technical resolution path came from the Api3 data-feed docs.\n\nThe canonical path is:\n1. encode the dAPI name, e.g. `ETH/USD`\n2. hash it\n3. call `Api3ServerV1.dapiNameHashToDataFeedId(...)`\n4. call `AirseekerRegistry.dataFeedIdToDetails(...)`\n5. decode the result as either:\n   - a single beacon `(address airnode, bytes32 templateId)`, or\n   - a beacon set `(address[] airnodes, bytes32[] templateIds)`\n\nThis gives the skill a proper technical backplane behind Market discovery.\n\nMeaning:\n- Market should be used to find the likely feed and active/inactive state\n- contract reads should be used to canonicalize the underlying feed identity\n- AirseekerRegistry gives the underlying beacon composition for deeper verification\n\n### 6. Signed APIs give a public off-chain inspection surface\n\nApi3 exposes public Signed API endpoints:\n- base feed: `https://signed-api.api3.org/public/<airnode>`\n- OEV feed: `https://signed-api.api3.org/public-oev/<airnode>`\n\nThe docs show the response includes:\n- `count`\n- `data`\n- per-entry fields including `airnode`, `templateId`, `timestamp`, `encodedValue`, and `signature`\n\nDocs also state:\n- base feeds are publicly updateable with signed data\n- OEV feeds are real-time and tied to the OEV mechanism\n- base feed data is served with delay in the OEV design\n\nFor the MVP, Signed APIs are useful for:\n- inspecting whether the underlying beacon data exists publicly\n- checking that the expected airnode/template pairs are live\n- validating that the feed is not merely listed but has recent signed data underneath it\n\n### 7. Sponsor-wallet complexity does not appear to be the user-facing activation primitive\n\nEarlier thinking over-indexed on sponsor wallets.\n\nAfter this pass, the more accurate framing is:\n- sponsor-wallet concepts are part of underlying Airnode request sponsorship mechanics\n- **Api3 Market activation docs do not present sponsor-wallet management as the normal user workflow for activating a Market feed**\n- an Api3 developer clarified that there is **one sponsor wallet per feed**, not one sponsor wallet per subscription tier or deviation choice\n- the user-facing flow is still purchase-based: choose parameters, connect wallet, buy plan\n\nSo for Part 1:\n- sponsor-wallet logic should **not** be treated as the main agent UX\n- but the internal model should assume a **stable sponsor wallet per feed**\n- deviation thresholds should be modeled as subscription-queue priorities, where smaller thresholds can win precedence\n- if sponsor-wallet logic becomes relevant, it should be treated as protocol background or an implementation detail, not the first-class interaction model\n\n## Recommended readiness model for the skill\n\nThe skill should classify feeds into these states.\n\n### `unavailable`\nUse when:\n- the feed is not discoverable on Market for the target chain, and/or\n- canonical contract resolution does not produce usable data-feed details\n\n### `listed_inactive`\nUse when:\n- the feed is listed on Market for the target chain\n- but no active plan is currently upholding it\n- the next required action is purchase/activation\n\n### `active_communal_usable`\nUse when:\n- the feed is active on Market\n- the communal/generic `Api3ReaderProxyV1` path is available\n- a contract-level read succeeds and returns a sane positive value\n\n### `active_but_needs_deeper_verification`\nUse when:\n- Market suggests the feed is active\n- but proxy resolution or on-chain verification is incomplete\n- the feed should not yet be reported as safely integration-ready\n\n### `dapp_specific_oev_path_available`\nUse when:\n- the feed is active or activatable\n- and the dApp-specific OEV path is available\n- but this should be modeled as optional and separate from the communal default\n\n### `non_operational_or_inconsistent`\nUse when:\n- the feed is listed or resolvable\n- but the proxy read, data-feed details, or signed-data checks do not line up cleanly\n\n## Recommended MVP source-of-truth strategy\n\n### Discovery layer\nUse Api3 Market as the first pass for:\n- chain availability\n- pair naming\n- active vs inactive state\n- current commercial plan options\n\n### Canonical resolution layer\nUse on-chain contract reads for:\n- dAPI name to data-feed ID resolution\n- data-feed details decoding\n- beacon vs beacon-set composition\n\n### Verification layer\nUse two checks:\n1. Signed API inspection for underlying beacon freshness\n2. `Api3ReaderProxyV1.read()` for integration-ready consumption\n\nThis is much better than relying only on either:\n- the UI, or\n- raw contracts without Market context\n\n## Activation and maintenance flow for the skill\n\n### `discover-feed`\nShould return:\n- requested chain and pair\n- whether the feed is listed on Market\n- whether it is active now\n- communal proxy address if derivable\n- whether the dApp-specific OEV path is available or intentionally skipped\n- any ambiguity in naming or chain coverage\n\n### `ensure-feed-active`\nShould do this sequence:\n1. discover the feed on Market\n2. if already active, skip purchase and return the proxy\n3. if inactive, direct the user or wallet-capable execution path into Market purchase flow\n4. target a **3-month mainnet plan** by default\n5. after purchase, verify proxy readability before reporting success\n\n### `check-feed-runway`\nThe docs clearly describe expiration behavior, but this pass did **not** uncover a documented stable API for querying remaining runway programmatically.\n\nSo the current implementation assumption should be:\n- Market UI is the visible source for expiration today\n- a programmatic runway check still needs to be pinned down before the skill can claim full automation here\n\n### `maintain-feed`\nFor MVP, this should be conservative:\n- if expiry information is available, recommend renewal before expiry\n- if expiry information is not yet programmatically available, report that limitation explicitly instead of pretending the skill can automate it safely\n\n## Blockers and unresolved questions\n\nThese are the real blockers that remain after this pass.\n\n### 1. Programmatic Market API stability is still unclear\nWe now know how the UI behaves, but we do **not** yet have a confirmed, documented Market API contract that the skill can safely depend on for catalog and expiry queries.\n\n### 2. Exact programmatic expiry/runway path is not yet pinned down\nDocs describe expiry and renewal behavior clearly, but I have not yet confirmed the stable underlying API or contract field that exposes remaining runway for automation.\n\n### 3. Exact per-chain payment asset still needs confirmation\nThe Arbitrum activation flow clearly quoted cost in ETH, which strongly suggests native gas-token payment on that chain. But I have not yet confirmed the rule across all supported networks.\n\n### 4. OEV self-serve flow needs a stricter go/no-go decision\nDocs imply that self-serve OEV-enabled integration can be completed through Api3 Market, but the project should still default to the communal path until we explicitly test and trust the dApp-specific flow for agent usage.\n\n### 5. Contract address sourcing needs to be nailed down in implementation\nWe have the resolution functions and proxy computation helpers, but the implementation still needs a clean source for the correct chain-specific `Api3ServerV1` and `AirseekerRegistry` addresses.\n\n## Implications for issue #5\n\nIssue `#5` should now be built around this narrower MVP:\n- default to communal proxy resolution\n- use Market for discovery and active/inactive classification\n- use contract reads for canonical mapping and verification\n- only support purchase guidance or execution once the Market transaction path is confirmed cleanly in code\n- keep dApp-specific OEV mode behind an explicit opt-in\n\n## Recommended immediate next implementation steps\n\n1. build a small discovery probe that accepts `chain + pair` and returns Market match candidates\n2. wire canonical resolution using `dapiNameHashToDataFeedId` and `dataFeedIdToDetails`\n3. add communal proxy computation using `@api3/contracts`\n4. add a verification step that calls `read()` on the resolved proxy\n5. defer full maintenance automation until expiry/runway can be queried programmatically with confidence\n\n## Bottom line\n\nIssue `#4` is now concrete enough to unblock MVP design.\n\nThe Part 1 skill should not be a vague \"feed funding helper\".\nIt should be a **discovery + resolution + activation-decision + proxy-return** tool with a conservative verification layer.\n\nThat is enough to move into implementation without hand-waving, while keeping the remaining unknowns explicit instead of burying them.\n\nFile v0.4.2:references/part1-skill-spec.md\n\n# Part 1 Skill Spec: Api3 Feed Activation Skill\n\n## Skill name (working)\n`api3-feed-manager`\n\n## Purpose\nEnable OpenClaw agents to discover, activate, fund, and maintain Api3 data feeds permissionlessly for downstream applications.\n\n## User stories\n\n### Story 1\nAs an agent building an app that needs a price feed,\nI want to discover the correct Api3 feed on a target chain,\nso I can use it without human oracle coordination.\n\n### Story 2\nAs an agent deploying a lending market,\nI want to ensure the required Api3 feed is active and funded for ~3 months,\nso my market can operate continuously.\n\n### Story 3\nAs an agent maintaining deployed systems,\nI want to check runway and top up feed funding before expiration,\nso dependent systems do not silently degrade.\n\n## Inputs\n\n### Required core inputs\n- `chain`\n- `asset` or `pair`\n- `useCase`\n\n### Optional inputs\n- `quoteAsset`\n- `runwayDays` (default 90)\n- `minimumRunwayDays`\n- `walletReference`\n- `execute` (boolean, default false for discovery/check flows)\n- `allowTopUp` (boolean)\n\n## Outputs\n- `feedFound`\n- `feedName`\n- `feedAddressOrId`\n- `chain`\n- `active`\n- `funded`\n- `runwayEstimateDays`\n- `requiredFundingAsset`\n- `estimatedFundingAmount`\n- `actionsTaken`\n- `transactions`\n- `nextMaintenanceRecommendation`\n- `warnings`\n\n## Commands / modes\n\n### discover-feed\nReturn the best matching feed and its state.\n\n### ensure-feed-active\nEnsure feed is active and funded for target runway.\n\n### check-feed-runway\nInspect runway and return top-up recommendation.\n\n### top-up-feed\nExtend funding for an existing feed.\n\n### maintain-feed\nCheck one or more feeds and top up if allowed.\n\n## Safety requirements\n- Never claim a feed is active without a concrete check.\n- Never claim coequal feeds are interchangeable without evidence.\n- Distinguish:\n  - feed exists but unfunded\n  - feed missing\n  - feed exists on another chain only\n  - feed exists but requires manual wallet capability not currently available\n- Log exact blockers instead of vague failure text.\n\n## MVP build plan\n\n### MVP scope\n- single-feed discovery\n- single-feed status inspection\n- single-feed ensure/top-up flow\n- maintenance recommendation output\n\n### Not required in MVP\n- batch optimization across many feeds\n- advanced treasury strategy\n- multi-wallet policy orchestration\n- automatic cron creation\n\n## Dependencies to confirm\n- exact Api3 Market/API access path\n- exact contract or API method to read feed funding/runway\n- exact activation/funding execution flow\n- exact token/payment route for feed funding on supported chains\n\n## Acceptance criteria\n- Given an asset/pair and chain, the skill can identify whether a usable Api3 feed exists.\n- Given a feed and wallet capability, the skill can determine whether it is sufficiently funded.\n- Given insufficient runway and execution rights, the skill can top up or produce exact execution instructions.\n- The skill can report back the resulting active/funded state and next maintenance recommendation.\n\nFile v0.4.2:CHANGELOG.md\n\n# Changelog\n\n## 0.4.0 - 2026-04-28\n\n- clarified that `browser-assisted` funding should hand off to `browser-plan` plus browser execution when the Api3 Market flow is reachable\n- documented that feed readiness must be re-checked after any direct, wrapper, or browser-assisted funding execution before downstream EVK steps continue\n- tightened downstream handoff guidance so agents preserve `fundingExecutionClassification.state` and do not blur deployment success into borrowability proof\n\n## 0.3.0 - 2026-04-22\n\n- synced the packaged skill runtime with the latest repo `api3-feed-manager` implementation\n- added guarded `execute-buy-subscription` support for the first exact executable funding path\n- added execution-mode selection:\n  - `auto`\n  - `direct`\n  - `wrapper` when exact wrapper calldata is safely derivable\n- added machine-usable funding state classification:\n  - `not-needed`\n  - `executable`\n  - `browser-assisted`\n  - `unsupported`\n- updated the skill docs to reflect the current automation boundary and browser-assisted fallback path\n\nFile v0.4.2:package.json\n\n{\n  \"name\": \"api3-feed-manager-skill\",\n  \"version\": \"0.4.0\",\n  \"private\": true,\n  \"description\": \"OpenClaw skill and bundled CLI for Api3 feed discovery, funding-state classification, guarded activation execution, and browser-assisted fallback planning.\",\n  \"type\": \"commonjs\",\n  \"bin\": {\n    \"api3-feed-manager\": \"scripts/bin/api3-feed-manager.js\"\n  },\n  \"files\": [\n    \"SKILL.md\",\n    \"README.md\",\n    \"CHANGELOG.md\",\n    \"references\",\n    \"scripts\"\n  ],\n  \"keywords\": [\n    \"openclaw\",\n    \"skill\",\n    \"api3\",\n    \"oracle\",\n    \"feeds\"\n  ],\n  \"engines\": {\n    \"node\": \">=20\"\n  },\n  \"scripts\": {\n    \"check\": \"node --check scripts/api3-feed-manager.js && node --check scripts/bin/api3-feed-manager.js\"\n  },\n  \"dependencies\": {\n    \"@api3/contracts\": \"^37.0.0\",\n    \"@api3/dapi-management\": \"^4.13.0\",\n    \"ethers\": \"^6.15.0\"\n  }\n}\n\nArchive v0.4.1: 10 files, 35163 bytes\n\nFiles: CHANGELOG.md (1050b), package.json (834b), README.md (1508b), references/part1-architecture-update.md (2479b), references/part1-research.md (14366b), references/part1-skill-spec.md (2977b), scripts/api3-feed-manager.js (90541b), scripts/bin/api3-feed-manager.js (191b), SKILL.md (8832b), _meta.json (136b)\n\nFile v0.4.1:SKILL.md\n\n---\nname: api3-feed-manager\ndescription: Discover, activate, fund, and maintain Api3 data feeds permissionlessly for downstream agent projects. Use when an agent needs a decentralized data feed pricing a blockchain based asset on a supported chain, needs to ensure feed runway for a build or deployment, or must maintain an already-enabled feed over time.\n---\n\n# Api3 Feed Manager\n\nThis skill is the oracle-enablement layer for agent-built projects that need reliable, decentralized, onchain data feeds.\n\nIt is designed to let agents:\n- find the correct Api3 feed\n- distinguish between feeds that are merely discoverable and feeds that are currently active\n- determine whether a feed is already usable\n- fund/activate it when possible\n- maintain runway for continued operation\n\nwithout requiring manual coordination with the Api3 team.\n\n## When to use\n\nUse this skill when:\n- a project needs a reliable, onchain, decentralized price feed\n- an agent wants to deploy something that depends on a live oracle\n- an existing feed may need a top-up or runway check\n- a downstream skill or app needs feed activation as a prerequisite\n\n## Core modes\n\n### 1. discover-feed\nUse when you need to identify the best Api3 data feed for:\n- an asset\n- a pair\n- a chain\n- a specific oracle use case\n\nExpected output:\n- feed identity\n- chain availability\n- whether it is discoverable\n- whether it appears active/usable\n- whether activation may be needed\n- any ambiguity or missing mapping\n\n### 2. ensure-feed-active\nUse when you know the required feed and want to ensure it has enough funding/runway.\n\nDefault target runway:\n- 90 days\n\nExpected output:\n- current funding/liveness status\n- estimated runway\n- whether funding/top-up is needed\n- execution path or exact transaction instructions\n\n### 3. check-feed-runway\nUse to inspect an already-known feed and estimate maintenance needs.\n\nExpected output:\n- current status\n- remaining runway estimate\n- whether action is required soon\n\n### 4. top-up-feed\nUse when a feed exists but needs more runway.\n\nExpected output:\n- required funding token/amount\n- top-up execution plan\n- resulting status if executed\n\n### 5. maintain-feed\nUse for maintenance mode when one or more project feeds must remain alive.\n\nExpected output:\n- current state per feed\n- top-up recommendation or actions taken\n- next maintenance checkpoint recommendation\n\n## Inputs to gather before acting\n\nCollect these first when available:\n- target chain\n- asset or pair required\n- use case (e.g. lending collateral pricing, borrow asset pricing)\n- desired runway in days\n- whether execution is allowed or discovery-only\n- wallet/funder available to the agent\n\n## Operating rules\n\n1. Do not pretend a feed is active without checking.\n2. Distinguish clearly between:\n   - feed missing\n   - feed present but unfunded\n   - feed available on another chain only\n   - feed exists but agent lacks execution capability\n3. Prefer permissionless operation paths.\n4. If a step cannot be done permissionlessly, say exactly why.\n5. Return concrete feed identifiers and maintenance recommendations.\n6. If discovery is ambiguous, surface the ambiguity instead of guessing.\n\n## Suggested workflow\n\n### For a new project\n1. Discover feed\n2. Confirm chain/feed suitability\n3. Check whether active/funded\n4. Ensure 90-day runway\n5. Return feed details to downstream builder/deployer\n\n### For an existing project\n1. Check current runway\n2. If below threshold, top up\n3. Return next maintenance recommendation\n\n## Output contract\n\nAim to return structured results containing:\n- `feedFound`\n- `discoverable`\n- `active`\n- `activationPossible`\n- `statusClassification`\n- `feedName`\n- `feedAddressOrId`\n- `chain`\n- `funded`\n- `runwayEstimateDays`\n- `requiredFundingAsset`\n- `estimatedFundingAmount`\n- `actionsTaken`\n- `transactions`\n- `nextMaintenanceRecommendation`\n- `warnings`\n\n## Current implementation status\n\nCurrent honest state:\n- feed discovery and readiness inspection: implemented\n- exact guarded `buySubscription(...)` execution: implemented\n- execution modes:\n  - `direct`\n  - `wrapper` when exact wrapper calldata is derivable safely\n  - `auto`\n- machine-usable funding state classification: implemented\n  - `not-needed`\n  - `executable`\n  - `browser-assisted`\n  - `unsupported`\n- browser-assisted funding should stay automatable where safe\n  - use `browser-plan` to produce the exact Market flow\n  - if the required UI is reachable, execute that plan with the browser tool instead of downgrading to a vague manual handoff\n  - after any funding execution, re-run feed readiness before claiming the feed is ready for downstream oracle or EVK steps\n- browser-assisted funding planning: implemented via `browser-plan`\n\nStill not universal:\n- not every funding path is exact onchain-executable yet\n- some flows still require browser-assisted automation\n- unsupported cases must still fail closed and be reported explicitly\n\nCurrent priorities:\n1. broaden executable funding coverage beyond the first exact family\n2. keep browser-assisted flows automatable where safe\n3. preserve explicit state classification instead of overclaiming support\n4. improve maintenance-mode and multi-feed workflows\n5. keep downstream EVK and Morpho handoffs aligned with the live planner behavior proven in canaries\n\n## Feed-name matching guardrails for downstream lending flows\n\nWhen this skill is used as a prerequisite for EVK or Morpho deployment:\n- prefer a literal exact dAPI name match before any alias-normalized match\n- treat symbol-family aliases as fallback discovery aids, not as reasons to block a live literal feed that already matches the requested asset pair\n- preserve the original requested dAPI name for live readiness checks; only use canonicalized symbols for fallback route derivation when no literal match exists\n- if a literal match is live and readable on-chain, classify that feed as ready even when alias-equivalent feeds also exist\n- only surface ambiguity when the literal-exact bucket itself is ambiguous\n- keep this logic asset-agnostic: the same path should work for whichever supported collateral and borrow assets the planner selects, not just previously tested majors\n\n## Downstream EVK canary handoff\n\nWhen this skill hands off to downstream EVK deployment tooling or canary execution:\n- require a signer-backed dry-run before any real send\n- treat multi-transaction deployment plans as sequential, not parallel\n- if later transactions depend on contracts created earlier in the same plan, wait for each receipt before sending the next transaction\n- if funding landed through the `browser-assisted` branch, execute the returned `browser-plan` when the Market flow is reachable and then re-run readiness before continuing\n- do not collapse `fundingExecutionClassification.state` into a generic “ready”; preserve the exact branch all the way into downstream reporting\n- do not assume `real-send ready` means “safe to fire blind”, it only means the plan has executable payloads and still needs a final operator check\n- if downstream EVK work needs proof of real borrowability, treat that as a separate post-deploy milestone rather than equating deployment success with borrowability\n- if the operator intentionally wants a duplicate or near-duplicate market attempt, require `duplicatePolicy: \"warn-only\"` so the planner keeps the path deployable and emits an explicit warning instead of silently bypassing duplicate protection\n- if the direct pair is unavailable but a supported composition route is live (for example through a shared unit of account such as USD), allow the EVK path to use that composed oracle route rather than failing prematurely\n- keep deployment and verification rules generic across supported asset pairs; do not special-case only the pairs used in earlier canaries\n- after a real send, verify more than submission: confirm nonce movement, status=1 receipts, deployed contract addresses for each oracle leg/wrapper, and final market deployment success before reporting the canary as successful\n\n## Downstream Morpho handoff\n\nWhen this skill hands off to downstream Morpho deployment tooling:\n- keep proxy-first ordering when a communal proxy deploy is required before adapter deploy or market creation\n- keep the same signer, RPC, and nonce assumptions across deploy + verify steps in a single live run\n- support the planner selecting whichever supported collateral/borrow pair is requested, as long as the oracle path resolves cleanly and verification invariants hold\n- do not treat a mined market-create transaction as success unless downstream verification confirms the market exists, params match, `price()` succeeds, and the oracle price is positive\n- persist enough artifact context for the next operator turn: tx hashes, market id, final oracle address, and a short failure-before / success-after note\n\nFile v0.4.1:README.md\n\n# Api3 Feed Manager\n\nAn OpenClaw skill for discovering Api3 feeds, checking whether they are live, classifying the activation/funding path, and executing the currently supported funding flows when possible.\n\n## What it helps with\n\n- find supported Api3 chain aliases\n- audit feed coverage across chains\n- separate activatable feeds from retired or delisted ones\n- inspect queue tiers and default activation choices\n- prepare exact `buySubscription(...)` Market contract calls for the supported narrow family\n- execute guarded funding in the supported exact path\n  - `direct`\n  - `wrapper` when exact wrapper calldata is derivable safely\n  - `auto`\n- expose machine-usable funding states:\n  - `not-needed`\n  - `executable`\n  - `browser-assisted`\n  - `unsupported`\n- prepare browser-assisted funding plans when exact execution is not yet available\n\n## What it does not do\n\n- provide universal pure-onchain automation for every funding case\n- pretend retired feeds are still available\n- replace `SKILL.md` as the agent-facing instruction file\n\n## Main files\n\n- `SKILL.md` - instructions for the agent\n- `scripts/bin/api3-feed-manager.js` - local CLI entrypoint\n- `scripts/api3-feed-manager.js` - bundled runtime\n\n## Quick examples\n\n```bash\nnode ./scripts/bin/api3-feed-manager.js supported-chains\nnode ./scripts/bin/api3-feed-manager.js coverage-audit --chain arbitrum --limit 20\nnode ./scripts/bin/api3-feed-manager.js queue-plan --dapi-name ETH/USD --rpc-url https://arb1.arbitrum.io/rpc --chain arbitrum\n```\n\nFile v0.4.1:_meta.json\n\n{\n  \"ownerId\": \"kn79961pqqa20q5jwn60zjkxzs84yc3w\",\n  \"slug\": \"api3-feed-manager\",\n  \"version\": \"0.4.1\",\n  \"publishedAt\": 1778069883406\n}\n\nFile v0.4.1:references/part1-architecture-update.md\n\n# Part 1 Architecture Update\n\n## Important correction\n\nFurther review shows the Part 1 skill should not be modeled only as a generic \"feed funding helper\".\n\nHowever, for the agent use case in this project, the correct practical model is **not** per-dApp proxy deployment.\n\n## Agent-specific constraint\n\nFor these agents, we should use the **generic proxy on Api3 Market**.\n\nReason:\n- OEV can accrue to Api3 in this mode\n- permissionless deployment of individual dApp-specific proxies is not currently available for our intended fully permissionless agent flow\n\nSo the skill should optimize for what agents can actually do today, not for a cleaner but unavailable theoretical path.\n\n## Revised role of the skill\n\nThe skill should primarily do four things:\n\n1. discover the relevant feed on Api3 Market\n2. classify whether the feed is active / usable / non-operational\n3. return the correct **generic Market proxy** or integration artifact for downstream agents\n4. when needed, help move a known but inactive feed toward usability through funding/activation paths\n\n## Why this matters\n\nA downstream agent using this skill should be able to ask:\n- \"I need an Api3 price feed for asset X on chain Y\"\n\nand get back:\n- whether the feed is known on Market\n- whether it appears operational\n- the generic Market proxy / feed integration details to use\n- whether the feed is already usable\n- if not usable, what is missing (e.g. activation/funding)\n\n## What the skill should not assume\n\nThe skill should **not** assume:\n- that a dApp-specific Api3ReaderProxyV1 can be permissionlessly deployed for the agent today\n- that the ideal OEV-capturing deployment pattern is available to agent users right now\n\n## Design implication\n\nThe architecture should now prioritize:\n1. live feed discovery from Api3 Market metadata\n2. readiness classification\n3. generic proxy resolution / integration artifact return\n4. non-operational feed activation/funding support\n\n## Updated implementation direction\n\nNear-term implementation should focus on:\n- improving live discovery matching\n- extracting/returning the generic Market proxy path where possible\n- identifying discoverable but non-operational feeds\n- only then extending toward activation/funding workflows\n\n## Why this is the correct compromise\n\nThis design is less theoretically perfect than per-dApp proxy deployment, but it matches the actual permissionless capability available to agent users now.\n\nThat is the right tradeoff for this project.\n\nFile v0.4.1:references/part1-research.md\n\n# Part 1 Research: Api3 Market discovery, readiness, and funding flows\n\n## Objective\n\nMap what an agent can discover, verify, fund, and maintain today through Api3 Market, and turn that into a concrete MVP contract for `api3-feed-manager`.\n\n## Sources reviewed\n\nPrimary docs and surfaces reviewed for this pass:\n- https://docs.api3.org/dapps/quickstart/\n- https://docs.api3.org/dapps/integration/\n- https://docs.api3.org/dapps/integration/contract-integration.html\n- https://docs.api3.org/dapps/oev-rewards/\n- https://docs.api3.org/oev-searchers/in-depth/data-feeds/\n- `@api3/contracts` in this repo's dependencies\n- live Api3 Market pages in browser\n\n## Executive summary\n\nThe good news is that Part 1 is more concrete than the earlier draft suggested.\n\nA workable agent flow already exists:\n1. discover candidate feeds on Api3 Market by chain and pair\n2. determine whether the feed is already active on that network\n3. if active, return the integration proxy and avoid paying again\n4. if inactive, purchase a 3-month plan through Api3 Market\n5. return the proxy, active state, and renewal recommendation\n\nThe most important implementation decision is to use a **layered source-of-truth model**:\n- **Api3 Market** for human-readable discovery and commercial state\n- **Api3 contracts** for canonical dAPI to data-feed resolution\n- **AirseekerRegistry + Signed APIs** for underlying beacon composition and off-chain signed data inspection\n- **Api3ReaderProxyV1 read()** for the final integration-ready state check\n\nFor the project, the safest MVP remains:\n- default to the **communal/generic Api3ReaderProxyV1 path** for agents\n- treat dApp-specific OEV-enabled proxies as a later enhancement unless we explicitly verify the self-serve path end to end\n\n## Confirmed findings\n\n### 1. Api3 Market is the primary discovery surface\n\nFrom the quickstart and live Market UI:\n- Api3 Market serves a catalog of feeds by network\n- the network page includes search, featured active feeds, and a full catalog\n- **all feeds are inactive by default**\n- if a feed is already active, the user lands on the data-feed page directly\n- if a feed is inactive, the user lands on the activation page first\n\nThis gives us a practical first discovery model:\n- search by `chain + pair`\n- determine whether the feed is already active\n- only enter purchase flow when activation is required\n\n### 2. Activation is a plan purchase, not a low-level oracle-admin flow\n\nApi3 Market exposes activation as a commercial subscription flow:\n- mainnets use **3-month plans**\n- testnets use **7-day plans**\n- plan purchase immediately activates a feed if inactive\n- if active already, purchase extends or upgrades the queued operating plan\n- the user chooses the deviation threshold subscription tier\n- the heartbeat is fixed at **24 hours**\n\nAdditional clarification from an Api3 developer:\n- each data feed has its **own wallet setup**, but there is only **one sponsor wallet per feed**\n- the effective deviation threshold is determined by the feed's **subscriptions queue**, where **smaller thresholds get priority**\n- this means the skill should model deviation selection as a queue/subscription concern, not as a separate per-wallet configuration surface\n\nOffered deviation thresholds in docs:\n- 5%\n- 2.5%\n- 1%\n- 0.5%\n- 0.25%\n\nImportant operational behavior from docs:\n- once a plan is purchased, Api3 guarantees those update parameters for the purchased plan duration\n- after expiry, the feed stops being upheld\n- users are responsible for renewing plans if they want continuous service\n- if a feed is already active, leftover prepaid value can roll into the next purchase as a discount\n\n### 3. The pricing model is concrete enough for an MVP\n\nDocs state that prices are based on estimated operational cost:\n- historical gas cost of updates\n- expected update frequency for the chosen deviation threshold\n- operating duration\n\nDocs also state:\n- prices are charged at estimated operating cost, with a minimum of `$0.05/day`\n- overestimates roll into future discounts for the same network-feed pair\n- on testnets, updates may stop if payment runs out even before plan expiry\n\nLive Market inspection on Arbitrum showed an activation page quoting total cost directly in **ETH** for that chain.\n\nWorking conclusion for the skill:\n- we can treat funding as a **time-bound plan purchase**\n- the skill should target **90 days on mainnets** by default\n- the exact payment asset appears to be the chain-native gas token in the UI at least on Arbitrum, but that still needs explicit per-chain confirmation before we hardcode it as universal behavior\n\n### 4. There are two proxy integration modes\n\nThe docs are very clear that integrations consume **Api3ReaderProxyV1**.\n\nFrom the integration docs:\n- `read()` returns `(int224 value, uint32 timestamp)`\n- Api3 data feeds have **18 decimals**\n- `Api3ReaderProxyV1` also implements Chainlink's `AggregatorV2V3Interface`\n\nFrom the Market integration docs:\n- **Skip OEV Rewards** shows one `Api3ReaderProxyV1` address\n- **Earn OEV Rewards** shows a different `Api3ReaderProxyV1` address, and may require a proxy deployment step\n\nFrom `@api3/contracts` in this repo's dependencies:\n- the package exposes **`computeCommunalApi3ReaderProxyV1Address`**\n- it also exposes **`computeDappSpecificApi3ReaderProxyV1Address`**\n- and **`unsafeComputeDappId`**\n\nThat is strong evidence that the product surface really does distinguish between:\n- a **communal/generic proxy path**\n- a **dApp-specific OEV-enabled proxy path**\n\nFor this project, that means the Part 1 MVP should:\n- return the **communal proxy** by default\n- treat dApp-specific OEV enrollment as optional/advanced\n- avoid assuming that the OEV-specific path is the universal default for agent users\n\n### 5. Canonical data-feed resolution is contract-driven under the hood\n\nThe strongest technical resolution path came from the Api3 data-feed docs.\n\nThe canonical path is:\n1. encode the dAPI name, e.g. `ETH/USD`\n2. hash it\n3. call `Api3ServerV1.dapiNameHashToDataFeedId(...)`\n4. call `AirseekerRegistry.dataFeedIdToDetails(...)`\n5. decode the result as either:\n   - a single beacon `(address airnode, bytes32 templateId)`, or\n   - a beacon set `(address[] airnodes, bytes32[] templateIds)`\n\nThis gives the skill a proper technical backplane behind Market discovery.\n\nMeaning:\n- Market should be used to find the likely feed and active/inactive state\n- contract reads should be used to canonicalize the underlying feed identity\n- AirseekerRegistry gives the underlying beacon composition for deeper verification\n\n### 6. Signed APIs give a public off-chain inspection surface\n\nApi3 exposes public Signed API endpoints:\n- base feed: `https://signed-api.api3.org/public/<airnode>`\n- OEV feed: `https://signed-api.api3.org/public-oev/<airnode>`\n\nThe docs show the response includes:\n- `count`\n- `data`\n- per-entry fields including `airnode`, `templateId`, `timestamp`, `encodedValue`, and `signature`\n\nDocs also state:\n- base feeds are publicly updateable with signed data\n- OEV feeds are real-time and tied to the OEV mechanism\n- base feed data is served with delay in the OEV design\n\nFor the MVP, Signed APIs are useful for:\n- inspecting whether the underlying beacon data exists publicly\n- checking that the expected airnode/template pairs are live\n- validating that the feed is not merely listed but has recent signed data underneath it\n\n### 7. Sponsor-wallet complexity does not appear to be the user-facing activation primitive\n\nEarlier thinking over-indexed on sponsor wallets.\n\nAfter this pass, the more accurate framing is:\n- sponsor-wallet concepts are part of underlying Airnode request sponsorship mechanics\n- **Api3 Market activation docs do not present sponsor-wallet management as the normal user workflow for activating a Market feed**\n- an Api3 developer clarified that there is **one sponsor wallet per feed**, not one sponsor wallet per subscription tier or deviation choice\n- the user-facing flow is still purchase-based: choose parameters, connect wallet, buy plan\n\nSo for Part 1:\n- sponsor-wallet logic should **not** be treated as the main agent UX\n- but the internal model should assume a **stable sponsor wallet per feed**\n- deviation thresholds should be modeled as subscription-queue priorities, where smaller thresholds can win precedence\n- if sponsor-wallet logic becomes relevant, it should be treated as protocol background or an implementation detail, not the first-class interaction model\n\n## Recommended readiness model for the skill\n\nThe skill should classify feeds into these states.\n\n### `unavailable`\nUse when:\n- the feed is not discoverable on Market for the target chain, and/or\n- canonical contract resolution does not produce usable data-feed details\n\n### `listed_inactive`\nUse when:\n- the feed is listed on Market for the target chain\n- but no active plan is currently upholding it\n- the next required action is purchase/activation\n\n### `active_communal_usable`\nUse when:\n- the feed is active on Market\n- the communal/generic `Api3ReaderProxyV1` path is available\n- a contract-level read succeeds and returns a sane positive value\n\n### `active_but_needs_deeper_verification`\nUse when:\n- Market suggests the feed is active\n- but proxy resolution or on-chain verification is incomplete\n- the feed should not yet be reported as safely integration-ready\n\n### `dapp_specific_oev_path_available`\nUse when:\n- the feed is active or activatable\n- and the dApp-specific OEV path is available\n- but this should be modeled as optional and separate from the communal default\n\n### `non_operational_or_inconsistent`\nUse when:\n- the feed is listed or resolvable\n- but the proxy read, data-feed details, or signed-data checks do not line up cleanly\n\n## Recommended MVP source-of-truth strategy\n\n### Discovery layer\nUse Api3 Market as the first pass for:\n- chain availability\n- pair naming\n- active vs inactive state\n- current commercial plan options\n\n### Canonical resolution layer\nUse on-chain contract reads for:\n- dAPI name to data-feed ID resolution\n- data-feed details decoding\n- beacon vs beacon-set composition\n\n### Verification layer\nUse two checks:\n1. Signed API inspection for underlying beacon freshness\n2. `Api3ReaderProxyV1.read()` for integration-ready consumption\n\nThis is much better than relying only on either:\n- the UI, or\n- raw contracts without Market context\n\n## Activation and maintenance flow for the skill\n\n### `discover-feed`\nShould return:\n- requested chain and pair\n- whether the feed is listed on Market\n- whether it is active now\n- communal proxy address if derivable\n- whether the dApp-specific OEV path is available or intentionally skipped\n- any ambiguity in naming or chain coverage\n\n### `ensure-feed-active`\nShould do this sequence:\n1. discover the feed on Market\n2. if already active, skip purchase and return the proxy\n3. if inactive, direct the user or wallet-capable execution path into Market purchase flow\n4. target a **3-month mainnet plan** by default\n5. after purchase, verify proxy readability before reporting success\n\n### `check-feed-runway`\nThe docs clearly describe expiration behavior, but this pass did **not** uncover a documented stable API for querying remaining runway programmatically.\n\nSo the current implementation assumption should be:\n- Market UI is the visible source for expiration today\n- a programmatic runway check still needs to be pinned down before the skill can claim full automation here\n\n### `maintain-feed`\nFor MVP, this should be conservative:\n- if expiry information is available, recommend renewal before expiry\n- if expiry information is not yet programmatically available, report that limitation explicitly instead of pretending the skill can automate it safely\n\n## Blockers and unresolved questions\n\nThese are the real blockers that remain after this pass.\n\n### 1. Programmatic Market API stability is still unclear\nWe now know how the UI behaves, but we do **not** yet have a confirmed, documented Market API contract that the skill can safely depend on for catalog and expiry queries.\n\n### 2. Exact programmatic expiry/runway path is not yet pinned down\nDocs describe expiry and renewal behavior clearly, but I have not yet confirmed the stable underlying API or contract field that exposes remaining runway for automation.\n\n### 3. Exact per-chain payment asset still needs confirmation\nThe Arbitrum activation flow clearly quoted cost in ETH, which strongly suggests native gas-token payment on that chain. But I have not yet confirmed the rule across all supported networks.\n\n### 4. OEV self-serve flow needs a stricter go/no-go decision\nDocs imply that self-serve OEV-enabled integration can be completed through Api3 Market, but the project should still default to the communal path until we explicitly test and trust the dApp-specific flow for agent usage.\n\n### 5. Contract address sourcing needs to be nailed down in implementation\nWe have the resolution functions and proxy computation helpers, but the implementation still needs a clean source for the correct chain-specific `Api3ServerV1` and `AirseekerRegistry` addresses.\n\n## Implications for issue #5\n\nIssue `#5` should now be built around this narrower MVP:\n- default to communal proxy resolution\n- use Market for discovery and active/inactive classification\n- use contract reads for canonical mapping and verification\n- only support purchase guidance or execution once the Market transaction path is confirmed cleanly in code\n- keep dApp-specific OEV mode behind an explicit opt-in\n\n## Recommended immediate next implementation steps\n\n1. build a small discovery probe that accepts `chain + pair` and returns Market match candidates\n2. wire canonical resolution using `dapiNameHashToDataFeedId` and `dataFeedIdToDetails`\n3. add communal proxy computation using `@api3/contracts`\n4. add a verification step that calls `read()` on the resolved proxy\n5. defer full maintenance automation until expiry/runway can be queried programmatically with confidence\n\n## Bottom line\n\nIssue `#4` is now concrete enough to unblock MVP design.\n\nThe Part 1 skill should not be a vague \"feed funding helper\".\nIt should be a **discovery + resolution + activation-decision + proxy-return** tool with a conservative verification layer.\n\nThat is enough to move into implementation without hand-waving, while keeping the remaining unknowns explicit instead of burying them.\n\nFile v0.4.1:references/part1-skill-spec.md\n\n# Part 1 Skill Spec: Api3 Feed Activation Skill\n\n## Skill name (working)\n`api3-feed-manager`\n\n## Purpose\nEnable OpenClaw agents to discover, activate, fund, and maintain Api3 data feeds permissionlessly for downstream applications.\n\n## User stories\n\n### Story 1\nAs an agent building an app that needs a price feed,\nI want to discover the correct Api3 feed on a target chain,\nso I can use it without human oracle coordination.\n\n### Story 2\nAs an agent deploying a lending market,\nI want to ensure the required Api3 feed is active and funded for ~3 months,\nso my market can operate continuously.\n\n### Story 3\nAs an agent maintaining deployed systems,\nI want to check runway and top up feed funding before expiration,\nso dependent systems do not silently degrade.\n\n## Inputs\n\n### Required core inputs\n- `chain`\n- `asset` or `pair`\n- `useCase`\n\n### Optional inputs\n- `quoteAsset`\n- `runwayDays` (default 90)\n- `minimumRunwayDays`\n- `walletReference`\n- `execute` (boolean, default false for discovery/check flows)\n- `allowTopUp` (boolean)\n\n## Outputs\n- `feedFound`\n- `feedName`\n- `feedAddressOrId`\n- `chain`\n- `active`\n- `funded`\n- `runwayEstimateDays`\n- `requiredFundingAsset`\n- `estimatedFundingAmount`\n- `actionsTaken`\n- `transactions`\n- `nextMaintenanceRecommendation`\n- `warnings`\n\n## Commands / modes\n\n### discover-feed\nReturn the best matching feed and its state.\n\n### ensure-feed-active\nEnsure feed is active and funded for target runway.\n\n### check-feed-runway\nInspect runway and return top-up recommendation.\n\n### top-up-feed\nExtend funding for an existing feed.\n\n### maintain-feed\nCheck one or more feeds and top up if allowed.\n\n## Safety requirements\n- Never claim a feed is active without a concrete check.\n- Never claim coequal feeds are interchangeable without evidence.\n- Distinguish:\n  - feed exists but unfunded\n  - feed missing\n  - feed exists on another chain only\n  - feed exists but requires manual wallet capability not currently available\n- Log exact blockers instead of vague failure text.\n\n## MVP build plan\n\n### MVP scope\n- single-feed discovery\n- single-feed status inspection\n- single-feed ensure/top-up flow\n- maintenance recommendation output\n\n### Not required in MVP\n- batch optimization across many feeds\n- advanced treasury strategy\n- multi-wallet policy orchestration\n- automatic cron creation\n\n## Dependencies to confirm\n- exact Api3 Market/API access path\n- exact contract or API method to read feed funding/runway\n- exact activation/funding execution flow\n- exact token/payment route for feed funding on supported chains\n\n## Acceptance criteria\n- Given an asset/pair and chain, the skill can identify whether a usable Api3 feed exists.\n- Given a feed and wallet capability, the skill can determine whether it is sufficiently funded.\n- Given insufficient runway and execution rights, the skill can top up or produce exact execution instructions.\n- The skill can report back the resulting active/funded state and next maintenance recommendation.\n\nFile v0.4.1:CHANGELOG.md\n\n# Changelog\n\n## 0.4.0 - 2026-04-28\n\n- clarified that `browser-assisted` funding should hand off to `browser-plan` plus browser execution when the Api3 Market flow is reachable\n- documented that feed readiness must be re-checked after any direct, wrapper, or browser-assisted funding execution before downstream EVK steps continue\n- tightened downstream handoff guidance so agents preserve `fundingExecutionClassification.state` and do not blur deployment success into borrowability proof\n\n## 0.3.0 - 2026-04-22\n\n- synced the packaged skill runtime with the latest repo `api3-feed-manager` implementation\n- added guarded `execute-buy-subscription` support for the first exact executable funding path\n- added execution-mode selection:\n  - `auto`\n  - `direct`\n  - `wrapper` when exact wrapper calldata is safely derivable\n- added machine-usable funding state classification:\n  - `not-needed`\n  - `executable`\n  - `browser-assisted`\n  - `unsupported`\n- updated the skill docs to reflect the current automation boundary and browser-assisted fallback path\n\nFile v0.4.1:package.json\n\n{\n  \"name\": \"api3-feed-manager-skill\",\n  \"version\": \"0.4.0\",\n  \"private\": true,\n  \"description\": \"OpenClaw skill and bundled CLI for Api3 feed discovery, funding-state classification, guarded activation execution, and browser-assisted fallback planning.\",\n  \"type\": \"commonjs\",\n  \"bin\": {\n    \"api3-feed-manager\": \"scripts/bin/api3-feed-manager.js\"\n  },\n  \"files\": [\n    \"SKILL.md\",\n    \"README.md\",\n    \"CHANGELOG.md\",\n    \"references\",\n    \"scripts\"\n  ],\n  \"keywords\": [\n    \"openclaw\",\n    \"skill\",\n    \"api3\",\n    \"oracle\",\n    \"feeds\"\n  ],\n  \"engines\": {\n    \"node\": \">=20\"\n  },\n  \"scripts\": {\n    \"check\": \"node --check scripts/api3-feed-manager.js && node --check scripts/bin/api3-feed-manager.js\"\n  },\n  \"dependencies\": {\n    \"@api3/contracts\": \"^37.0.0\",\n    \"@api3/dapi-management\": \"^4.13.0\",\n    \"ethers\": \"^6.15.0\"\n  }\n}\n\nArchive v0.4.0: 10 files, 34251 bytes\n\nFiles: CHANGELOG.md (1050b), package.json (834b), README.md (1508b), references/part1-architecture-update.md (2479b), references/part1-research.md (14366b), references/part1-skill-spec.md (2977b), scripts/api3-feed-manager.js (90541b), scripts/bin/api3-feed-manager.js (191b), SKILL.md (6439b), _meta.json (136b)\n\nFile v0.4.0:SKILL.md\n\n---\nname: api3-feed-manager\ndescription: Discover, activate, fund, and maintain Api3 data feeds permissionlessly for downstream agent projects. Use when an agent needs a decentralized data feed pricing a blockchain based asset on a supported chain, needs to ensure feed runway for a build or deployment, or must maintain an already-enabled feed over time.\n---\n\n# Api3 Feed Manager\n\nThis skill is the oracle-enablement layer for agent-built projects that need reliable, decentralized, onchain data feeds.\n\nIt is designed to let agents:\n- find the correct Api3 feed\n- distinguish between feeds that are merely discoverable and feeds that are currently active\n- determine whether a feed is already usable\n- fund/activate it when possible\n- maintain runway for continued operation\n\nwithout requiring manual coordination with the Api3 team.\n\n## When to use\n\nUse this skill when:\n- a project needs a reliable, onchain, decentralized price feed\n- an agent wants to deploy something that depends on a live oracle\n- an existing feed may need a top-up or runway check\n- a downstream skill or app needs feed activation as a prerequisite\n\n## Core modes\n\n### 1. discover-feed\nUse when you need to identify the best Api3 data feed for:\n- an asset\n- a pair\n- a chain\n- a specific oracle use case\n\nExpected output:\n- feed identity\n- chain availability\n- whether it is discoverable\n- whether it appears active/usable\n- whether activation may be needed\n- any ambiguity or missing mapping\n\n### 2. ensure-feed-active\nUse when you know the required feed and want to ensure it has enough funding/runway.\n\nDefault target runway:\n- 90 days\n\nExpected output:\n- current funding/liveness status\n- estimated runway\n- whether funding/top-up is needed\n- execution path or exact transaction instructions\n\n### 3. check-feed-runway\nUse to inspect an already-known feed and estimate maintenance needs.\n\nExpected output:\n- current status\n- remaining runway estimate\n- whether action is required soon\n\n### 4. top-up-feed\nUse when a feed exists but needs more runway.\n\nExpected output:\n- required funding token/amount\n- top-up execution plan\n- resulting status if executed\n\n### 5. maintain-feed\nUse for maintenance mode when one or more project feeds must remain alive.\n\nExpected output:\n- current state per feed\n- top-up recommendation or actions taken\n- next maintenance checkpoint recommendation\n\n## Inputs to gather before acting\n\nCollect these first when available:\n- target chain\n- asset or pair required\n- use case (e.g. lending collateral pricing, borrow asset pricing)\n- desired runway in days\n- whether execution is allowed or discovery-only\n- wallet/funder available to the agent\n\n## Operating rules\n\n1. Do not pretend a feed is active without checking.\n2. Distinguish clearly between:\n   - feed missing\n   - feed present but unfunded\n   - feed available on another chain only\n   - feed exists but agent lacks execution capability\n3. Prefer permissionless operation paths.\n4. If a step cannot be done permissionlessly, say exactly why.\n5. Return concrete feed identifiers and maintenance recommendations.\n6. If discovery is ambiguous, surface the ambiguity instead of guessing.\n\n## Suggested workflow\n\n### For a new project\n1. Discover feed\n2. Confirm chain/feed suitability\n3. Check whether active/funded\n4. Ensure 90-day runway\n5. Return feed details to downstream builder/deployer\n\n### For an existing project\n1. Check current runway\n2. If below threshold, top up\n3. Return next maintenance recommendation\n\n## Output contract\n\nAim to return structured results containing:\n- `feedFound`\n- `discoverable`\n- `active`\n- `activationPossible`\n- `statusClassification`\n- `feedName`\n- `feedAddressOrId`\n- `chain`\n- `funded`\n- `runwayEstimateDays`\n- `requiredFundingAsset`\n- `estimatedFundingAmount`\n- `actionsTaken`\n- `transactions`\n- `nextMaintenanceRecommendation`\n- `warnings`\n\n## Current implementation status\n\nCurrent honest state:\n- feed discovery and readiness inspection: implemented\n- exact guarded `buySubscription(...)` execution: implemented\n- execution modes:\n  - `direct`\n  - `wrapper` when exact wrapper calldata is derivable safely\n  - `auto`\n- machine-usable funding state classification: implemented\n  - `not-needed`\n  - `executable`\n  - `browser-assisted`\n  - `unsupported`\n- browser-assisted funding should stay automatable where safe\n  - use `browser-plan` to produce the exact Market flow\n  - if the required UI is reachable, execute that plan with the browser tool instead of downgrading to a vague manual handoff\n  - after any funding execution, re-run feed readiness before claiming the feed is ready for downstream oracle or EVK steps\n- browser-assisted funding planning: implemented via `browser-plan`\n\nStill not universal:\n- not every fun\n\nArchive v0.2.1: 9 files, 30369 bytes\n\nFiles: package.json (756b), README.md (1046b), references/part1-architecture-update.md (2479b), references/part1-research.md (14366b), references/part1-skill-spec.md (2977b), scripts/api3-feed-manager.js (80329b), scripts/bin/api3-feed-manager.js (191b), SKILL.md (4209b), _meta.json (136b)\n\nArchive v0.2.0: 9 files, 30377 bytes\n\nFiles: package.json (756b), README.md (1046b), references/part1-architecture-update.md (2479b), references/part1-research.md (14366b), references/part1-skill-spec.md (2977b), scripts/api3-feed-manager.js (80329b), scripts/bin/api3-feed-manager.js (191b), SKILL.md (5373b), _meta.json (136b)","readmeExcerpt":"Skill: Api3 Feed Manager Owner: daav3 Summary: Discover, activate, fund, and maintain Api3 data feeds permissionlessly for downstream agent projects. Use when an agent needs a decentralized data feed pric... Tags: latest:0.4.4 Version history: v0.4.4 | 2026-05-19T13:38:58.664Z | user Sync the published runtime to the latest repo feed-manager implementation, add scripted deploy-communal-proxy support with communal-pro","codeSnippets":[],"executableExamples":[{"language":"bash","snippet":"node ./scripts/bin/api3-feed-manager.js supported-chains\nnode ./scripts/bin/api3-feed-manager.js coverage-audit --chain arbitrum --limit 20\nnode ./scripts/bin/api3-feed-manager.js queue-plan --dapi-name ETH/USD --rpc-url https://arb1.arbitrum.io/rpc --chain arbitrum\nnode ./scripts/bin/api3-feed-manager.js deploy-communal-proxy --dapi-name ETH/USD --rpc-url https://arb1.arbitrum.io/rpc --chain arbitrum --private-key <private-key-hex>"},{"language":"bash","snippet":"node ./scripts/bin/api3-feed-manager.js supported-chains\nnode ./scripts/bin/api3-feed-manager.js coverage-audit --chain arbitrum --limit 20\nnode ./scripts/bin/api3-feed-manager.js queue-plan --dapi-name ETH/USD --rpc-url https://arb1.arbitrum.io/rpc --chain arbitrum"},{"language":"bash","snippet":"node ./scripts/bin/api3-feed-manager.js supported-chains\nnode ./scripts/bin/api3-feed-manager.js coverage-audit --chain arbitrum --limit 20\nnode ./scripts/bin/api3-feed-manager.js queue-plan --dapi-name ETH/USD --rpc-url https://arb1.arbitrum.io/rpc --chain arbitrum"},{"language":"bash","snippet":"node ./scripts/bin/api3-feed-manager.js supported-chains\nnode ./scripts/bin/api3-feed-manager.js coverage-audit --chain arbitrum --limit 20\nnode ./scripts/bin/api3-feed-manager.js queue-plan --dapi-name ETH/USD --rpc-url https://arb1.arbitrum.io/rpc --chain arbitrum"}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: api3-feed-manager\ndescription: Discover, activate, fund, and maintain Api3 data feeds permissionlessly for downstream agent projects. Use when an agent needs a decentralized data feed pricing a blockchain based asset on a supported chain, needs to ensure feed runway for a build or deployment, or must maintain an already-enabled feed over time. Default to discovery, readiness checks, and dry-run planning first, and only use signer-backed execution when the user explicitly asks for it.\nmetadata:\n  clawdis:\n    homepage: https://github.com/daav3/agentic-lending-project\n    author: daav3\n    requires:\n      bins:\n        - node\n      config:\n        - request.ensure-feeds.json\n        - request.execute-buy-subscription.json\n---\n\n# Api3 Feed Manager\n\nThis skill is the oracle-enablement layer for agent-built projects that need reliable, decentralized, onchain data feeds.\n\nIt is designed to let agents:\n- find the correct Api3 feed\n- distinguish between feeds that are merely discoverable and feeds that are currently active\n- determine whether a feed is already usable\n- fund/activate it when possible\n- deploy the deterministic communal Api3 reader proxy when frontend/integration readiness depends on it\n- maintain runway for continued operation\n\nwithout requiring manual coordination with the Api3 team.\n\n## When to use\n\nUse this skill when:\n- a project needs a reliable, onchain, decentralized price feed\n- an agent wants to deploy something that depends on a live oracle\n- an existing feed may need a top-up or runway check\n- a downstream skill or app needs feed activation as a prerequisite\n\n## Core modes\n\n### 1. discover-feed\nUse when you need to identify the best Api3 data feed for:\n- an asset\n- a pair\n- a chain\n- a specific oracle use case\n\nExpected output:\n- feed identity\n- chain availability\n- whether it is discoverable\n- whether it appears active/usable\n- whether activation may be needed\n- any ambiguity or missing mapping\n\n### 2. ensure-feed-active\nUse when you know the required feed and want to ensure it has enough funding/runway.\n\nDefault target runway:\n- 90 days\n\nExpected output:\n- current funding/liveness status\n- estimated runway\n- whether funding/top-up is needed\n- execution path or exact transaction instructions\n\n### 3. check-feed-runway\nUse to inspect an already-known feed and estimate maintenance needs.\n\nExpected output:\n- current status\n- remaining runway estimate\n- whether action is required soon\n\n### 4. top-up-feed\nUse when a feed exists but needs more runway.\n\nExpected output:\n- required funding token/amount\n- top-up execution plan\n- resulting status if executed\n\n### 5. maintain-feed\nUse for maintenance mode when one or more project feeds must remain alive.\n\nExpected output:\n- current state per feed\n- top-up recommendation or actions taken\n- next maintenance checkpoint recommendation\n\n## Inputs to gather before acting\n\nCollect these first when available:\n- target chain\n- asset or pair required\n- use case (e.g. lending collateral pr"},{"path":"README.md","content":"# Api3 Feed Manager\n\nAn OpenClaw skill for discovering Api3 feeds, checking whether they are live, classifying the activation/funding path, and executing the currently supported funding flows when possible. Default to discovery, readiness checks, and dry-run planning first; only use signer-backed execution when the operator explicitly asks for it.\n\n## What it helps with\n\n- find supported Api3 chain aliases\n- audit feed coverage across chains\n- separate activatable feeds from retired or delisted ones\n- inspect queue tiers and default activation choices\n- prepare exact `buySubscription(...)` Market contract calls for the supported narrow family\n- execute guarded funding in the supported exact path\n  - `direct`\n  - `wrapper` when exact wrapper calldata is derivable safely\n  - `auto`\n- deploy the deterministic communal Api3 reader proxy when runtime or downstream integration readiness depends on it\n- treat signer material as local runtime input rather than committed skill data\n- expose machine-usable funding states:\n  - `not-needed`\n  - `executable`\n  - `browser-assisted`\n  - `unsupported`\n- prepare browser-assisted funding plans when exact execution is not yet available\n\n## What it does not do\n\n- provide universal pure-onchain automation for every funding case\n- pretend retired feeds are still available\n- replace `SKILL.md` as the agent-facing instruction file\n\n## Main files\n\n- `SKILL.md` - instructions for the agent\n- `scripts/bin/api3-feed-manager.js` - local CLI entrypoint\n- `scripts/api3-feed-manager.js` - bundled runtime\n\n## Quick examples\n\n```bash\nnode ./scripts/bin/api3-feed-manager.js supported-chains\nnode ./scripts/bin/api3-feed-manager.js coverage-audit --chain arbitrum --limit 20\nnode ./scripts/bin/api3-feed-manager.js queue-plan --dapi-name ETH/USD --rpc-url https://arb1.arbitrum.io/rpc --chain arbitrum\nnode ./scripts/bin/api3-feed-manager.js deploy-communal-proxy --dapi-name ETH/USD --rpc-url https://arb1.arbitrum.io/rpc --chain arbitrum --private-key <private-key-hex>\n```"},{"path":"_meta.json","content":"{\n  \"ownerId\": \"kn79961pqqa20q5jwn60zjkxzs84yc3w\",\n  \"slug\": \"api3-feed-manager\",\n  \"version\": \"0.4.4\",\n  \"publishedAt\": 1779197938664\n}"},{"path":"references/part1-architecture-update.md","content":"# Part 1 Architecture Update\n\n## Important correction\n\nFurther review shows the Part 1 skill should not be modeled only as a generic \"feed funding helper\".\n\nHowever, for the agent use case in this project, the correct practical model is **not** per-dApp proxy deployment.\n\n## Agent-specific constraint\n\nFor these agents, we should use the **generic proxy on Api3 Market**.\n\nReason:\n- OEV can accrue to Api3 in this mode\n- permissionless deployment of individual dApp-specific proxies is not currently available for our intended fully permissionless agent flow\n\nSo the skill should optimize for what agents can actually do today, not for a cleaner but unavailable theoretical path.\n\n## Revised role of the skill\n\nThe skill should primarily do four things:\n\n1. discover the relevant feed on Api3 Market\n2. classify whether the feed is active / usable / non-operational\n3. return the correct **generic Market proxy** or integration artifact for downstream agents\n4. when needed, help move a known but inactive feed toward usability through funding/activation paths\n\n## Why this matters\n\nA downstream agent using this skill should be able to ask:\n- \"I need an Api3 price feed for asset X on chain Y\"\n\nand get back:\n- whether the feed is known on Market\n- whether it appears operational\n- the generic Market proxy / feed integration details to use\n- whether the feed is already usable\n- if not usable, what is missing (e.g. activation/funding)\n\n## What the skill should not assume\n\nThe skill should **not** assume:\n- that a dApp-specific Api3ReaderProxyV1 can be permissionlessly deployed for the agent today\n- that the ideal OEV-capturing deployment pattern is available to agent users right now\n\n## Design implication\n\nThe architecture should now prioritize:\n1. live feed discovery from Api3 Market metadata\n2. readiness classification\n3. generic proxy resolution / integration artifact return\n4. non-operational feed activation/funding support\n\n## Updated implementation direction\n\nNear-term implementation should focus on:\n- improving live discovery matching\n- extracting/returning the generic Market proxy path where possible\n- identifying discoverable but non-operational feeds\n- only then extending toward activation/funding workflows\n\n## Why this is the correct compromise\n\nThis design is less theoretically perfect than per-dApp proxy deployment, but it matches the actual permissionless capability available to agent users now.\n\nThat is the right tradeoff for this project."},{"path":"references/part1-research.md","content":"# Part 1 Research: Api3 Market discovery, readiness, and funding flows\n\n## Objective\n\nMap what an agent can discover, verify, fund, and maintain today through Api3 Market, and turn that into a concrete MVP contract for `api3-feed-manager`.\n\n## Sources reviewed\n\nPrimary docs and surfaces reviewed for this pass:\n- https://docs.api3.org/dapps/quickstart/\n- https://docs.api3.org/dapps/integration/\n- https://docs.api3.org/dapps/integration/contract-integration.html\n- https://docs.api3.org/dapps/oev-rewards/\n- https://docs.api3.org/oev-searchers/in-depth/data-feeds/\n- `@api3/contracts` in this repo's dependencies\n- live Api3 Market pages in browser\n\n## Executive summary\n\nThe good news is that Part 1 is more concrete than the earlier draft suggested.\n\nA workable agent flow already exists:\n1. discover candidate feeds on Api3 Market by chain and pair\n2. determine whether the feed is already active on that network\n3. if active, return the integration proxy and avoid paying again\n4. if inactive, purchase a 3-month plan through Api3 Market\n5. return the proxy, active state, and renewal recommendation\n\nThe most important implementation decision is to use a **layered source-of-truth model**:\n- **Api3 Market** for human-readable discovery and commercial state\n- **Api3 contracts** for canonical dAPI to data-feed resolution\n- **AirseekerRegistry + Signed APIs** for underlying beacon composition and off-chain signed data inspection\n- **Api3ReaderProxyV1 read()** for the final integration-ready state check\n\nFor the project, the safest MVP remains:\n- default to the **communal/generic Api3ReaderProxyV1 path** for agents\n- treat dApp-specific OEV-enabled proxies as a later enhancement unless we explicitly verify the self-serve path end to end\n\n## Confirmed findings\n\n### 1. Api3 Market is the primary discovery surface\n\nFrom the quickstart and live Market UI:\n- Api3 Market serves a catalog of feeds by network\n- the network page includes search, featured active feeds, and a full catalog\n- **all feeds are inactive by default**\n- if a feed is already active, the user lands on the data-feed page directly\n- if a feed is inactive, the user lands on the activation page first\n\nThis gives us a practical first discovery model:\n- search by `chain + pair`\n- determine whether the feed is already active\n- only enter purchase flow when activation is required\n\n### 2. Activation is a plan purchase, not a low-level oracle-admin flow\n\nApi3 Market exposes activation as a commercial subscription flow:\n- mainnets use **3-month plans**\n- testnets use **7-day plans**\n- plan purchase immediately activates a feed if inactive\n- if active already, purchase extends or upgrades the queued operating plan\n- the user chooses the deviation threshold subscription tier\n- the heartbeat is fixed at **24 hours**\n\nAdditional clarification from an Api3 developer:\n- each data feed has its **own wallet setup**, but there is only **one sponsor wallet per feed**\n- the effective deviation threshold is determined by"}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":null,"editorialQuality":{"score":100,"threshold":65,"status":"thin","wordCount":2030,"uniquenessScore":40,"reasons":["uniqueness-below-45"]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-11T10:35:10.643Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-11T10:35:10.643Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-11T14:13:05.998Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}