The chain skill
A real RPC-backed skill that digests the node into meaning — not the model guessing.
"How's the ETH/USDC pool?" should return a sentence, not a slot0() tuple — and it should be true, not plausibly hallucinated. The chain skill is the component that makes both so. It is deterministic code over a Base RPC node, exposed to the presence as a tool.
Why it isn't the model
Asking a language model to read chain state directly fails two ways: it can't make RPC calls, and if it could, it would still fabricate a confident number. The skill removes the model from the data path entirely. The route asks a question; the skill answers from the node; the route only narrates the result.
route → chain.ask(q) → RPC (eth_call, logs) → digest → typed result → route narratesThe digested views
The skill maintains four normalised views over the node so common questions are one lookup, not a derivation:
| View | Resolves | Example question |
|---|---|---|
| tokens | metadata · balances · USD | “what do I hold, and what is it worth?” |
| pools | reserves · price · depth · 24h vol | “how’s the ETH/USDC pool — can I move size?” |
| positions | this wallet's holdings & owed | “am I up since I funded this?” |
| safety | verified? · mint rights · holder spread | “is this token safe to touch?” |
Freshness & honesty
- Block-stamped.Answers carry the block they were read at; a presence can say "as of block N" when it matters.
- Priced, with a source.USD figures come from the same digest, not the model's memory of prices.
- Honest gaps.If a view can't resolve (unindexed token, thin pool), the skill returns "unknown" and the presence says so rather than guessing.
The chain skill is read-only. Moving value is a separate, policy-gated path — reading something and acting on it are never the same permission.
More chains
New chains arrive as new skill backends behind the same four views and the same questions. A presence's code, preferences, and the way you ask never change when a chain is added — only the set of places it can look.