How to enable transaction fees with multi-sig?

Question

Consider a digital bank with deposits of different assets and transactions between digital wallets. All transactions have mandatory transaction fees, collected by the bank.

An interesting approach to the implementation of this concept was proposed:

During the user onboarding process you can add an additional signer to the account. This allows you to control all operations of this account. A user can't transfer or exchange any assets without your explicit permission – a signature on the transaction is required. At the same time, you can't do anything either with this account without user's confirmation. Such a scheme allows you to enforce general policies (like KYC & AML) and build complex individual validation rules for your users.

I'd like to confirm if I got the idea. The bank and the user have their private keys. An additional signer (the bank) is being added to the user account with Set options upon creation. This way, there are no users in the system who can perform any operation without the bank permission.

In order for the system to work fast, the auto-sign automated service is needed. To transfer the asset, user wallet software creates the transaction with 2 operations: transfer per se and bank fee. This transaction is being sent to the auto-sign service, which validates the fee size (off-chain) and broadcasts the transaction to the network.

In the case of a malicious/invalid transaction attempt, for instance, a transaction without the bank fee, this transaction is being declined by the auto-sign service and it's not valid. This way, every transaction in the network is controlled by the bank and contains its network fees.

Is this correct?

Answer 1

Yes, exactly. That's the essence of the idea.

To transfer the asset, user wallet software creates the transaction with 2 operations: transfer per se and bank fee.

That's right. As an alternative, you can charge the monthly fee or use any other fee schedule (simply block all account operations until the user pays the monthly service fee for the next month). Especially useful for micro-payments.

This transaction is being sent to the auto-sign service, which validates the fee size (off-chain) and broadcasts the transaction to the network.

Often it's better to sign and send the tx back to the client. Submitting the transaction from the client side has a few advantages. For instance, the client will unlikely to hit Horizon's rate limits. To prevent this from happening on the server side, you'll additionally need to build a processing queue.

This way, every transaction in the network is controlled by the bank and contains its network fees.

Yep, as I said, any validation logic can be enforced this way.

---

You might also want to add a third trusted party as a signer while setting all thresholds to 2. As a result, you have a 2-of-3 multisig on all bank-controlled accounts.

This approach mirrors the real-world scenario:

• a user can transfer funds if the bank confirms the transaction
• in case if bank misbehaves, a user contacts the government which can seize funds
• and if a user has been spotted in illicit activity, or, say, in case of user's death, the bank can access funds under government supervision

The third trusted party can be very helpful in various situations. For example, it can help to recover access if the user's secret key is lost, or liquidate dormant accounts that have been inactive for a few years.