Skip to content

Commit cf27a2e

Browse files
committed
Separate websocket api reference
1 parent 59227c3 commit cf27a2e

File tree

3 files changed

+188
-10
lines changed

3 files changed

+188
-10
lines changed

pages/express-relay/_meta.json

Lines changed: 3 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -24,9 +24,10 @@
2424
},
2525

2626
"api-reference": {
27-
"title": "API Reference ↗",
28-
"href": "https://per-staging.dourolabs.app/docs/"
27+
"title": "HTTP API Reference ↗",
28+
"href": "https://pyth-express-relay-mainnet.asymmetric.re/docs/"
2929
},
30+
"websocket-api-reference": "Websocket API Reference",
3031
"contract-addresses": "Contract Addresses",
3132
"errors": "Error Codes",
3233
"examples": {

pages/express-relay/integrate-as-searcher/auction-server.mdx

Lines changed: 6 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -4,7 +4,7 @@
44

55
Searchers submit their bids on transactions they wish to execute to the off-chain auction server of the Express Relay. The auction server lives at (TODO: INSERT ENDPOINT), and its API documentation can be found here (TODO: INSERT SWAGGER DOCS). You can use the express relay [JavaScript SDK](https://www.npmjs.com/package/@pythnetwork/express-relay-evm-js) or [Python SDK](https://pypi.org/project/express-relay/) for a more native integration.
66

7-
To submit a bid to the auction server, a searcher can use either websocket (if they wish to subscribe to updates on the status of their bid) or the HTTP `/v1/bids` POST method.
7+
To submit a bid to the auction server, a searcher can use either websocket (if they wish to subscribe to updates on the status of their bid) or the HTTP `/v1/bids` POST method.
88

99
### HTTP
1010

@@ -21,11 +21,12 @@ The HTTP POST request should be submitted with a JSON request body representing
2121
```
2222

2323
The fields of this object are described in more detail below:
24+
2425
- `chain_id`: The `string` identifying the chain on which the searcher wishes to submit the transaction.
2526
- `permission_key`: The `bytes` (in the form of a 0x-prefixed hex string) that serve as the unique identifying information for a position within a protocol
2627
- `target_contract`: The `address` of the contract the searcher wishes to call from the `ExpressRelay` contract. This could be the searcher's own contract or the [`OpportunityAdapterFactory` contract](./integrate-as-searcher/opportunity-adapter).
2728
- `target_calldata`: The `bytes` (in the form of a 0x-prefixed hex string) of the calldata the searcher wishes to call the `targetContract` with.
28-
- `amount`: The amount of ETH (in wei) the searcher is bidding for their transaction's priority.
29+
- `amount`: The amount of ETH (in wei) the searcher is bidding for their transaction's priority.
2930

3031
### WebSocket
3132

@@ -62,10 +63,6 @@ A successful response to bid submission has the following schema:
6263

6364
From this point on, you will receive notifications about the bid status updates in JSON format. There are four types of bid status updates ("pending", "submitted", "lost", "won"), and you can find more details and examples in the `BidStatus` schema in the Schemas section of the API documentation (TODO: INSERT SWAGGER DOCS).
6465

65-
#### WebSocket connection persistence
66-
67-
The WebSocket server responds to ping messages according to WebSocket standards. Additionally, the server periodically sends a ping message to the client to ensure the connection is still active and expects a pong in return.
68-
6966
## Discovering transactions to bid on
7067

7168
In addition, the server has a set of opportunity endpoints that expose [opportunities](./how-express-relay-works/opportunities) as they become available. An `Opportunity` has the following structure:
@@ -94,6 +91,7 @@ In addition, the server has a set of opportunity endpoints that expose [opportun
9491
```
9592

9693
The fields of the `Opportunity` are described below:
94+
9795
- `chain_id`: The chain id where the opportunity is available
9896
- `permission_key`: The permission key corresponding to the opportunity
9997
- `target_contract`: The protocol contract address where the opportunity is available
@@ -156,7 +154,7 @@ function callLiquidation(Opportunity memory opp){
156154
let token = opp.buy_tokens[j];
157155
before = IERC20(token.contract).balanceOf(address(this));
158156
}
159-
157+
160158
opp.target_contract.call{value: opp.target_call_value}(opp.target_calldata);
161159
162160
uint256[] after = new uint256[](opp.buy_tokens.length);
@@ -170,4 +168,4 @@ function callLiquidation(Opportunity memory opp){
170168
...
171169
```
172170

173-
Note that the protocol contract (`opp.contract`) expects the caller to have already approved the necessary amount from the `sell_tokens` to the protocol. Also note that the custom contract will be expected to pay the specified bid in ETH while it is called.
171+
Note that the protocol contract (`opp.contract`) expects the caller to have already approved the necessary amount from the `sell_tokens` to the protocol. Also note that the custom contract will be expected to pay the specified bid in ETH while it is called.
Lines changed: 179 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,179 @@
1+
# Websocket API Reference
2+
3+
You can connect to the server via websocket in order to reduce latency and subscribe to various events. The websocket endpoint relies at `/v1/ws`(e.g `wss://pyth-express-relay-mainnet.asymmetric.re/v1/ws`)
4+
5+
## General format
6+
7+
Each request sent to the server via websocket should be in the following json format:
8+
9+
```json
10+
{
11+
"id": "...", // used for uniquely identifying the responses to requests
12+
"method": "...", // name of the server method to invoke
13+
"params": {...} // parameters necessary for the method
14+
}
15+
```
16+
17+
The server responds using the same `id` specified in the request:
18+
19+
```json
20+
{
21+
"id": "...",
22+
"status": "success",
23+
"result": {}
24+
}
25+
```
26+
27+
In case of error, `status` field will be `error` and the error message will be available in the `result` field as a string:
28+
29+
```json
30+
{
31+
"id": "...",
32+
"status": "error",
33+
"result": "..."
34+
}
35+
```
36+
37+
## Subscribing to opportunities
38+
39+
To subscribe to opportunities you can send a request with the `chain_ids` parameter which specifies the chains as an array.
40+
41+
```json
42+
{
43+
"id": "1",
44+
"method": "subscribe",
45+
"params": {
46+
"chain_ids": ["op_sepolia"]
47+
}
48+
}
49+
```
50+
51+
After a successful subscription you will receive the new opportunities for the selected chains via the websocket in the following format:
52+
53+
```json
54+
{
55+
"type": "new_opportunity",
56+
"opportunity": {...}
57+
}
58+
```
59+
60+
The schema for the opportunity is similar to what’s returned in the [http requests](https://pyth-express-relay-mainnet.asymmetric.re/docs/#/liquidation/get_opportunities)
61+
62+
In order to unsubscribe from a list of chains you can send the following message:
63+
64+
```json
65+
{
66+
"id": "1",
67+
"method": "unsubscribe",
68+
"params": {
69+
"chain_ids": ["op_sepolia"]
70+
}
71+
}
72+
```
73+
74+
## Submitting bids
75+
76+
In addition to the http methods, you can submit your bids via websocket in order to avoid additional network round-trips and get notified about changes to your bid status. Here is an example json payload for submitting a new bid
77+
78+
```json
79+
{
80+
"id": "1",
81+
"method": "post_bid",
82+
"params": {
83+
"bid": {
84+
"amount": "10",
85+
"calldata": "0xdeadbeef",
86+
"chain_id": "sepolia",
87+
"contract": "0xcA11bde05977b3631167028862bE2a173976CA11",
88+
"permission_key": "0xdeadbeefcafe"
89+
}
90+
}
91+
}
92+
```
93+
94+
A successful response to bid submission has the following schema:
95+
96+
```json
97+
{
98+
"id": "1", // websocket request id
99+
"status": "success",
100+
"result": {
101+
"id": "beedbeed-b346-4fa1-8fab-2541a9e1872d", //bid id
102+
"status": "OK"
103+
}
104+
}
105+
```
106+
107+
From this point you will receive notifications about the bid status updates in JSON format. We share four examples below, one for each of the status options (”pending”, “submitted”, “lost”, “won”):
108+
109+
```json
110+
// pending
111+
// The temporary state which means the auction for this bid is pending
112+
{
113+
"type": "bid_status_update",
114+
"status": {
115+
"id": "1eaee2a4-01bf-4f6c-8a76-21fadb2c43b1",
116+
"bid_status": {
117+
"type": "pending"
118+
}
119+
}
120+
}
121+
122+
// submitted
123+
// The bid is submitted to the chain, which is placed at the given index of the transaction with the given hash
124+
// This state is temporary and will be updated to either lost or won after conclusion of the auction
125+
{
126+
"type": "bid_status_update",
127+
"status": {
128+
"id": "beedbeed-0e42-400f-a8ef-d78aa5422252",
129+
"bid_status": {
130+
// the enum for the bid_status
131+
"type": "submitted",
132+
// the hash of the transaction that the bid's calldata was included in
133+
"result": "0xabc393b634fdf3eb45be8350fd16cd1b4add47b96059beacc1d8c20e51d75ec3",
134+
// the index of the bid calldata within the multicall bundle for the above transaction
135+
"index": 0
136+
}
137+
}
138+
}
139+
140+
// lost
141+
// The bid lost the auction, which is concluded with the transaction with the given hash and index
142+
// The result will be None if the auction was concluded off-chain and no auction was submitted to the chain
143+
// The index will be None if the bid was not submitted to the chain and lost the auction by off-chain calculation
144+
// There are cases where the result is not none and the index is none.
145+
// It is because other bids were selected for submission to the chain, but not this one.
146+
{
147+
"type": "bid_status_update",
148+
"status": {
149+
"id": "1eaee2a4-01bf-4f6c-8a76-21fadb2c43b1",
150+
"bid_status": {
151+
"type": "lost",
152+
"result": "0x99c2bf411330ae997632f88abe8f86c0d1f4c448f7d5061319d23814a0fb1135"
153+
}
154+
}
155+
}
156+
157+
// won
158+
// The bid won the auction, which is concluded with the transaction with the given hash and index
159+
{
160+
"type": "bid_status_update",
161+
"status": {
162+
"id": "beedbeed-0e42-400f-a8ef-d78aa5422252",
163+
"bid_status": {
164+
// the enum for the bid_status
165+
"type": "won",
166+
// the hash of the transaction that the bid's calldata was included in
167+
"result": "0xabc393b634fdf3eb45be8350fd16cd1b4add47b96059beacc1d8c20e51d75ec3",
168+
// the index of the bid calldata within the multicall bundle for the above transaction
169+
"index": 0
170+
}
171+
}
172+
}
173+
```
174+
175+
## Connection Persistence
176+
177+
The websocket server responds to ping messages according to websocket standards.
178+
179+
Additionally, the server periodically sends a ping message to the client to ensure the connection is still active and expects a pong in return.

0 commit comments

Comments
 (0)