By Lin Oshitani
To achieve mass adoption, it is necessary to reach non-crypto users who may be unfamiliar with Tezos and don't necessarily own tez. Onboarding such users has a critical hurdle: They are required to use tez to cover the fees necessary for interacting with their assets, even if they don't currently hold any tez.
Consider, for instance, a gamer who is not interested in cryptocurrencies but still wishes to engage with their in-game assets recorded on Tezos. Similarly, imagine a user who seeks to use stable coins on Tezos but does not want to hold tez for fiscal or regulatory reasons. In both scenarios, the need for tez hinders the entry of these potential users.
Permits and Gas Station Networks (GSN) have been proposed to circumvent this issue, but they require individual dApps to integrate GSN support into their contract code. This demands the redeployment of existing contracts and explicit GSN support in new contract codes, which impedes broad adoption.
To address this challenge, we propose protocol-level support for users to initiate operations to any contract while having fees covered by a third party.
Proposed Solution
- The first host operation signify that the following operations can have tz_G as the src.
- The sig_G is the signature by tz_G against [tx1; tx2].
- The sig_H is the signature by tz_H against [host {..}; tx1; tx2];
- The fee for the whole batch will be payed by tz_H.
Furthermore, we enable batches sponsoring of multiple sponsees in one batch, as follows:
Example Use Cases
- Gaming dApps subsidize fees for interacting with their in-game assets.
- A third-party sponsor subsidizes fees in exchange for non-tez assets, such as on-chain stable coins or off-chain credit card payments.
- Organizations pay fees for specific marketing campaigns. E.g., Objkt.com gas fees paid by the Objkt.com for a week, all deposits to Tezos 2.0 paid by the foundation, etc.
- Wallets subsidizes some amount of transaction fees per month as a marketing campaign.
- A third-party sponsor covers fees for withdrawal from sapling contracts. This is done to ensure that withdrawals are not linked to a user's implicit account through fee-payer information (reference).
Example User Flow
Refer to the design document for more technical details of the proposal.
Please let us know what you think! We are very keen on all kinds of inputs and feedback.
If you want to know more about Marigold, please follow us on social media (Twitter, Reddit, Linkedin)!