Preconfirmations, and nothing else.
preconfs.io sells a signed commitment that your transaction lands in a specific upcoming block, and a receipt you can verify yourself. You sign locally, we commit, you check the signature.
A promise made before the block exists.
A preconfirmation is a commitment, signed by the party that will build the block, that a specific transaction will be included in a specific upcoming block. It is not a transaction receipt and it is not finality. It reaches you far faster than the block itself, which is the whole point.
We run the auction
Requests enter a per-slot auction. A winning bid becomes a signed commitment naming the target block.
We publish the evidence
Every commitment has a signed receipt, and we publish whether it was kept or broken.
We do not do the rest
No nodes, no RPC access, no MEV software. Our product is the commitment and the evidence.
Five parts of one product.
Everything below is a piece of the same thing: getting a verifiable commitment for a transaction you have already signed.
Preconf API
Request a preconfirmation for a signed transaction over HTTPS, then read its status until the block is produced.
Commitment receipts
A signed receipt for every commitment, verifiable while the block is still pending.
Tip pricing
A tip per preconfirmation, set by your bid, with the current floor published per region.
Service levels
Response-time and inclusion targets written into the contract and reported against.
TypeScript and Python SDKs
Client libraries for both languages, on mainnet and testnet.
Documentation
A quickstart, the error codes, and the fallback path, kept next to the API they describe. Read the docs
Sign locally. Verify yourself.
We never see a private key and never build a transaction for you. The only thing that leaves your machine is bytes you already signed.
- Sign locally. Build and sign with your own keys.
- Request. Send the signed bytes, the target block and a maximum tip.
- Verify. Check the receipt signature against the published signer.
- Fall back. No commitment before your deadline? Send the same signed transaction to the public mempool.
# 1. sign the transaction with your own key (never shared)
tx=$(sign-transaction --key "$KEY" --nonce "$NONCE")
# 2. ask for a preconfirmation: signed bytes, target block, max tip
preconf request --tx "$tx" --block next --max-tip "$TIP"
# 3. verify the signed receipt yourself
preconf verify --receipt receipt.json
# 4. no commitment before your deadline? same signed tx, public mempool
send-raw-transaction "$tx"What a preconfirmation is not.
We would rather you know the edges before you build on us.
It is not finality
A preconfirmation is a promise, not finality. A later reorganisation can remove the block, and a commitment cannot undo that.
It does not promise success
Inclusion is not execution. A transaction can be included and still revert, unless you buy an execution preconf where it is offered.
Misses are visible
When a commitment is broken, the receipt says so and the service level decides the credit.
A person reads support
Support is by email, and a person reads it.
Short answers.
Do you run nodes or sell RPC access?
No. preconfs.io sells preconfirmations and nothing else.
Do you ever see my private key?
No. You sign locally and send only the signed bytes.
What happens if no commitment arrives?
Send the same signed transaction to the public mempool. The nonce never changes. The fallback path is documented.
Can I try it without real funds?
Yes. The same API and the same receipts run on the testnet, with separate keys.
New from preconfs.io.
Guides, posts and comparisons appear here as soon as they are published.
Build on a commitment you can verify.
Start on the testnet, exercise the error codes and the fallback, then move the same integration to mainnet by changing the key and the base URL.