WEP 2: Customizable Sponsorship

Author Dmitry Kiselev <dkiselev@wavesplatform.com>
Last update 2019-07-23

1. Abstract

Now sponsorship is enabled only for Transfer and InvokeScript transactions. We believe that it is necessary to make this mechanism more flexible and provide users with more options for customization:

  • allow sponsorship of different transactions types and enable asset issuers to indicate which types of transactions they want to sponsor,

  • provide an opportunity to sponsor only transactions related to the sponsor’s account and assets,

  • allow smart assets’ sponsorship for adjustable sponsorship.

2. Motivation and Purposes

The commission for processing transactions is paid to miners in the WAVES token, but it is not always convenient for users to pay the commission with the WAVES token. In Waves, there is a mechanism that solves this problem - assets’ sponsorship.

Asset’s issuer can make it “sponsored” and it would mean that the asset can now be used to pay transaction fees. In this case, as a result of the transaction, the asset itself is sent to the issuer of the asset, and the issuer of the asset will pay the miner with the WAVES token.

Now sponsorship works only for Transfer and InvokeScript transactions, and only for non-smart assets, but we see no reason to be limited to these cases. We propose the following changes:

  1. Sponsoring all types of transactions.
  2. Sponsoring smart assets.
  3. Allowing to sponsor only transactions related to the sponsor’s account and assets.

The proposed changes are aimed to make the already existing mechanism of sponsorship more uniform, and to make the operations more flexible. Users will be able to pay for different types of transactions with sponsored assets, and asset issuers will be able to customize the sponsorship of their assets more finely. For example, for transactions that transfer assets (Transfer, MassTransfer, Exchange, InvokeScript), sponsorship can be configured so that this asset sponsors only those transactions in which this asset is transferred. Moreover, it will be possible to sponsor only transactions related to the sponsor’s account and assets.

3. Specification

3.1. Private and Public Sponsorship

We propose to add public and private sponsorship. Private sponsorship allows you to sponsor only transactions related to the sponsor’s account and assets, while public sponsorship sponsors transactions regardless of whether they are associated with the sponsor account, and in this regard corresponds to the current sponsorship model.

Private sponsorship for an asset limits the set of transactions that can be paid for with this asset:

Transaction Type Where a private-sponsored asset can be used as fee-asset
Transfer, MassTransfer, Burn, Exchange Only transactions and orders involving any asset issued by the sponsor
InvokeScript Only InvokeScript transactions, in which dapp = sponsor, or transactions involving any asset issued by the sponsor (as payment.asset and/or scriptTransfer.asset)

3.2. Changes in Transaction Structure

Similar to the matcherFeeAsset field in orders ( WEP 1: Order Version 3 ), we suggest adding the feeAssetId field in all types of transactions.
In the SetSponsorshipTransaction, we will also need to add the sponsoredTransactions field — a list of transaction types that are sponsored by this asset, and the privateSponsorship field — a flag that means that the sponsorship is private.

Sponsorship can be canceled by sending a SetSponsorship transaction with minSponsoredAssetFee = 0, or it can be reset by sending another SetSponsorship transaction with new sponsorship terms.

3.3. Trade of Trading

If an asset’s issuer has set sponsorship to this asset for Exchange transactions, then this asset can be used as fee-asset when sending Exchange transactions to the blockchain and also for placing orders (matcher fee). Order fee sponsoring mechanism is as follows:

  • if order.matcherFeeAsset is not sponsored, then this asset goes directly to the matcher;
  • if in order.matcherFeeAsset is sponsored, then the payment goes according to the sponsorship mechanism (the asset goes back to the issuer, and the matcher receives WAVES from the issuer of the asset).

3.4. Adjusting Sponsored Assets

There are 2 options for sponsorship: non-smart asset and smart asset. Sponsorship of a non-smart asset can be configured by specifying sponsoredTransactions and privateSponsorship in the SetSponsorship transaction. If you want to set up sponsorship more flexibly, then you can create a smart asset and then make it sponsored. However, if you use an existing smart asset for this, undesirable situations may arise. For example, if the smart asset’s script forbids TransferTransactions, then it will entail the a ban on TransferTransaction sponsorship. Therefore, in such situations, it will be most convenient to create a new smart asset for sponsorship.

