Asset classes and strategies
Every agent on Wakehood declares one asset class and at least one strategy tag. Together they are the whole classification system, and they are what Explore filters on. This page defines them and explains why they are enforced rather than free-form.
Why real-world assets change the picture
On a crypto-only chain, the only strategies an agent can honestly implement are crypto strategies. Arbitrage, momentum, market making, yield farming. That is the entire universe, and every agent directory built on such a chain looks the same.
Robinhood Chain is built for tokenized real-world assets. Equities and ETFs exist on it as tokens, which means an agent can hold and trade them the same way it holds and trades a native crypto asset, on the same rails, with the same settlement.
That is what makes classes like STOCK and ETF meaningful here rather than aspirational. A
sector rotation agent, a dividend strategy, an index rebalancer: these are ordinary financial
strategies that simply had nowhere to live on a crypto-only network. On an RWA chain they are
first class, and they can sit alongside a crypto arbitrage bot in the same index, filtered apart
by asset class.
It is also the reason the taxonomy needs classes at all. A single flat list of tags would put
yield farming and dividend strategy in the same bucket, which helps nobody.
The four classes
CRYPTO
Trades native crypto assets on Robinhood Chain. This is the familiar territory: tokens, liquidity pools, on-chain markets.
STOCK
Trades tokenized equities. The agent's positions are individual companies, represented as tokens on the chain rather than as shares in a brokerage account.
ETF
Trades tokenized ETFs and index products. The unit of exposure is a basket, not a single name, so the strategies are about weighting and rotation rather than stock picking.
MIXED
Trades across both crypto and tokenized real-world assets in one strategy. Use this when the agent genuinely spans both universes, for example a portfolio agent that rebalances between an index ETF and a crypto position. Do not use it as a way to reach a tag from another class: the class you pick is a claim about what the agent actually trades.
Strategy tags per class
Tags are scoped to the class. Pick at least one. You can pick more than one when they all apply.
| Asset class | Allowed strategy tags |
|---|---|
CRYPTO | arbitrage, momentum, market making, yield farming |
STOCK | equity trading, ETF rebalancing, dividend strategy, sector rotation |
ETF | ETF rebalancing, sector rotation, dividend strategy |
MIXED | the union of the CRYPTO and STOCK tag sets: arbitrage, momentum, market making, yield farming, equity trading, ETF rebalancing, dividend strategy, sector rotation |
Some tags deliberately appear under more than one class. sector rotation is coherent for both
an equities agent and an ETF agent, and the meaning is the same in both. Explore lets you filter
by tag across classes, or by class and tag together.
The taxonomy is enforced
The server does not accept free-form tags. When you publish, it takes your declared asset class, looks up the tags allowed for it, and refuses anything outside that set. If nothing valid is left, the publish is rejected with an error telling you to select at least one strategy tag for the class. See publishing an agent for where this sits in the flow.
This is a constraint on you, and it is on purpose.
A filter is only worth having if the values behind it mean something. The moment tags are
free-form, you get momentum, Momentum, momentum-strategy and momentum trading as four
separate entries, and the filter degrades into a tag cloud that nobody uses. Worse, tags become a
marketing surface: an agent that has nothing to do with arbitrage tags itself arbitrage because
that is what people search for.
A closed, per-class taxonomy keeps Explore honest. When you filter to ETF plus
dividend strategy, you get the agents whose authors made exactly that claim, and the claim is
constrained enough to be checkable by reading the code.
The tradeoff is real: if your strategy does not fit any existing tag, you have to choose the closest one and explain the nuance in your description. In Phase 1 the list is curated and fixed, and we would rather have a short, sharp list than a long, meaningless one.
Future: governance over the taxonomy
This is on the roadmap, not in the product.
Phase 5 proposes that holders of a $WAKE token govern this taxonomy: proposing and voting on new
categories and tags rather than leaving the list to us. That is the natural answer to the tradeoff
above, because the people who feel a missing tag most sharply are the people publishing agents.
To be explicit: no token exists, no governance exists, and none of it is built or promised. Today the list on this page is the list, and it is enforced exactly as described.