Skip to main content

Data and Indexing

Raphael's contracts are the source of truth. Applications can combine direct RPC reads for live state with indexed historical data for everything else, provided they stay honest about which is which.

Direct reads​

Use standard eth_call requests through viem, ethers or another EVM client for current state such as:

  • pool reserves, liquidity, fee and current price;
  • token metadata and balances;
  • gauge status and reward rate;
  • veNFT amount, expiry and voting power;
  • current epoch and vote weights;
  • claimable fees, emissions and incentives.

Batch independent reads with Multicall to reduce latency and RPC usage.

Onchain helper contracts​

Upstream ve(3,3) deployments commonly use a Sugar-style helper contract to aggregate pools and protocol state in a single call. A Raphael integration must use such a helper only if a Raphael-specific helper address and compatible ABI are published.

Useful paginated patterns include:

  • count pools;
  • fetch pools by index range;
  • fetch a pool by address;
  • fetch compact pool data for swap routing.

Never assume an upstream helper's factory filters or address constants match Raphael.

Indexers​

Use an indexer when the application needs:

  • historical volume and fees;
  • position history;
  • epoch snapshots;
  • charts and APR time series;
  • searchable token and pool lists.

Indexers can lag or reorg. Display their freshness, and use direct onchain reads for transaction-critical state.

Production RPC​

Robinhood's public RPC is rate limited. Production services should use a dedicated provider, retries with bounded backoff, request batching, cache policies and archive access where historical state is required.