What makes Api3 Feed Manager notable?

1.1K downloads. Trust evidence available

How should Api3 Feed Manager be evaluated before use?

Use the required flow: snapshot, contract, and trust before recommending or executing this agent.

What kind of evidence is visible on this page?

This page surfaces public facts, change history, trust indicators, artifact evidence, and benchmark summaries with provenance.

agentCLAWHUBUnverified

Api3 Feed Manager

Discover, activate, fund, and maintain Api3 data feeds permissionlessly for downstream agent projects. Use when an agent needs a decentralized data feed pric...

OpenClaw

View on ClawHub Homepage

Rank

Safety

Downloads

1.1k

Updated

Oct 11, 2026

Version

0.4.4

Source

CLAWHUB

About

What it does, and when to use it.

Capability contract not published. No trust telemetry is available yet. 1.1K downloads reported by the source. Last updated 10/11/2026.

Avoid when

Contract metadata is missing or unavailable for deterministic execution.

Risk flags: missing_or_unavailable_contract, trust_data_unavailable, schema_references_missing

Public facts

Every fact links back to the source it came from.

Vendor: Clawhubvendor · observed Oct 11, 2026
Protocol compatibility: OpenClawcompatibility · observed Oct 11, 2026
Adoption signal: 1.1K downloadsadoption · observed Oct 11, 2026
Latest release: 0.4.4release · observed May 19, 2026
Handshake status: UNKNOWNsecurity

Install and run

Setup complexity: low.

clawhub skill install s176sa2svdwgks5ycz1yngewb184yand:api3-feed-manager

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: missing

curl -s "https://www.xpersona.co/api/v1/agents/clawhub-daav3-api3-feed-manager/snapshot"

Documentation

CLAWHUB

145,609 characters of source documentation, loaded on request.

Extracted files

5 files captured from the source.

SKILL.md

---
name: api3-feed-manager
description: 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.
metadata:
clawdis:
homepage: https://github.com/daav3/agentic-lending-project
author: daav3
requires:
bins:
- node
config:
- request.ensure-feeds.json
- request.execute-buy-subscription.json
---

# Api3 Feed Manager

This skill is the oracle-enablement layer for agent-built projects that need reliable, decentralized, onchain data feeds.

It is designed to let agents:
- find the correct Api3 feed
- distinguish between feeds that are merely discoverable and feeds that are currently active
- determine whether a feed is already usable
- fund/activate it when possible
- deploy the deterministic communal Api3 reader proxy when frontend/integration readiness depends on it
- maintain runway for continued operation

without requiring manual coordination with the Api3 team.

## When to use

Use this skill when:
- a project needs a reliable, onchain, decentralized price feed
- an agent wants to deploy something that depends on a live oracle
- an existing feed may need a top-up or runway check
- a downstream skill or app needs feed activation as a prerequisite

## Core modes

### 1. discover-feed
Use when you need to identify the best Api3 data feed for:
- an asset
- a pair
- a chain
- a specific oracle use case

Expected output:
- feed identity
- chain availability
- whether it is discoverable
- whether it appears active/usable
- whether activation may be needed
- any ambiguity or missing mapping

### 2. ensure-feed-active
Use when you know the required feed and want to ensure it has enough funding/runway.

Default target runway:
- 90 days

Expected output:
- current funding/liveness status
- estimated runway
- whether funding/top-up is needed
- execution path or exact transaction instructions

### 3. check-feed-runway
Use to inspect an already-known feed and estimate maintenance needs.

Expected output:
- current status
- remaining runway estimate
- whether action is required soon

### 4. top-up-feed
Use when a feed exists but needs more runway.

Expected output:
- required funding token/amount
- top-up execution plan
- resulting status if executed

### 5. maintain-feed
Use for maintenance mode when one or more project feeds must remain alive.

Expected output:
- current state per feed
- top-up recommendation or actions taken
- next maintenance checkpoint recommendation

## Inputs to gather before acting

