1

Consider a digital bank with multi-currency deposits of crypto tokens (mirroring fiat), token exchange, transactions and digital wallets. The bank should charge configurable transaction fees with the upper limit. Forking Stelar seems like a viable option for this purpose. Stellar is able to mint and burn tokens, do the token exchange and transactions.

I would like to add several questions to these questions.

  • As documentation states, the inflation mechanism was disabled in protocol version 12. Where do the transaction fees go now? How to set up the native token fees to be accumulated on the central bank account?

  • Is it possible to limit the endless XLM supply? Where in the source code is this configured?

  • I see it's possible to configure transaction fees size. Do I understand this right that fees can be adjusted dynamically using JS SDK while the system is running?

  • Is it possible to configure the transaction fee upper limit?

  • Currently, there is no supported mechanism for setting token fees in tokens themselves (unlike Waves, which has this feature). However, looks like there is a workaround:

    Set "authorization required" for your asset but don't allowTrust to any user in general. Instead require them to sandwich every payment + payment fee operation between a allowTrust and a allowTrust(revoke) operation. This way your authorization (by co-signing every transaction with the asset issuer account) for using that asset is only granted temporarily within this atomic transaction.

    Altough there is SEP-8 showing a standardized way to automate the co-signing process, afaik there is yet no wallet around that implements it. You'll have to code your own wallet and co-signing service.

    I had in mind creating an automated exchange which will exchange fiat token onto native token dynamically upon creating a transaction, and enable users to pay the transaction fees after the exchange happened, under the hood. This will require oracle service with the exchange rate feeds. Which approach is better?

1 Answer 1

1

Where do the transaction fees go now?

To the inflation pool. Since there is no inflation redistribution process, those XLM tokens are effectively locked for now. This may change in the future, when the new inflation distribution proposal is introduced.

How to set up the native token fees to be accumulated on the central bank account?

There is no such option, but you always know current amount locked in the fee pool.

Is it possible to limit the endless XLM supply? Where in the source code is this configured?

The supply isn't endless, it is strictly limited. For example, current total existing XLM mount on the pubnet is 105443902087.3472865XLM (20B XLM in circulation, 55B XLM is locked forever, the rest locked on escrow accounts). When you create a private network, the genesis account receives 100000000000 XLM and you can regulate total XLM supply by burning unneeded tokens.

Do I understand this right that fees can be adjusted dynamically using JS SDK while the system is running?

Yes, you set up the maximum fee you are willing to pay for the transaction – individually for each transaction. But unlike other blockchains, Stellar Core nodes will usually charge the fraction of this fee depending on the network load. If there is no surge pricing (which takes effect only when there is more than 1000 operations are hanging in the mempool) you will be charged the minimum fee.

Is it possible to configure the transaction fee upper limit?

Yes, you always specify the upper limit in the transaction, see explanation above.

Currently, there is no supported mechanism for setting token fees in tokens themselves.

Right, and there is no plans to add such mechanism in the nearest future as far as I know. This might be tricky due to the on-chain DEX mechanics. Charging fees on-per trade basis may result in various edge cases because Stellar doesn't have the min lot size or min trade amount limitations – you can end up receiving zero asset amount on micro trades.

There is an alternative to allowTrust sandwich approach and it may be suitable for your case if you really want to build the on-chain bank. 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.

enable users to pay the transaction fees after the exchange happened, under the hood

I highly doubt that this can be implemented without writing a ton of code. You can charge the fees in the transaction itself. Also, check this cross-blockchain anchor implementation by Umbrel. A good starting point for building the fiat↔crypto and crypto↔crypto gateway mechanism.

1
  • 1
    Thanks for the detailed and informative answer, it helps greatly! I'd like to clarify if I got the idea with the additional signer correctly, if I may. I created a follow-up question for this: stellar.stackexchange.com/q/4289/3245
    – Poliakoff
    Commented Oct 19, 2020 at 17:25

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.