Added retry logic to minaTransactionSender #360

Raunaque97 · 2025-11-25T13:28:41Z

closes #340

refactored minaTransactionSender to use a persistent Storage.
added a simple retry Strategy to increase fees by a multiple and retry every few minutes if the transaction is not included.
also handles the case if the sequencer restarts and the last sent transaction statuses were not updated in DB.

rpanic · 2025-11-26T14:54:32Z

So what I just discovered: When we setFee(), o1js erases all previous signatures in order for the tx to be signed again. And this makes sense - for the feepayer and some accountupdates, o1js uses the so-called "full commitment". This is simply just the hash of the whole transaction, including all accountupdates and the feepayer, whereas the non-full commitment would just the be hash of the current accountupdate.
Now, accountupdates can actually specify whether they want to use the full commitment or not (this is a field in the accountupdate struct that mina will receive as part of the transaction). And whatever commitment you choose, you signature or proof will only be valid given that exact commitment. it is kinda the basis on which you sign or prove. Now why is this important?
Signing or proving over a full commitment prevent replay attacks, like in other chains. But mina is a bit special, and unlike other chains, we sign a bunch of sub-parts individually. And so generally, in order to prevent somebody to rip out a part of our tx from the L1 mempool and replay it in their own specially-crafted malicious transaction and frontrun ours, we sign over the full commitment.
For resending transactions with a higher fee, this is a bit annoying - we don't want to re-prove the entire tx just because we changed the fee, right?
As I've mentioned above, luckily we can choose to opt-out of using the full commitment and use only the current accountupdate's commitment instead. But this is only possible in some distinct scenarios. My initial suspicious is that this is the case iff the accountupdate's validity is directly dependent on exclusively other full-commitment based accountupdates within the same transaction. But I'll have to think more on that definition.
Anyways, what we have to do before this PR will work without re-proving some accountupdates, is to use no full commitment generally. And for us to be able to do this, we need to examine the protocol and see if we can do this safely

rpanic

This is great! I have a few minor requests and questions, but I like it generally

rpanic · 2025-11-26T09:07:21Z

packages/persistance/prisma/schema.prisma

  messages IncomingMessageBatchTransaction[]
 }
+
+model PendingL1Transaction {


You forgot to create a migration for this new schema change - do this by cd-ing into the persistence pkg, then run prisma migrate dev and it'll you for a name and migrate

rpanic · 2025-11-27T12:28:16Z

packages/sequencer/src/settlement/transactions/DefaultL1TransactionRetryStrategy.ts

+    const currentFee = tx.transaction.feePayer.body.fee;
+    const newFee = UInt64.from(this.bumpFee(Number(currentFee.toBigInt())));
+    tx.setFee(newFee);
+    // Delay if needed


Can you explain what this delay here accomplishes? I'd expect this function to only craft the new transaction and return it...

This is used to add a delay between retries, like retrying a transaction every 5 minutes.

packages/sequencer/src/storage/repositories/PendingL1TransactionStorage.ts

rpanic · 2025-11-27T12:30:44Z

packages/persistance/prisma/schema.prisma

+  lastError      String?
+  sentAt         DateTime? 
+
+  @@id([sender, nonce])


I'm not against this schema, but I think for the reorg support we'll have to change this - but that will happen when we tackle that piece of work.

rpanic · 2025-11-27T12:31:50Z

packages/persistance/prisma/schema.prisma

+  lastError      String?
+  sentAt         DateTime? 
+
+  @@id([sender, nonce])


What I'd love to see would be if we could add foreign-key out of settlement here. So in the Settlement entity, add a reference to the PendingTransaction so that we can establish that link

packages/persistance/src/services/prisma/PrismaPendingL1TransactionStorage.ts

package.json

rpanic · 2025-11-27T12:50:29Z

packages/sequencer/src/settlement/transactions/DefaultL1TransactionRetryStrategy.ts

+    const tx = Transaction.fromJSON(JSON.parse(record.transactionJson));
+    const currentFee = tx.transaction.feePayer.body.fee;
+    const newFee = UInt64.from(this.bumpFee(Number(currentFee.toBigInt())));
+    tx.setFee(newFee);


As mentioned in the comment earlier, we need to figure something out to prevent re-proving

packages/sequencer/src/settlement/transactions/DefaultL1TransactionRetryStrategy.ts

packages/sequencer/src/settlement/transactions/MinaTransactionSender.ts

… db.

…endingL1TransactionStorage

…ttlementModule

… string

…nId instead of transactionHash, PendingL1TransactionStorage to use id as the primary identifier.

…ling

…edAt

- polling the chain and updating persistant storage is now handled by L1TransactionDispatcher - TxStatusWaiter is used for waiting on a txn to get sent, included.

…sactions

rpanic · 2026-01-15T14:25:55Z

packages/sequencer/src/protocol/baselayer/MinaBaseLayer.ts

+        useClass: TxStatusWaiter,
+      },
+
+      L1TransactionDispatcherConfig: {


So - the pattern that we should use here is by using useFactory instead of useValue and then returning the Dispatcher instance - so inside the factory, resolve the dispatcher from the given dependencycontainer, then setting the config

rpanic · 2026-01-15T14:27:09Z

packages/sequencer/src/settlement/transactions/MinaTransactionSender.ts

+    @inject("SettlementSigner") private readonly signer: MinaSigner,
+    @inject("FeeStrategy") private readonly feeStrategy: FeeStrategy,
+    private readonly dispatcher: L1TransactionDispatcher,
+    @inject("TxStatusWaiter") private readonly waiter: TxStatusWaiter


If I see it correctly, the waiter is only used inside the MinaTransactionSender and is not supposed to be overrideable - therefore I'd suggest resolving by class reference, not by token here

rpanic · 2026-01-15T14:29:30Z

packages/sequencer/src/settlement/transactions/MinaTransactionSender.ts

+    private readonly dispatcher: L1TransactionDispatcher,
+    @inject("TxStatusWaiter") private readonly waiter: TxStatusWaiter
+  ) {
+    this.dispatcher.start();


We can use @startable() here (like closeable) and then start the dispatcher in there

rpanic · 2026-01-15T14:31:23Z

packages/sequencer/src/settlement/transactions/L1TransactionDispatcher.ts

+        this.pollingTimeout.unref?.();
+      }
+    };
+    this.pollingTimeout = setTimeout(poll, this.config.pollIntervalMs);