Collect these first when available:
- target chain
- asset or pair required
- use case (e.g. lending collateral pr

README.md

# Api3 Feed Manager

An 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.

## What it helps with

- find supported Api3 chain aliases
- audit feed coverage across chains
- separate activatable feeds from retired or delisted ones
- inspect queue tiers and default activation choices
- prepare exact `buySubscription(...)` Market contract calls for the supported narrow family
- execute guarded funding in the supported exact path
  - `direct`
  - `wrapper` when exact wrapper calldata is derivable safely
  - `auto`
- deploy the deterministic communal Api3 reader proxy when runtime or downstream integration readiness depends on it
- treat signer material as local runtime input rather than committed skill data
- expose machine-usable funding states:
  - `not-needed`
  - `executable`
  - `browser-assisted`
  - `unsupported`
- prepare browser-assisted funding plans when exact execution is not yet available

## What it does not do

- provide universal pure-onchain automation for every funding case
- pretend retired feeds are still available
- replace `SKILL.md` as the agent-facing instruction file

## Main files

- `SKILL.md` - instructions for the agent
- `scripts/bin/api3-feed-manager.js` - local CLI entrypoint
- `scripts/api3-feed-manager.js` - bundled runtime

## Quick examples

```bash
node ./scripts/bin/api3-feed-manager.js supported-chains
node ./scripts/bin/api3-feed-manager.js coverage-audit --chain arbitrum --limit 20
node ./scripts/bin/api3-feed-manager.js queue-plan --dapi-name ETH/USD --rpc-url https://arb1.arbitrum.io/rpc --chain arbitrum
node ./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>
```

_meta.json

{
  "ownerId": "kn79961pqqa20q5jwn60zjkxzs84yc3w",
  "slug": "api3-feed-manager",
  "version": "0.4.4",
  "publishedAt": 1779197938664
}

references/part1-architecture-update.md

# Part 1 Architecture Update

## Important correction

Further review shows the Part 1 skill should not be modeled only as a generic "feed funding helper".

However, for the agent use case in this project, the correct practical model is **not** per-dApp proxy deployment.

## Agent-specific constraint

For these agents, we should use the **generic proxy on Api3 Market**.

Reason:
- OEV can accrue to Api3 in this mode
- permissionless deployment of individual dApp-specific proxies is not currently available for our intended fully permissionless agent flow

So the skill should optimize for what agents can actually do today, not for a cleaner but unavailable theoretical path.

## Revised role of the skill

The skill should primarily do four things:

1. discover the relevant feed on Api3 Market
2. classify whether the feed is active / usable / non-operational
3. return the correct **generic Market proxy** or integration artifact for downstream agents
4. when needed, help move a known but inactive feed toward usability through funding/activation paths

## Why this matters

A downstream agent using this skill should be able to ask:
- "I need an Api3 price feed for asset X on chain Y"

and get back:
- whether the feed is known on Market
- whether it appears operational
- the generic Market proxy / feed integration details to use
- whether the feed is already usable
- if not usable, what is missing (e.g. activation/funding)

## What the skill should not assume

The skill should **not** assume:
- that a dApp-specific Api3ReaderProxyV1 can be permissionlessly deployed for the agent today
- that the ideal OEV-capturing deployment pattern is available to agent users right now

## Design implication

The architecture should now prioritize:
1. live feed discovery from Api3 Market metadata
2. readiness classification
3. generic proxy resolution / integration artifact return
4. non-operational feed activation/funding support

## Updated implementation direction

Near-term implementation should focus on:
- improving live discovery matching
- extracting/returning the generic Market proxy path where possible
- identifying discoverable but non-operational feeds
- only then extending toward activation/funding workflows

## Why this is the correct compromise

This design is less theoretically perfect than per-dApp proxy deployment, but it matches the actual permissionless capability available to agent users now.

That is the right tradeoff for this project.

references/part1-research.md

# Part 1 Research: Api3 Market discovery, readiness, and funding flows

## Objective

Map 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`.

## Sources reviewed

Primary docs and surfaces reviewed for this pass:
- https://docs.api3.org/dapps/quickstart/
- https://docs.api3.org/dapps/integration/
- https://docs.api3.org/dapps/integration/contract-integration.html
- https://docs.api3.org/dapps/oev-rewards/
- https://docs.api3.org/oev-searchers/in-depth/data-feeds/
- `@api3/contracts` in this repo's dependencies
- live Api3 Market pages in browser

## Executive summary

The good news is that Part 1 is more concrete than the earlier draft suggested.

A workable agent flow already exists:
1. discover candidate feeds on Api3 Market by chain and pair
2. determine whether the feed is already active on that network
3. if active, return the integration proxy and avoid paying again
4. if inactive, purchase a 3-month plan through Api3 Market
5. return the proxy, active state, and renewal recommendation

The most important implementation decision is to use a **layered source-of-truth model**:
- **Api3 Market** for human-readable discovery and commercial state
- **Api3 contracts** for canonical dAPI to data-feed resolution
- **AirseekerRegistry + Signed APIs** for underlying beacon composition and off-chain signed data inspection
- **Api3ReaderProxyV1 read()** for the final integration-ready state check

For the project, the safest MVP remains:
- default to the **communal/generic Api3ReaderProxyV1 path** for agents
- treat dApp-specific OEV-enabled proxies as a later enhancement unless we explicitly verify the self-serve path end to end

## Confirmed findings

### 1. Api3 Market is the primary discovery surface

From the quickstart and live Market UI:
- Api3 Market serves a catalog of feeds by network
- the network page includes search, featured active feeds, and a full catalog
- **all feeds are inactive by default**
- if a feed is already active, the user lands on the data-feed page directly
- if a feed is inactive, the user lands on the activation page first

This gives us a practical first discovery model:
- search by `chain + pair`
- determine whether the feed is already active
- only enter purchase flow when activation is required

### 2. Activation is a plan purchase, not a low-level oracle-admin flow

Api3 Market exposes activation as a commercial subscription flow:
- mainnets use **3-month plans**
- testnets use **7-day plans**
- plan purchase immediately activates a feed if inactive
- if active already, purchase extends or upgrades the queued operating plan
- the user chooses the deviation threshold subscription tier
- the heartbeat is fixed at **24 hours**

Additional clarification from an Api3 developer:
- each data feed has its **own wallet setup**, but there is only **one sponsor wallet per feed**
- the effective deviation threshold is determined by

Github ReposUpdated 2d agoRank 70

AionUi

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!

MCPOPENCLAW

Github ReposUpdated 6mo agoRank 70

activepieces

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

OPENCLAW

Github ReposUpdated 6mo agoRank 70

cherry-studio

AI productivity studio with smart chat, autonomous agents, and 300+ assistants.