Those familiar with the Tezos ecosystem know that transacting on the network requires users to pay gas in Tezos’ native token, tez. But what about those users who don’t have tez and want to complete a transaction on Tezos? Or users who want to avoid paying for individual contract calls (e.g. voting in a DAO) that could be batched?
TZIP-17 enables account abstraction: emulating multiple account types using standardized contract calls. This is done through pre-signing: a method to sign and submit Tezos transactions separately.
For instance, a “relayer” can submit a user’s pre-signed (meta) transaction and pay the tez fees on their behalf; a process called gas abstraction. This is especially convenient for subsidizing user onboarding, collecting multiple signatures when voting in a DAO, signing in a multisig, or batching transactions.
For those familiar with Ethereum, TZIP-17’s functionality overlaps with two Ethereum EIPs:
- EIP-712: TZIP-17 similarly aims to improve the user experience of off-chain signing through its typed signing and hashing schema. Compound Finance makes use of EIP-712 in its governance module.
- EIP-1776: Similar meta-transaction functionality may be implemented using TZIP-17 by adding explicit nonce and gas parameters.
TZIP-17 expands the transactional model of Tezos: enabling developers to provide more native experiences for user onboarding and allowing users to pay fees using the token (e.g. a stablecoin) used in the transaction. The relayer still pays transaction fees in tez at the protocol level and, because Tezos is Proof-of-Stake, these transaction fees accrue to stakeholders rather than just a small group of miners.
Ultimately, brings the experience of using digital assets on Tezos more in line with that of traditional financial transactions and supports the use of Tezos as a settlement layer.
Below, we explain in greater detail how TZIP-17 works in the wild, with examples of using Permit for gas relaying and a simulated multisig. We also encourage users to check out Madfish’s Gas Station Network demo and a stablecoin reference implementation which implements Permit.
Key Resources
· Madfish’s Gas Station Network demo using Permit in LIGO
· Stablecoin Demo Implementation using Permit
Permit in the Wild
Gas Relaying
In a typical Tezos transaction, the signer (let’s call him Bob) signs for a transaction. Bob’s transaction JSON — which holds the parameter, the parameter hash, Bob’s address, the destination address KTfoo, a counter, and the transaction fee in tez — is submitted to a node. A baker validates the transaction, loading and running KTfoo. Finally, KTfoo processes the parameter from Bob and the transaction is complete.
Permit transactions are a little different. In order to create a Permit, Bob pre-signs for the transaction Bob wants. Bob’s Permit JSON includes the parameter hash, Bob’s public key, the destination address KTfoo, and a counter. It notably excludes the parameter and the tez needed for transactional costs. This data is submitted to the relayer, who acts as an auxiliary for Bob. The relayer submits Bobs request to a node on-chain, paying the transactional fee for Bob in tez. A baker validates this transaction and runs KTfoo, which saves this Permit from Bob.
When the Permit is used, the pre-signed transaction JSON is revealed to the relayer. This revealed data contains the parameter, Bob’s address, and the destination KTfoo. The relayer in turn submits this data to a node, where a baker loads and runs KTfoo. KTfoo processes the parameter as if it was sent directly from Bob, and it deletes the permit that allowed this relayed transaction to happen.
NORMAL TEZOS TRANSACTION
PERMIT CREATION
PERMIT USAGE
Integrated Multisig using TZIP-17
Permit can be used to add multisig administration to entrypoints without requiring a separate multisig contract.
Suppose our contract has an entrypoint “Foo” that we want to administrate using a multisig contract. This could be an entrypoint to mint FA2 tokens or update a Transferlist that permissions digital securities. The multisig contract will only execute a call to “Foo” when a threshold of admin signatures are provided.
We can simulate multisig administration for Foo within the contract by enabling Permit transactions and modifying Foo’s logic to only run once a threshold of admin’s have called it. This allows signatures to be provided explicitly in a batch, as with a multisig contract, or implicitly in individual Tezos transactions, by calling Foo as an admin.
The Impact of TZIP-17
TZIP-17’s gas relaying process gives anyone the opportunity to subsidize user onboarding to their application or send a token over Tezos without needing to spend tez. Its flexible signing schema is convenient when multiple signatures are required, for example in voting or multisig-type administration. These signatures may be batched in a single on-chain transaction to cut down on gas costs. This improves the end-user experience interacting with dApps from their wallets and brings the experience more in line with the applications and financial transactions most users are accustomed to.
As with prior releases, we encourage feedback on TZIP-17! Reach out if you have any questions, comments, suggestions, or would like to get involved!
