Introducing: Meta Transactions on Zilliqa via ZRC-3
Meta Transactions
To understand what Zilliqa Reference Contract 3 (ZRC-3) is useful for, you must understand the need meta transactions fill. They are part of a larger User and Developer Experience (UX, DX) improvement that the Ethereum community has been engaged in for the past couple years. The original meta transaction was devised to allow holders of an ERC-20 token to transfer that token without owning any ETH to pay gas fees. This was accomplished by sending the transaction to a third party that processes it and pays the barrier fee to the network. Since then the pattern has proliferated to include ERCs: 865, 965, 1035, 1077, 1776 and many more not directly related to token transfers like ERC-735 and UniversalLogins for identity management.
Meta Transactions are part of a powerful pattern for enabling the blockchain smart contracts to interact with off-chain data via a signed data submission. This signed data blob can be safely relayed by an untrusted third party because it is hashed and signed by its original author, making it tamper-proof. This enables such things as univerally accepted logins, cookie-based embedded wallets, gassless transfers and tokens with special authority-based properties like badges. With this context, you are ready to understand Zilliqa’s first implementation of this pattern: ZRC-3.
ZRC-2 and the Operator
ZRC-3 is an extension to ZRC-2 so it is impossible to understand without first addressing its predecessor: the standard for Fungible Tokens on Zilliqa. ZRC-2 is based largely on ERC-777, which extends ERC-20 with some small changes and the addition of an operator account, which can move tokens around on a user’s behalf and, problematically, without their consent. A well-behaved operator can perform many useful functions for the token holding community, but a faulty or malicious one can do serious damage to the community by engaging transfers without the relevant token holder’s consent.
The ERC-965 contract directly relates to ERC-777, as it enables gassless transfers via a ‘checkTransfer’. This function takes as input a signed data blob designating things like to, from, amount, fee and accountNonce. These modifications, when taken together upgrade the Operator into a Teller (like a bank teller or Automated Teller Machine (ATM)).
ZRC-3 and the Teller
In order to avoid the dangers of a Byzantine Operator, some modifications to its power within the contract were needed. By limiting its ability to transfer to only the cases where it has a signed transaction from the user, and validating that nested metatransaction on-chain, we can prevent the Operator from improperly spending funds.
There is however, a second concern. Both the Operator and Teller can receive transactions and wait to process them. For time-sensitive actions, it is recommended to supplement the reference implementation with a hashlock that designates the transaction valid for a certain finite range of block numbers. If this is not necessary, the default implementation includes the ability to recover these funds by skipping that nonce.
In order to protect the token holder, if you’ve submitted a signed check to a Teller, thus locking up your funds and you want them unlocked you only have to submit a regular transaction ahead of the processing of that check to invalidate it. Nonces are assumed always increasing, so by processing a new transaction the nonce you assigned to the check is no longer considered valid and the Teller’s meta transaction will no longer clear. This puts pressure on the Teller to process meta transactions fast, and makes the contract patterns conceptually familiar — if you don’t want to interact with the Teller, or perhaps have issues with the Teller, you can still interact with the token contract without ever needing the Teller’s services. In this way, the vulnerabilities introduced by an Operator can be turned into an entirely opt-in safe alternative transaction flow that allows for less crypto-savvy users to onboard into your DAPP in minutes instead of spending weeks waiting for KYC to get that tiny bit of gas they will need to engage transfers themselves.
Sustaining ventures with a Teller
The final part of this post will look forwards — what can this Teller pattern do for Zilliqa and token holders? The most obvious implications that onboarding is easier, tokens can be intentionally designed across more parameters and the token community does not pay for the convenience with any undue risks. But beyond this, a well-functioning token community might elect to use the Teller as their default method of payment and contribute to the development of this dapp project by paying fees (in the native token) that are in excess of the market-rate conversion of their gas fees. The excess funds from this difference in rates accumulates into a fund pool can then be used to pay for community-specific items like marketing, project funding, etc. I believe this token contract is central to realizing a modern DAO on Zilliqa, and it is in-fact the basis for my planned implementation of BlockScience’s Augmented Bonding Curve on Zilliqa. This implementation will empower would-be DAO creators to engineer a funding pool that outlasts a founder’s exit plan and provisions the continuation of the community — including the founders who have rejoined the community as commoners. The fees feed the governance of the DAO and inform it about how it is perceived by the community, as the community members might decide to pay the transfer in ZIL in protest of a bad decision.