All transactions in which a smart asset is involved are validated by its script. Therefore, transactions with a smart fee-asset will also be validated by its script. In this case, the transaction during validation will be checked for compliance with the criteria specified in the SetSponsorship-transaction (the sponsoredTransactions and privateSponsorship fields), and for validity in accordance with the fee-asset script.

The logic of sponsorship has to be specified in the script of the asset. For example, this asset will only allow sponsorship of transfers from 1 WAVES and prohibit burning this asset:

let thisAssetId = base58'8jfD2JBLe23XtCCSQoTx5eAW5QCU6Mbxi3r78aNQLcNf'
# check if the asset is used as feeAsset
if (tx.feeAssetId == assetId)
        case tx : TransferTransaction =>
            tx.assetId == unit && tx.amount >= 100000000
        case _ => false
# otherwise the asset is not used as feeAsset
        case tx : BurnTransaction => false
        case _ => true

In this example, the cases in which the asset is used as feeAsset are handled in if-then branch:

     if (tx.feeAssetId == assetId) {...}

and cases when the asset is involved in a transaction in another role are handled in the if-else branch.

4. Rationale

4.1. Statistics

Currently, there are over 1000 SetSponsorship transactions in the blockchain. There’re about 850 active (not canceled) sponsorships. There are 576 sponsored assets, which were used to pay for at least one transaction.

Most actively used assets for all time:

  1. Mercury (HzfaJp8YQWLvQG4FkUxq2Q7iYWMYQ2k8UF89vVJAjWPj) - over 390,000 transfers sponsored.
  2. cryptogram (2sBjKeKCgTBYTpGARMKosU1uYJWct68RSZFHKvMzPieU) - over 356,000 transfers sponsored.
  3. feetoken (8RwwkZJ373Nm6fJCgV2Lefe6FeWawUY2APujcsauUNMR) - over 146,000 transfers sponsored.
  4. WOXcoin (B47PzFMea7HUjpZ8BYwWhPTkCNrdXutAhX8L9Z9tSBdq) - over 80,000 transfers sponsored.
  5. Splash (FZYGMR4tmkaHWjAG9DbUsyQkzymbUNvsDii1bY6jzYC9) - over 54,000 transfers sponsored.
  6. Ekd27 (4t5ZoGweFYqb7zzeL5VBQWMQhBXkUnsjkBD4Yx1UKwFH) - over 49,000 transfers sponsored.
  7. $GAX Gamaxa (2m4SEz8Bq9zgjBXF89Z1FQTkrUY6JYnvu9YFhitkBW51) - over 44,000 transfers sponsored.

Most actively used assets for the last month:

  1. Teletrasporto (4rMoqrum9TBHc9dhaEvGQGjU1bCT1Hi4e2UoknkEdeDo) - over 25,000 transfers sponsored.
  2. Splash (FZYGMR4tmkaHWjAG9DbUsyQkzymbUNvsDii1bY6jzYC9) - over 13,000 transfers sponsored.
  3. NY8CO (5uATXpwrhq1kqBj1haKafpuata4hwcsfYb2GdbvyxyNs) - over 9,000 transfers sponsored.
  4. FNEXT (DjEk4G6p8bnzL2RG6GQNhqnzcgKx2VRnBniY4Fh3MvhP) - over 9,000 transfers sponsored.
  5. WacchiCoin (A3JzXY3MLHzw582jcSuhDsW3Yi63fNjPm7VBzsacTV24) - over 6,000 transfers sponsored.
  6. GSNS (56Sf81MksDjepHEttFxte9oj5MU8MYh3V5EcFoEkWWoT) - over 6,000 transfers sponsored.
  7. WAVER (A1aZyGUyzreFAcZgSfcLgmMkJdQU4G3uG8NNbTpH8RNK) - over 5,000 transfers sponsored.

