LogoLogo
  • 📖What is Spire?
  • 🌊DA Builder
    • Blob Aggregation Conceptually
  • 📡Preconf Router
    • Developer API
    • Tutorial
  • 🧱Based Stack
    • Spire's flavor of L2 based sequencing
    • Customizable composability
    • Preconfirmations in the Based Stack
    • Execution environment / virtual machine
    • Sequencing revenue (MEV) retention
    • Traditional shared sequencing
    • Open source and credibly neutral
    • Future upgrades
    • What's holding L2 based rollups back today?
    • GitHub [spire-labs/based-stack]
  • 🏫Education Hub
    • Ethereum L2 Based Rollups
    • Based resources
    • Sequencing on Ethereum L1
    • Preconfirmations on Ethereum L1
    • Synchronous Composability
Powered by GitBook
LogoLogo

About Spire

  • Website
  • Writings
  • Career
  • Media Kit

Follow Us

  • X
  • Farcaster
On this page
  • 1. Submit a preconf request
  • 2. Query request status
  • 3. Query commitment
Edit on GitHub
  1. Preconf Router

Tutorial

PreviousDeveloper APINextBased Stack

Last updated 26 days ago

1. Submit a preconf request

To submit a preconf request fill in the following curl template with the params containing your raw transaction and RPC/v0 being the router's endpoint on the supported networks.

The router's endpoint and query parameters for the url (separate from the params field in the body) can be found in .

To submit a non-preconf request i.e. use the router to forward your request to a RPC provider either change the method (and the rest of the body) to not be eth_sendRawTransaction or in the url specify the preconf=false parameter.

curl -X POST \
  -H "Content-Type: application/json" \
  --data '{
    "jsonrpc":"2.0",
    "method":"eth_sendRawTransaction",
    "params":["0x..."],
    "id":1
  }' \
  RPC/v0?deadline=3...

A successful response returns the hash of your transaction but that transaction may not appear in any block explorer until a preconfer has submitted it to the mempool or the router failed to get a commitment and forwarded the request to a standard RPC provider.

The hash is used as a parameter to query so save it for the next step.

{
  "id":1,
  "jsonrpc":"2.0",
  "result":"0xe65664cabb0df5136290b4cc7e4b445ff5ed51d4ad667fb5163208be3f2cc6c2"
}

2. Query request status

Once a preconf request has been submitted you may use the hash to query its status to see if it has finished processing and if it has succeeded or failed.

A non-preconf request is not stored therefore an error / no data is returned.

A success comes from 2 states:

  • Attaining a commitment

  • Failed to gain commitment but successfully forwarded to RPC provider (if the user specified fallback=true )

curl "RPC/v0/data/transaction/<tx hash>"

A valid request will respond with something like

Note that status is Success meaning we either got a commitment or the request was forwarded on our behalf because we specified fallback=true . If it was set to false and the status is Success then we have a commitment from a preconfer.

{
  "result": {
    "query": {
      "chain_id": null,
      "deadline": 3,
      "fallback": true,
      "preconf": true,
      "priority": "Medium"
    },
    "request_id": 1,
    "status": "Success",
    "tx_hash": "0xe65664cabb0df5136290b4cc7e4b445ff5ed51d4ad667fb5163208be3f2cc6c2"
  }
}

3. Query commitment

If in the previous stage the status contained Success then we may attempt to query the commitment.

curl "RPC/v0/data/preconfirmation?tx_hash=0xe65664cabb0df5136290b4cc7e4b445ff5ed51d4ad667fb5163208be3f2cc6c2"

The response should contain the latest slot for the inclusion request, the preconfer that committed and their signature.

{
  "jsonrpc": "2.0",
  "id": "1",
  "result": {
    "tx_hash": "0xe65664cabb0df5136290b4cc7e4b445ff5ed51d4ad667fb5163208be3f2cc6c2",
    "signature": "0xd76605086cc7dababa113510a017512443fb0cfed77ce6e35caec13b88c313d335415784c5ccd484738981d8cb4bd6f952c18e33eb6adf8b544c4a98cd87f76300",
    "slot": "106",
    "preconfer": "f47b88e2-7c6f-4f01-bc2e-3e0b7c8714f7",
    "timestamp_sec": "1713879132"
  }
}
📡
Preconf Request