# Submit Bid

{% hint style="danger" %}
Shio permanently shut down on 12 May 2026. This page is kept as a historical reference only; the Shio feed, bidding APIs, explorer, and RPC endpoints are no longer active.
{% endhint %}

Once an `auctionStarted` event had been seen, searchers could submit bids.

The Bid with the highest `bid_amount` won, while paying exactly that amount.

## Conditions for a Bid to be accepted

A Bid had to satisfy all conditions below in order to be accepted.

* A Bid could be submitted before the given deadline (specified by `deadlineTimestampMs`). Since that window could be extremely short (usually 200-300ms), searchers were strongly recommended to host services in **Frankfurt, Germany** to avoid unnecessary round trips.
* A Bid **MUST** have a lexicologically larger transaction digest compared to the opportunity transaction's. Comparison was done with the two digests' binary form (represented as 32-byte binaries), rather than base-58 encoded. This is because in the implementation of [Soft Bundle (SIP-19)](https://github.com/sui-foundation/sips/blob/main/sips/sip-19.md), Shio chose the transaction with the smallest digest to determine submission order. One way to achieve this was to keep increasing gas budget by 1, until the digest of the transaction satisfied the condition.
* A bid had to have the exact `gas_price` as the opportunity transaction's.
* A bid had to avoid locking any object that had already been locked by the opportunity transaction.
* A bid had to contain a MoveCall to the `submit_bid` method of the Shio package, paying exactly `bid_amount`, see [Interact with Shio Contract](/archived-searcher-guides/interact-with-shio-contract.md).
* A bid had to pass dry-run in the bundle of \[opportunity transaction, bid].

## Bid Submission

There were two ways to submit a bid:

* A Bid could be submitted directly through the Feed WebSocket connection. This approach appeared to be simpler (by not having to maintain more than one client), however, in case of bid rejection, exact reason would not be returned.
* Or alternatively, a bid could also be submitted through JSON-RPC method `shio_submitBid`. An error message would be returned directly, explaining why the bid had been rejected if that was the case.

### Submission through WebSocket

Searchers sent a message in the following format through the Feed WebSocket connection:

```json
{
  "oppTxDigest": "E72mG9GCroPgaw9uoeGiKLzAfd9CZq82iGDjypKdzYG7",
  "bidAmount": 42000000000,
  "txData": "base64Encoded",
  "sig": "base64Encoded"
}
```

* `bidAmount` is in terms of MIST. This was the amount that needed to be paid on successful execution.
* `txData`: Base64-encoded bcs-serialized TransactionData without signature.
* `sig`: Base64-encoded signature. Shio only supported the ED25519 signature scheme.

Bids had to be sent within the given Auction Window.

Once sent, the bid would either be accepted or rejected; however, no response would be given.

For troubleshooting, please refer to Submission through JSON-RPC .

### Submission through JSON-RPC

Historically, searchers sent a JSON-RPC request to `https://rpc.getshio.com` in the following format. This endpoint is no longer active.

```json
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "shio_submitBid",
  "params": [
    "E72mG9GCroPgaw9uoeGiKLzAfd9CZq82iGDjypKdzYG7",
    42000000000,
    "txDataBase64Encoded",
    "sigBase64Encoded"
  ]
}
```

A response would be returned, containing error message if any.

This approach was not recommended in production, as extra RTTs could be incurred due to HTTP/TLS handshake.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.getshio.com/archived-searcher-guides/submit-bid.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.