Added retry logic to minaTransactionSender by Raunaque97 · Pull Request #360 · proto-kit/framework

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

 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

+ 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.

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

+ 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

+ 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

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

+ 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

… 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

+ 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

+ @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

+ 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

+ 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

+ * 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

+ 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

removed hash field from PendingL1Transaction model

rpanic requested changes Nov 28, 2025
View reviewed changes

Raunaque97 force-pushed the raun/retryMinaTransactions branch from 87ebda9 to 2fe0464Compare 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 0ceb431Compare 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 70d884dCompare January 14, 2026 10:18

adjusted DI for TxStatusWaiter
eb8c39c

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

updating the indexer schema
ccc3fdd

Raunaque97 force-pushed the raun/retryMinaTransactions branch from 5fcb3ed to ccc3fddCompare 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

Raunaque97 added 4 commits January 20, 2026 01:47

Refactored DI for L1TransactionDispatcher, MinaTransactionSender
c03336b

using o1js nightly build,
090ac91
removed hash field from PendingL1Transaction model

updating tests for MinaTransactionSender
0067369

prisma migrate indexer schema
3c978a8

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!

2 participants

Raunaque97 commented Nov 25, 2025•
edited
Loading