Skip to main content

FAQ

1. What are inclusion preconfirmations, and where can Bolt be used?​

Inclusion preconfirmations allow users to receive near-instant feedback on the inclusion status of their transactions. Bolt enables users to interact with Ethereum as if they were using a regular web application, providing immediate responses for transfers, approvals, and mints. For more detail, check out our use cases documentation.

2. How can wallets integrate Bolt, and what changes are required?​

Check out our Wallet Integration documentation for detailed steps.

3. Can users send multiple preconfirmations at once?​

Yes, users can send multiple preconfirmations for non-contentious transactions (e.g., transfers, mints, approvals) that don't depend on each other. These transactions can be preconfirmed, and users will receive immediate feedback.

For example, a user can preconfirm multiple transfers or approvals in quick succession. However, certain transactions, like swaps, are more complex and require on-chain confirmation to know the final result. While the approval step for a swap can be preconfirmed instantly, the actual swap itself needs to be confirmed on-chain before the user sees the outcome. This is because the swap depends on the current market conditions and needs on-chain execution to complete.

4. How does Bolt handle transaction ordering?​

Bolt uses a First-Come-First-Serve (FCFS) model for transaction ordering. Proposers must maintain the correct nonce order and follow the protocol rules. The use of bundles and sidecar mechanisms ensures that transactions are correctly processed and included.

5. How does Bolt deal with transaction spam?​

Bolt RPC implements rate-limiting logic and reputation checks to prevent spam. Transactions from the same sender are monitored, and preconfirmations are queued to ensure smooth processing.

6. What is the lookahead feature in Bolt?​

The lookahead feature allows users to set a preference for how far in advance their transaction is preconfirmed. The default is currently set to 32 slots (approximately 6.4 minute), balancing UX and protocol efficiency. This can be adjusted based on data or user preferences.

7. What is the role of the Challenger contract in Bolt?​

The Challenger contract allows for the verification of inclusion preconfirmations. If a commitment is violated, users can open a challenge by posting a bond. If successful, they receive a portion of the slashed collateral, incentivizing the proposer to maintain integrity.

8. Can a user send a transaction conditional on another preconfirmed transaction?​

Yes, users can send transactions that are conditional on the preconfirmation of another transaction. This means that the second transaction will only proceed if the first one is successfully preconfirmed. To maintain consistency, proposers issue constraints to builders, typically following a First-In-First-Out (FIFO) policy. In some cases, using batches allows for a flexible ordering of transactions.

For example, suppose Alice sends 100 USDC to Bob, and Bob wants to send 50 USDC from that amount to Charlie. Bob's transaction is conditional on Alice's transaction being preconfirmed and included in the block first. This ensures that Bob only sends the funds after he has received them from Alice.

10. How can Bolt be integrated with existing restaking protocols?​

Bolt supports integration with restaking protocols like Symbiotic and Eigenlayer to allow validators to post external collateral. This integration helps maintain credibility and security for preconfirmations and ensures validators are sufficiently incentivized to follow through on commitments.

11. How does Bolt ensure security and prevent misuse?​

Bolt ensures security through a combination of economic collateral and the Challenger contract. Proposers must restake collateral, which can be slashed if they breach their commitments. The preconf tip smoothing mechanism and structured fee models further encourage honest behavior.

12. What if there is no proposer in the lookahead?​

If no proposer is available in the lookahead, the RPC defaults to sending the transaction to the mempool. This fallback mechanism ensures the transaction is processed, even if preconfirmation is not possible at that moment.

13. How can we track preconfirmed transactions?​

Preconfirmed transactions can be tracked using preconf_state on Bolt RPC endpoints. This state information ensures front-ends, wallets, and explorers can update user interfaces quickly and accurately. Plans to implement this feature are under development.