feat(funding-service): collect deposits sent to the funding account by SantiagoPittella · Pull Request #2604 · 0xMiden/node

SantiagoPittella · 2026-09-09T20:16:05Z

Summary

Adds funding for the funder account via a public pay-to-ID note holding the native asset, and the service finds and consumes it on its own.

Only public, pay-to-ID, targeting the funding account, holding nothing but the native asset are collected.

Deposits are consumed in their own transaction, so a note that turns out to be unconsumable cannot fail a request a client is waiting on.

--top-up-interval controls how often it runs, defaulting to one minute.

Changelog

[[entry]]
scope       = "funding-service"
impact      = "added"
description = "The service collects public pay-to-ID deposits sent to its funding account."

igamigo · 2026-09-09T22:13:41Z

Deposits are consumed in their own transaction, so a note that turns out to be unconsumable cannot fail a request a client is waiting on.

I think if the script is confirmed to be a P2ID script, then it should not be fallible to consume it as long as we know that it's targeting the service account ID.

Mirko-von-Leipzig · 2026-09-11T05:35:14Z


+        /// Interval at which the service collects deposits sent to the funding account.
+        #[arg(
+            long = "top-up-interval",


Somewhat sounds like its topping itself up somehow.

I would consider reserve this phrasing for requesting funds from the faucet on devnet/testnet?

Perhaps p2id-collection-interval?

Sounds good

Mirko-von-Leipzig · 2026-09-11T05:36:46Z

+        from_block: BlockNumber,
+    ) -> Result<SyncedNotes> {
+        let tip = self.chain_tip().await?;
+        // An empty range is rejected, and there is nothing to scan past the tip anyway.


I've always wondered if this isn't a bug tbh. Is an empty range request not just an empty response.

Considering that it is inclusive in both ends, an empty range means that start > end, which doesn't makes much sense. I don't see why it shouldn't be an error

Fair. I was thinking of rust ranges ie 7..3 is just an empty iterator

Mirko-von-Leipzig · 2026-09-11T05:43:55Z

+            .rpc_client
+            .clone()


I know you can get tonic to generate using Arc; I wonder if we shouldn't do that.

I don't remember using it before, will take a look

Mirko-von-Leipzig · 2026-09-11T05:47:30Z

+                    block_to: tip.as_u32(),
+                }),
+                prefix_len: NULLIFIER_PREFIX_LEN,
+                nullifiers: prefixes,


We should technically limit the size here?

sounds good, will use the server side limit

Mirko-von-Leipzig · 2026-09-11T05:50:10Z

+
+The scan restarts at the genesis block after a restart, because the service keeps nothing on disk. That costs one request: the node answers a whole block range in a single response, and returns only the blocks which hold a matching note.
+
+Two choices in this collection are deliberate. It runs as its own transaction rather than riding along with a funding transaction, because a deposit note comes from outside the service and a note which turns out to be unconsumable must not be able to fail a request a client is waiting on.


I think this shouldn't matter - a p2id note should always be consumeable? Though perhaps not if it is recalled by the sender?

Perhaps that is not worth optimising around though, both should be rare, so its unlikely that a top up and a fund request coincide in time.

also, it is simpler in the service side to have them split, since otherwise we would have two option:
a) request our inputs notes from the node on each funding tx
b) keep the collection of those notes in a separate task and add a channel to the worker

@igamigo this works for your initial comment too

Mirko-von-Leipzig · 2026-09-11T05:52:53Z

+    }
+
+    /// Collects deposits until the service shuts down.
+    pub async fn run(mut self, shutdown: CancellationToken) -> Result<()> {


Will this not conflict with the funding service itself?

As in, we should probably have a single loop that handles both incoming requests, and top-up collections? Or at least a mutex to lock things into sequential execution and submission?

The thing with incoming requests is that we need to scan the chain to get them. Though we can think of a way to merge them. Regarding the sequential execution: it is not really a problem because the account is built with rpc data, both executions will build the same account and the first one submitting will win the slot, making the other one to retry and that;s it

I was thinking something like a separate scanning task that identifies p2id notes and sends them to the main task which includes them as part of the finding tx

But overall this shouldn't matter much you're right

SantiagoPittella · 2026-09-11T21:01:20Z

@Mirko-von-Leipzig @igamigo due to the painfully large amount of conflicts, I opened #2615 which has the original change and the comments addressed in new commits

SantiagoPittella added this pull request to stack #2602 September 9, 2026 20:16

SantiagoPittella force-pushed the fs/3-network-and-monitor branch from 4b96675 to ecd416b Compare September 9, 2026 20:29

SantiagoPittella force-pushed the fs/4-account-top-up branch from 4e184b7 to 93f7642 Compare September 9, 2026 20:29

SantiagoPittella added 4 commits September 10, 2026 13:48

feat(funding-service): add server and status endpoint

e2256d4

feat(funding-service): add the RequestFunds endpoint

02509de

feat(network-monitor): fund accounts from the funding service

6b76a4a

feat(funding-service): collect deposits sent to the funding account

3e9bef4

SantiagoPittella force-pushed the fs/3-network-and-monitor branch from ecd416b to 6b76a4a Compare September 10, 2026 16:48

SantiagoPittella force-pushed the fs/4-account-top-up branch from 93f7642 to 3e9bef4 Compare September 10, 2026 16:48

Mirko-von-Leipzig reviewed Sep 11, 2026

View reviewed changes

SantiagoPittella force-pushed the fs/3-network-and-monitor branch from 6b76a4a to 2a26ac9 Compare September 11, 2026 18:47

SantiagoPittella closed this Sep 11, 2026

SantiagoPittella removed this pull request from stack #2602 September 11, 2026 21:01


		The scan restarts at the genesis block after a restart, because the service keeps nothing on disk. That costs one request: the node answers a whole block range in a single response, and returns only the blocks which hold a matching note.

		Two choices in this collection are deliberate. It runs as its own transaction rather than riding along with a funding transaction, because a deposit note comes from outside the service and a note which turns out to be unconsumable must not be able to fail a request a client is waiting on.

Uh oh!

Conversation

SantiagoPittella commented Sep 9, 2026

Summary

Changelog

Uh oh!

igamigo commented Sep 9, 2026

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!

Mirko-von-Leipzig Sep 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

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!

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!

SantiagoPittella commented Sep 11, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Mirko-von-Leipzig Sep 11, 2026 •

edited

Loading