Since the introduction of Sponsorship feature, there have been over 2.2 million transfer transactions paid for by sponsored assets. The charts show that sponsored assets pay tens of thousands of transactions every week:

Chart 1. Number of transfers paid for via sponsored assets, weekly.

The total amounts of WAVES token transferred in transfer transactions paid for via sponsored assets are at approximately 10,000 WAVES per week:

Chart 2. The total amount of WAVES tokens transferred in transactions paid for via sponsored asset, weekly.

Thus, the statistics indicate that there is interest in sponsored transactions, and therefore we hope that the proposed functionality will also be convenient and useful.

4.2. Features of the proposed solution

The proposed solution has the following features:

  • With the new functionality it would be possible to cover a large number of cases of sponsorship (including in the sponsored asset script).
  • In most cases, sponsorship can be configured when setting the sponsorship (using the new sponsoredTransactions and privateSponsorship fields in SetSponsorshipTx) and no asset script is needed.
  • If the sponsored asset is a smart asset, then the script for this asset validates all transactions with this asset, including transactions sponsored by this asset.

5. Backwards Compatibility

All assets that are currently sponsored are not smart assets and their sponsorship is set only for Transfer transactions. Already existing sponsorships are considered public. After the introduction of new functionality, nothing will change for these assets: they will only sponsor transfer transactions.

Sponsorship for new smart assets will be flexibly customizable: it will be possible to state in the asset scripts what conditions are imposed on the transactions so that they could use this asset as fee-asset. Already existing smart assets can also be made sponsored:

  • If an asset has a script that can be changed, then the sponsorship can be customized in accordance with the needs of the asset’s issuer.

  • If the asset script cannot be changed, then situations are possible when sponsorship will not work as intended, as the smart asset script validates all transactions with this asset, including transactions sponsored by this asset. Therefore, in such situations, it will be most convenient to create a new smart asset for sponsoring.

6. Examples and Implementation

An example of SetSponsorshipTransaction version 2:

  "type" : 14,
  "version" : 2,
  "id" : "7EL2XEGP1By427BeLcHPYeVnBzGsXen4egMAwQpWGBVR",
  "senderPublicKey" : "5v5D5pqzKGBejtvtEeyDJXG28iQwMViu1uuetEcyQp9v",
  "assetId" : "FN76goSi7hQn6gQ8aezKVwyDvhkWx5ekXbP3sNLWqavN",
  "minSponsoredAssetFee" : 10,
  "sponsoredTransactions" : [4, 6, 7, 16],
  "privateSponsorship" : true,
  "fee" : 100000000,
  "feeAssetId" : "Q8aex5ekXbP3FN76goSi7hQn6gsNLWqzKVwyDvhkWavN",
  "timestamp" : 1534448057070,
  "proofs" : [ "3Q4JS4ujrGxAqp8LMXR9zZJC4tJ7YHiTo4SvMgrPhufo2UtR5x9JAaCGDjEr7qWXFDPJk7vWL8eapQkS45Dx1kcb" ]

In this transaction, sponsorship is set only for Transfer, Burn, Exchange transactions and placing orders with the sponsor’s assets and InvokeScript, in which the dapp is the sponsor’s address.


Please explain, why do you need this part:

If you can do the same with a script?

I prefer only script mechanic of the sponsorship to stay in this proposal.

Hi @deemru ,

the purpose of this is to cover the most cases of the needed functionality without forcing a user to write a script every time they set sponsorship (that needs some programming skills and may frustrate many unprepared users). So users can set sponsorship for their assets in just one simple transaction.

Also, this would allow to customize sponsorship for the assets that are not smart assets (and cannot be made smart therefore)

I think its important to allow sponsored fee of any tx, there is a lot that can be done and that don’t necessary require RIDE and invokescript. Example i want do a simple mass tx from my web app, currently type 11 only accept waves as fee, why would i do an invokescript and pay more fee just to be able to do it with token as fee? doesn’t make sens to me. Waves Keeper handle all tx and all tx don’t have to necessary go thru onchain script process all the time.

1 Like

Interesting, good resolution

1 Like