API reference, Deploys
Deploys stream
Every HyperCore deploy action as our node executes it (HIP-3 dexs and their markets, spot deploys, outcomes, validator votes): the rows of GET /v1/hypercore/deploys, pushed per block. One frame per block with all its matching events.
- Elysium: not served
- HyperCore
- HyperEVM: not served
- Not on Elysium or HyperEVM: a channel of HyperCore only
WebSocket channel hc.deploys on wss://api.femtos.xyz/v1/ws
Parameters
| Param | In | Example or values | Meaning |
|---|---|---|---|
kind | filter | (empty), perpDeploy, spotDeploy, outcomeDeploy, activateOutcomeDeployer, VoteGlobalAction | One kind: perpDeploy, spotDeploy, outcomeDeploy, activateOutcomeDeployer, VoteGlobalAction |
variant | filter | (optional) | Action key as written (registerAsset2, haltTrading, setFundingInterestRates, J…), an outcome operation (settleOutcome…); several keys: sorted, joined by commas |
dex | filter | (optional) | Perp dex or outcome venue (xyz, mkts, fox…) |
coin | filter | (optional) | Coin the action names (BTC, xyz:TSLA) |
user | filter | (optional) | Account the exchange answered for: 0x address or a named wallet's handle |
status | filter | (empty), ok, err | ok or err (refused) |
notable | filter | (empty), true | true: the notable actions only, the routine ones left out: `perpDeploy` `setFundingInterestRates` (each HIP-3 dex's funding interest rates), `outcomeDeploy` `registerStandaloneOutcomeFromTemplate` (every outcome registered from a template), `outcomeDeploy` `settleOutcome` (every outcome settlement, on any venue), `VoteGlobalAction` `LL` holding `registerTokensAndQuestion` (the validators' vote registering a question), `VoteGlobalAction` `LL` holding `registerTokensAndStandaloneOutcome` (the validators' vote registering an outcome), `VoteGlobalAction` `LL` holding `settleOutcome` (the validators' vote settling an outcome), `VoteGlobalAction` `LL` holding `settleQuestion2` (the validators' vote settling a question) |
Subscribe
{"op":"subscribe","channel":"hc.deploys","filter":{}}Key: Authorization: Bearer $FEMTOS_KEY. Get a free key, or with no browser through agent onboarding.
Response fields
| Field | Type | Meaning |
|---|---|---|
snapshot: true | DeployAction[] | the last 50 deploy actions matching the filter, oldest first: the rows of GET /v1/hypercore/deploys over the last 31 days, `pending` the blocks of that window it may lack, `head` how far the feed read; a `gap` whose actions the history holds is followed by a new snapshot when it can be read, a `not_stored` one is not (its blocks are pending) |
pending[] | object | null | Blocks of the snapshot's window whose actions it may lack, oldest first: the `pending` of GET /v1/hypercore/deploys for that window, plus the blocks of each `gap` since. A `gap` after the last span, with no action received between them, extends that span to the gap's end, the blocks between included. null: not known (the history could not be read): {fromBlock, toBlock, fromTime, toTime} |
head | object | null | How far the feed read (`time`: that block's): every action up to `block` has come but those of the `pending` blocks, later ones come live. The last `head` frame's, or the `head` of GET /v1/hypercore/deploys; null: not known yet: {block, time} |
data | DeployAction[] | each HyperCore deploy action our node executes, with its status and the exchange's answer, the node's JSON every digit as it wrote it (a named wallet's address: its handle): one frame per HyperCore block, `data` the block's matching events in order (a block with none sends nothing): {block, time, bundleHash, bundleIdx, actionIdx, kind, variant, dex, coin, user, entity, multiSigUser, …} |
data[].variant | string | The action's key besides `type` (an outcomeDeploy's: its operation's); several: sorted, joined by commas |
data[].status | ok | err | null | ok, or err (refused: `response` says why); null when the node wrote no answer |
data[].action | object | The action as the node wrote it, every digit as written (a named wallet's address: its handle): `{type, <variant>: {…}}`; inside a multiSig, its inner action |
latency_ms.source_to_sent | int | block → sent by the server |
batch | "block" | every live frame: one block, `data` its matching events |
status | "gap" | a frame of its own: events of those blocks will not come on this subscription (`from_block`, `to_block`, `from_time`, `to_time`, `channels`, `reason`). Not billed |
status | "head" | a frame of its own on each beat of the source (about every 10 s): every event up to `block` (`time` its time) has come, or a `gap` named it. Not billed |
Related: Deploys
- Deploy actions GET /v1/hypercore/deploys HyperCore
Every HyperCore deploy action, newest first: HIP-3 dexs and their markets, spot deploys, outcomes, validator votes, each as the node wrote it.
More
- This page as Markdown
- The whole API reference
- What HyperCore serves
- The whole API in one Markdown file
- OpenAPI 3.1 document
Agent guide (agents.md)llms.txtOpenAPIMCP serverGet an API keyChangelog