Real-world assets

What exists

The plain-language documentation describes three layers. Exactly one of them has code in this repository, and this reference documents that one.

So: there are prices, and there are contracts that hold and serve them. There is no margin engine, no collateral registry and no position contract to call. When those exist they will be documented here as call surfaces, not as intentions.

A price, not the asset

This is a statement about what the chain does, not a disclaimer bolted onto it. Nothing in the registry references an issuer, a custodian or a reserve, because there is none: Pickle issues no real-world asset and holds none. A feed named AAPL/USD is a number describing what that share trades at on a market elsewhere, published on this chain and nothing more.

Getting the asset list

Three ways, and the first one is almost always the right one. It needs no ABI, no address and no key.

# Every feed the chain carries, with its adapter, decimals, answer and age.
curl -s $RPC_URL \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"pickle_prices","params":[]}' \
  | jq '.result.feeds[] | {symbol, feedId, adapter, decimals, price, statusName, staleOnchain}'

# The count alone, when you only want to know whether the catalog changed.
curl -s $RPC_URL \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"pickle_prices","params":[]}' \
  | jq '.result.feeds | length'

$RPC_URL is the endpoint on Network parameters. The answer also carries blockNumber, timestamp, and the publisher and owner the registry names - read those if you want to know who could have written what you just read.

The 33 feeds

19 of the 33 are real-world assets. The split that matters operationally is a different one: 13 feeds are backed by spot venues and 20 come from Pyth alone - which is every real-world feed plus XMR/USD, the one crypto pair with no venue leg.

• 5 venues + Pyth. five spot venues, with a Pyth feed alongside as a cross-check and a stand-in
• Pyth only. Pyth only - no venue is listed for this feed, so an absent Pyth credential leaves it unpublished

Market column: always open - open every day, all day; NYSE hours - 09:30-16:00 New York, Monday to Friday, with the exchange holiday list; FX week - continuous Monday to Friday afternoon New York, closed Saturday, reopening Sunday evening; session with a daily break - a nearly-continuous session with a daily break and a closed Saturday. The schedules are the subject of Market hours, and handling them is not optional.

Five publish policies, not thirty-three

The step cap is the row most often misread. It is 0, and therefore disabled, on every crypto feed, and live on every real-world feed - so a real-world update that moves further than the cap in one step is skipped by the contract rather than written, unless the market status changed in the same update. That exception is what lets a weekend gap land.

What a feed record carries

The same fields are the feed's configuration on chain, so what you read from pickle_prices or from feeds(offset, limit) is this record plus the latest round. decimals is 8 on every feed today and the field allows 0 to 18: read it rather than assuming it, because the cost of being wrong is a price off by eight orders of magnitude.

Feed ids

A feed is keyed by a hash of its symbol, not by an index and not by an address:

bytes32 feedId = keccak256(bytes("ETH/USD"));

The canonical symbol, upper case, with a single slash - keccak256("ETH/USD"), not "ETH-USD" and not "eth/usd". The same 32 bytes key the contract's mappings, name the feed on the RPC, and appear as the indexed topic of every FeedUpdated log. You can compute it offline with any keccak-256 implementation; nothing has to be fetched to know it.

The node and the service both accept ETH/USD, ETH-USD, eth-usd or 0x<64 hex feed id and normalise before looking up, so a URL-safe spelling costs nothing.

Resolving the addresses

The price registry and one adapter per feed are predeploys: their addresses are fixed at genesis and canonical for the life of the chain. That is precisely why this reference resolves them instead of printing them.

• pickle_prices answers with the registry's address in core and each feed's adapter in feeds[].adapter, checksummed. That is the shortest path and it needs no ABI.
• pickle_price(feed) carries that feed's adapter; pickle_ethUsdPrice carries the adapter, the registry and, under contract, the adapter again, which is what a Chainlink reader should be pointed at.
• On chain, adapterOf(feedId) returns the deployed adapter and adapterAddress(feedId) recomputes it: the adapter is CREATE2 from the registry with salt = feedId, so its address is a pure function of the registry address and the symbol.
• The first-party applications resolve every address they use at runtime rather than compiling one in - shared-ui/config.js merges the deployment's address files into config.addresses at load.
• The explorer shows that address as an account, with its code and its activity, which is the human-readable cross-check that something is deployed there. It publishes no source and no ABI: the repository is not public yet, and the explorer verifies no contract.

# The registry and one feed's adapter, resolved from the chain itself.
curl -s $RPC_URL \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"pickle_price","params":["ETH-USD"]}' \
  | jq '{adapter: .result.adapter, feedId: .result.feedId}'

# Then prove the address has code before you call it.
curl -s $RPC_URL \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getCode","params":["<adapter>","latest"]}'

Verify a resolved address with an eth_getCode before your first call. A CALL to an account with no code succeeds and returns nothing, so a wrong address does not revert - it reads as a price of zero.