The goal of our usage mining program is to provide our community with ownership of the APIS protocol. The API token is used to govern the APIS protocol, stake as insurance against improperly executed reads or writes, stake on different sides of disputes should an APIS node or gateway act maliciously, and validate the layer-two scaling solution used by the APIS protocol. Because the API token is so crucial for the APIS protocol’s functioning, we believe that a maximally decentralized distribution of API tokens into the hands of those who care about the APIS protocol would be best for the APIS protocol’s success.
43,000,000 API (43% of the total supply) are allocated to the usage mining program. Both sides of the API marketplace (supply and demand) are equally important, and thus the usage mining program is split evenly between both:
Supply: 21,500,000 API
(API Nodes and Gateways who provide reads/writes)
Demand: 21,500,000 API
(Applications and Websites who need reads/writes)
Both sides of the marketplace will follow the same emissions schedule concerning the 21.5mn API issued. The time over which the 21.5mn will be issued will be 24 months, conducted via an S-curve. An S-curve was determined because our community put forth that new technology is often adopted via an S-curve. We want our distribution to align with our adoption. This was the underlying principle behind the entire program.
Thus, the t = 0 starting point (the block number at which the program begins) will likely be different for each side of the marketplace.
For the demand side, t = 0 will be when 5 Dapps are made over 1000 reads or writes (the two will be combined) in a day.
For the supply side, t = 0 will be when 5 distinct APIS Nodes (distinct meaning run by separate actors/entities) with over 10,000 API staked have provisioned at least 1000 reads or writes in a day.
We predict that the demand program will begin before the supply program.
The tools to obtain reads and writes from the APIS network are nearly ready for widespread use. The tools to build to launch a Node or Gateway (supply side) are not yet fully developed, as a highly performant, decentralized back-end is more difficult to achieve. Our test net’s launch will be extremely helpful in accelerating the development time of a decentralized Node and Gateway network.
API tokens will be distributed monthly, with the specific dates to be determined by t = 0.
You can find our complete token distribution schedule here.
Onthe demand side, we develop an accounting standard that can be implemented across Gateways and Nodes (a universal protocol login) — as buyers will purchase reads/writes from multiple Gateways and Nodes. Each transaction will be logged on-chain via a hash and associate Merkle Trie (Merkle Trie hashes are the best solution gas usage minimization), while API Nodes will log the complete Merkle Trie that makes up that hash, thus allowing them to share the same history of the APIS network.
API Nodes will open-source their tallies for the demand side, such that customers can frictionlessly see and/or project their API token earnings. The monthly allocation to each account will be directly proportional to that account’s usage of the APIS protocol (i.e., a Dapp that pays 1% of fees generated that month will earn 1% of that month’s emission). All tokens issued to the demand side will be subject to a one-year lock-up. To mitigate malicious actors, API Gateways and Nodes will monitor user account behavior such that malicious actors will be caught and have their tokens slashed and redistributed between the pool appropriately for the time periods when the fraudulent actions occurred (90%) and to the actors who exposed the fraudulent actor (10%). We cannot ensure that every fraudulent action will be caught. However, due to our community’s experience in the internet industry, we are confident to be able to spot all egregious examples of fraud. All fraudulent cases will be voted on by all API holders, such that the community can be the judge and jury.
On the supply side, a registry of Nodes and Gateways will be maintained on-chain. Each transaction also logs the Node and Gateway associated with that transaction using Merkle Tries. Nodes will open-source their tallies for the supply side in the same way that they do it for the demand side, such that maximal, real-time transparency ensues.
The monthly allocation will be directly proportional to use (i.e., a Node that sells 1% of fees generated that month will earn 1% of that month’s emissions for Nodes). The division of tokens between Nodes and Gateways will be favored towards Nodes, as the decentralization of Nodes is more important than the decentralization of Gateways (to ensure a maximally decentralized network), as Nodes will require significantly more compute and storage resources than Gateways. Nodes can be thought of as our network’s decentralized back-end, while Gateways can be thought of as our network’s decentralized front-end. Thus, Gateways are still immensely valuable due to their role as customer acquirers (acquiring the demand side of the market), and so to write them to 0 would also be irresponsible.
We currently propose a 75–25 monthly split between Nodes and Gateways. All tokens issued to the supply side will be subject to a one-year lock-up. To mitigate malicious actors, API Gateways and Nodes will monitor fellow Gateway and Node behavior such that malicious actors will be caught and have their tokens removed and redistributed to the pool appropriately for the time periods fraudulent. Malicious supply-side actors can have their stakes, in addition to their fraudulently earned tokens, slashed. Like demand side, slashing amounts for fraudulence will be subject to the judge and jury of APIS governance.