TIP: 0003
Title: Establishment of common-use snapshots for airgrabs
Authors: Jesse Schulman <[email protected]>
Status: Adopted
Type: Informational
Created: 2018-07-30
Adopted: 2018-10-30 Voting - Yes: 27, No: 0, Abstain: 6
This proposal outlines a plan to make a snapshot of the genesis balances available on-chain, and proposes future scheduled snapshots as well. It also discusses the potential for modified versions of the eosio.token contract that would enable a very easy process to create airgrab tokens based on a specified snapshot.
Many dApps wish to distribute their own token via the “airdrop” method which requires a large upfront cost of RAM that must be paid for by the dApp’s account.
There is an alternative “airgrab” method which involves a user pre-allocating their row in the “accounts” table, thus paying for the RAM to store their balance of the new token. This leaves the user with a small amount of RAM consumed, and a zero balance of the dApps token. The dApp must then come in later and fill in the balance using what is likely an off-chain source of truth for the amount of tokens that the account will receive. This does not cost the dApp any ram but does however require many transactions so the dApp would need a reasonable amount staked for both CPU and Bandwidth, the more they have staked the faster they can get the balances set.
If there were an on-chain source of truth for the balances that the dApp wishes to use to determine how much of the dApp’s tokens the account will receive, then as part of the transaction that is signed by the account to airgrab the token, the dApp contract could query that source of truth and set the correct balance for the account. This provides the account with immediate access to the dApp’s tokens and requires zero RAM and zero CPU/Bandwidth from the dApp developer, without any significant downside for the account holder.
Create a new contract named “tlos.snapshots” which will have a “balances” table. This table will reflect the balance of TLOS tokens that a specific account had at a specific time. The initial balances would be a reflection of the TLOS genesis snapshot and would allow new dApps built on the Telos network to provide a free and fairly distributed token “airgrab” based on the TLOS genesis.
Potentially there would be further snapshots performed on a regular interval so that dApps launched much later after the launch of the network may choose to honor a more current set of balances and reward accounts who were not part of the genesis. There would need to be consideration for the amount of time that a dApp would allow their tokens to be claimed.
Imagine a situation where on the 1st of every month there is a “current” snapshot taken. This would mean that a dApp would only have one month for users to claim their token before a new set of balances would be reflected by the “current” snapshot. For this reason it may make the most sense to have a certain duration (1-2 months) between each snapshot, and to keep 2 active snapshots (plus genesis for maybe 1year?). With this approach, and lets say a 1.5 month duration between snapshots, we would have a July1 snapshot followed by an August15 snapshot and then an October1 snapshot. We would keep the July1 snapshot until the October1 snapshot is performed, which means any dApps using the July1 snapshot for their distribution would be claimable until October1. This also means that a dApp wishing to give users the full 3 months to claim their airdrop would need to wait up to 6 weeks to launch their token immediately after a snapshot.
The cost of this would grow as more accounts join the network, it would require enough RAM to store the balances of 2 snapshots at any given time, plus enough CPU/Bandwidth available at each snapshot time to update all of the balances.
The current eosio.token contract would need to be modified in place or copied and modified to add “claim” and “setClaimable” actions. The “claim” action is for accounts to claim their “airgrab” while the “setClaimable” action lets the dApp developer enable claiming and specify which snapshot to use, it would also have a multiplier/ratio parameter so they can issue more or less of the dApp’s tokens per TLOS token in the snapshot.
Make changes or create a new token contract to be deployed at bios/network boot time, owned and managed by the system. Currently the eosio.token contract that is deployed at the launch of the network is fully controlled by the eosio account and the multi-sig contract that is controlled by 2/3+1 of the 21 active BPs. It is designed to handle many more tokens than just the system (TLOS) token, however due to how it is controlled it is very difficult for any dApps to deploy their token on it. If there were a contract that allowed any other account to deploy a token on it, that would save a decent amount of RAM for dApp developers. Currently a dApp developer who wishes to issue tokens must either deploy their own copy of the eosio.token contract or integrate all its methods into their existing dApp contract. This is unnecessary effort/duplication and a waste of system resources (RAM). If the system had a modified version of the current token contract that allowed any account to call the “create” action, it would solve the resource/duplication problem but also would serve as a central registry of tokens on the network. It would need the same “claim” and “setClaimable” actions as described in the main proposal of this document. If a dApp developer wished to still use their own contract to manage the tokens, the system’s token contract could still offer a way for that dApp to “register” the token with the system, thus enabling this contract as a network-wide registry of tokens and enabling wallets to dynamically render token balances without needing hard-coded updates each time new tokens are issued on the network.
The Telos Foundation could provide a portal that would make it VERY simple for a dApp to create a token and set it as claimable based on a specified snapshot without even needing to deploy a token contract. The portal would serve as a front end to a standard airgrab contract so that users would only need to set simple parameters such as token name, supply, distributing contract/account, to be able to easily distribute an airgrab contract. Similarly that portal could be a centralized place for users to claim any of the registered airgrab tokens.
- How the contract RAM and CPU/Bandwidth for performing the snapshot will be paid for? (Suggestion: paid for by the Telos Foundation endowment.)
Douglas.tf: The Telos Foundation board has accepted the resource cost of maintaining these snapshots, which is primarily in RAM and brief usage of resources during the injection process.
- Who controls the keys and performs the ongoing snapshots? (Suggestion: the TF voters or their elected representatives.)
Douglas.tf: The Telos Foundation board controls the keys for the account: snapshots.tf
- How frequently to perform snapshots and how many historical snapshots to keep? (Suggestion: perform every two months; keep 2 snapshots at any given time.)
Douglas.tf: Without any formal vote, the block producers undertaking the snapshot process have settled on a timetable of capturing a snapshot every 6 million blocks (i.e. on block 6 million, 12 million, 18 million, etc.) and maintaining these for 1 year for the first snapshot and 2 months each for subsequent snapshots. These numbers emerged from community discussion and were employed due to general acceptance and lack of stong competing proposals.
- Do we also want to pursue the optional proposals?
Douglas.tf: The optional proposals do not require a governance amendment to implement. These ideas will be addressed by either the Telos Core Developers or individual developers, most likely using worker proposal funds.
This document is placed in the public domain.