3

I am working on a system that allows users to send and receive on the Polkadot network. The system tracks the amount of DOT controlled by a user, and this may be spread across multiple Polkadot accounts.

Scenario

  • A user controls many DOT addresses on our system
  • They wish to transfer balance to a DOT address
  • The balance to be transferred is greater than the balance of any one account that they control
  • We cannot allow sending accounts to be reaped

My solution is to broadcast multiple balance transfer Extrinsics ("components") such that the total amount transferred matches the total target balance transfer amount.

This is obviously inefficient since multiple inclusion fees/tips are paid, but this inefficiency is not a problem.

To prevent reaping of accounts controlled by our system, "component" Extrinsics either spend their full account balance or spend such that the Existential Balance on that account is maintained.

Is this (multiple "component" Extrinsics) my only option, or am I missing a better solution?

I have the following assumptions:

  1. A balance transfer Extrinsic that sends less than the Existential Deposit to a new (zero-balance) address is considered invalid and not accepted by the network.
  2. It is not possible to batch inputs in a Substrate/Polkadot Extrinsic - a single balance transfer cannot have multiple senders
  3. If two extrinsics are broadcast together and each sends (0.6 x Existential Deposit) to the same zero-balance address, both Extrinsics are invalid and will fail

Are these assumptions correct?

1 Answer 1

4

You can do this using derivative accounts. See this blog post for an example, although it's not exactly what you're looking for.

You've correctly spotted that a batch of extrinsics all must come from the same origin, which in general is an account. However, using utility.as_derivative, you can create derivative origins for a single account. So then you can do a batch with multiple as_derivative calls, since those will take on the derived origin.

A user controls many DOT addresses on our system

I assume here you mean that you control the keys, and allow users access to those accounts?

The as_derivative approach assumes that you control the address generation process, since if your users were generating their own addresses then you'd have no way to make sure their accounts are siblings.

1
  • Yes, we control keys and address generation - so this looks promising. Thanks!
    – csknk
    Commented Oct 19, 2022 at 8:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.