Seed senders regularly

[Sajjon]

Note

Target branch is not main, the target branch is the source branch of PR #86

Resolves comment https://github.com/paritytech/devops/issues/4297#issuecomment-3302247513

[sandreim]

I was expecting that we can just run the binary periodically via some k8s scheduling and running the pod for example every 12h or smth.

But ... we can also go this route, however if we put it here, I'd rather have some robust logic when this happens. Currently it happens when the TPS drops, but that can happen for other reasons like RPC issues.

[sandreim]

Also, seeding takes some time and there will be no txs submitted during that time.

[Sajjon]

I was expecting that we can just run the binary periodically via some k8s scheduling and running the pod for example every 12h or smth.

But ... we can also go this route, however if we put it here, I'd rather have some robust logic when this happens. Currently it happens when the TPS drops, but that can happen for other reasons like RPC issues.

Hmm, lets take a step back... we want to make transactions, but do we really need these transactions to contain fungible token transfers?

On Radix, a transaction can transfer 0 tokens (of any token, fungible or non-fungible), which still costs a transaction fee of course, but those are very small. So cannot we simply change the contents (the extrinsics?) of the transactions emitted, so that our sender "never" runs out of funds. By "never" I mean: ofc transactions costs a TX fee, but with enough initial funding we can calculate that for a riduculously high TPS (say 1 million), with a very high amount of senders (say 1 million) we can know that our service will be able to spam transactions for 100 years. That would remove the need to periodically fund senders, right? So what hinders us from doing this? :)

[sandreim]

👍🏼 . Then we don't need this, let's just bump the funds so they "never" run out.

[Sajjon]

Replaced by #89