I didn't know about unref - that's cool!
Why is this not a interval? Because of the unref or other reasons?

if a poll() call takes more than pollIntervalMs time, 2 calls can overlap

rpanic · 2026-01-15T14:34:51Z

packages/sequencer/src/settlement/transactions/L1TransactionRetryStrategy.ts

+   * Optional retry delay. If provided, the dispatcher will schedule
+   * the next retry after the delay from the last sentAt time.
+   */
+  getRetryDelayMs?(record: PendingL1TransactionRecord): number;


What happens if the user doesn't specify that function? When will we retry?

the retry will happen after inclusionTimeoutMs (default: 10 mins).
this delay is after checking for status ends.

rpanic · 2026-01-15T14:39:50Z

packages/sequencer/src/storage/repositories/PendingL1TransactionStorage.ts

+  attempts: number;
+  status: PendingL1TransactionStatus;
+  transaction: Transaction<any, any>;
+  hash?: string;


https://github.com/o1-labs/o1js/blob/main/CHANGELOG.md#added
The PR that we requested from florian is now merged, we should use a nightly version of o1js for now until this is released but already now integrate it into this PR and use the hash everywhere

rpanic requested changes Nov 28, 2025

View reviewed changes

Raunaque97 force-pushed the raun/retryMinaTransactions branch from 87ebda9 to 2fe0464 Compare December 18, 2025 13:32

Raunaque97 marked this pull request as ready for review December 18, 2025 13:51

Raunaque97 added 22 commits January 12, 2026 22:14

added PendingL1TransactionStorage for persisting mina transactions in…

fe09020

… db.

implementing PendingL1TransactionStorage

8f8f768

implementing L1TransactionRetryStrategy

b129ea7

added MinaSigner interface

1dd9d5e

updated MinaTransactionSender to use L1TransactionRetryStrategy and P…

def1b44

…endingL1TransactionStorage

fixing tests

3e90a3a

refactoring, removed feeStrategy dependencies from bridgingModule, se…

dd86edc

…ttlementModule

using SettlementSigner, and removing LocalMinaSigner

e5d8922

storing transaction obj in PendingL1TransactionRecord instead of json…

1f2f51a

… string

making MinaTransactionSender closeable

2068f62

Refactor PendingL1Transaction and Settlement models to use transactio…

235e41e

…nId instead of transactionHash, PendingL1TransactionStorage to use id as the primary identifier.

added a queued wait status in MinaTransactionSender

919fdf9

adding foreign key relation between Settlement and PendingL1Transaction

2617552

fixing lint errors

14f8827

created the migration file

dfe29e7

refactoring, renaming mappers

0bac257

lint fix

197fbeb

Add hash field to PendingL1Transaction model and added txn status pol…

b81ca92

…ling

added minaTransactionSender tests

debc765

updating PendingL1Transaction schema to include nextActionAt and queu…

9c6b506

…edAt

refactoring MinaTransactionSender.

f3f2085

- polling the chain and updating persistant storage is now handled by L1TransactionDispatcher - TxStatusWaiter is used for waiting on a txn to get sent, included.

fixing build errors after rebase

0ceb431

Raunaque97 force-pushed the raun/retryMinaTransactions branch from 087636c to 0ceb431 Compare January 12, 2026 17:07

Raunaque97 added 2 commits January 14, 2026 05:43

moved transactionDispatcher to MinaBaseLayer

a967a16

using signProveAndSendTransaction in place of proveAndSendTransaction

43a4c49

Raunaque97 force-pushed the raun/retryMinaTransactions branch from c88b741 to 70d884d Compare January 14, 2026 10:18

adjusted DI for TxStatusWaiter

eb8c39c

Raunaque97 force-pushed the raun/retryMinaTransactions branch from 68399ea to eb8c39c Compare January 15, 2026 10:45

updating the indexer schema

ccc3fdd

Raunaque97 force-pushed the raun/retryMinaTransactions branch from 5fcb3ed to ccc3fdd Compare January 15, 2026 13:03

Raunaque97 added 2 commits January 15, 2026 18:34

Merge remote-tracking branch 'origin/develop' into raun/retryMinaTran…

ce7a958

…sactions

fixing errors

abc396e

rpanic reviewed Jan 15, 2026

View reviewed changes

Added retry logic to minaTransactionSender #360

Are you sure you want to change the base?

Added retry logic to minaTransactionSender #360

Uh oh!

Conversation

Raunaque97 commented Nov 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rpanic commented Nov 26, 2025

Uh oh!

rpanic left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Raunaque97 commented Nov 25, 2025 •

edited

Loading