Feedback-request: Sponsored Operations

Research and Development
1

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

We propose to introduce a new host manager operation that enables the sponsor (the “host”) to include operations from the sponsee (the “guest”) in their operation batch. Below is an example where tz_H is sponsoring two operations tx1 and tx2 from tz_G:

{
  ...
  contents = [
    host { src=tz_H; guest_src=tz_G; guest_sig=sig_G };
      tx { src=tz_G; dst=KT_X; ...}; // tx1
      tx { src=tz_G; dst=KT_Y; ...}; // tx2
   ];
  signature = sig_H;
}
  • 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:

{
  ...
  contents = [
    host { src=tz_H; guest_src=tz_G; guest_sig=sig_G };
      tx { src=tz_G; dst=KT_X; ...}; 
      tx { src=tz_G; dst=KT_Y; ...};
    host {src=tz_H; guest_src=tz_G'; guest_sig=sig_G'}
      tx {src=tz_G'; dst=KT_Z; ...};
   ];
  signature = sig_H;
}

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

Untitled diagram-2023-11-16-122531
Untitled diagram-2023-11-16-1225313840×3472 225 KB

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.

5 Likes
2

The Taquito team have done a couple discussions on this topic after reading the design docs and some materials related to the implementation of sponsored operations. We have some preliminary questions to determine the impact of this feature.

  • Will there be a distinction between a regular transaction operation and a transaction operation that is created by a guest (to get sponsored)? Will there be an introduction to a new ‘guest operation’, or will Octez be modified to accommodate some existing operations to not require fees?

  • How does the guest and the host communicate? Will it be limited to just the application level? As we currently understand, the host can sponsor an account when it has access to the signed operation of a guest-created operation. Is this the intended use case, or will this use case be expanded upon in the future?

  • After a host sponsors and injects an operation for the guest, how will the injected operation results get back to the guest? What kind of format can we expect to receive from the host? (JSON, bytes, etc)

1 Like