GOVERNANCE

Introduction

The Everest protocol is the largest decentralized, public blockchain protocol for the creation and verification of digital, biometric identities & wallets. Using the native access, staking & governance token, ID, the Everest protocol creates and verifies identities + wallets, ranging from proving uniqueness and humanness, to allowing for additional storage (docs), and organizational identities + wallets; and it functions as a general purpose, permissionless blockchain capable of processing transactions and building dApps that use the infrastructure. In part, the Everest protocol leverages a fast, cost-effective blockchain, the EverChain, that is secured by Validators and built with open tools. Users will be able to create and verify identities & wallets, combined with a state-of-the-art blockchain and tokenized value, THE Foundation (TF) catalyzes an expanding ecosystem of decentralized applications, which include health care, insurance, financial services, supply chain, voting, etc.

THE Foundation (TF) is a non-profit organization, governed as a DAO, leveraging the Everest protocol to bring about a more transparent and fair society. TF is currently giving away 15 Billion biometric, digital identities + wallets, each with 0.001 ID token for access to basic access (15M ID tokens) over the coming years.

Summary: THE Foundation (TF) supplies access to the ecosystem by creating identities + digital wallets verifying identities, and facilitating decentralized governance for EverChain that processes transactions for dApps built on top of it, and similar services:

  • a. User identities will be free to individual users, and include biometric, digital identity + wallet + 0.001 ID token for every human on the planet

  • b. Validators will compete for creation, verification, transactions and similar services based on a minimum price of USD, but paid in ID tokens.

  • c. The identity and associated wallet is private by design. No entity or organization, including the TF can unilaterally access a user’s identity store.

  • d. Users can be pseudonymous, and granularly share various credentials. Although anchored in a de-duplicated, unique human identity, users can, for example, show zero-knowledge proofs that they are human, unique or are of age or KYC status, without necessarily giving up their privacy.

  • e. No special hardware is required to create an identity and wallet. Any camera with auto-focus, 2 megapixel and internet connection can create or verify an identity + wallet.

  • f. Governance of pricing, transaction fees & rewards will be per similar proof of stake methodologies such that the network is decentralized and that no active participant controls it.

  • g. There will be 100 validating nodes:

    • i. At the outset, each node is required to stake 400,000 ID tokens.

    • ii. The minimum time for a node to stake is 12 weeks. Un-staking requires a four week un-bonding period. During the un-bonding period, the stake shall remain locked up and the Validators will continue to be able to receive fees for their network services.

    • iii. Future staking amount, rewards, and burning fees will be governed by node Validators after the vote on the initial schema.

    • iv. Fees voted on per governance methods are illustrated below; validating nodes will determine the fees charged, not the issuer of the transaction. A simple transaction over EverChain may be $0.0001 or $0.0002, either of which are paid in ID tokens.

    • v. For identity and wallet creation, as well as transactions on the network, all fees are paid in the native ID token. Each transaction has a fee, which will be paid in part to node Validators, and in part will be burned. The percentages are determined by the node validator governance system after the initial vote of ID holders. This model benefits everyone in the ecosystem as a whole, instead of one set of players.

    • vi. The staked ID tokens by validators do not serve as collateral, and there is no “slashing” or risk of losing one’s stake. Each validator will be identifiable to TF, ensuring protection against a Sybil attack. Staking ID is independent of consensus, and the 100 node Validators will share in the reward on a pro-rata basis based on staked value.

    • vii. Emissions of rewards to staking Validators, minimum pricing for identity creation and verification are determined on a quarterly basis based on community governance outlined below. Rewards are set by the validators (and associated delegators) and can be changed by votes up to a maximum of 1% per voting period

    • viii. Every seven days the “Active Validators”, are chosen from all validator candidates. Up to 100 validators are selected from all validator candidates based on the amount of the ID they have staked. The amount of staked ID is the combination of the Validator’s pledge stake (400,000), and the Delegators’ additional pledges.

TF Background

1.1. Organization. THE Foundation (TF) is a non-profit foundation which was created and endowed for the common good of all humankind. TF is a non-capturable, decentralized network, owned by no one, with a Board of Councillors, functioning into perpetuity and embodying the Principles of Identification for Sustainable Development Goals (SDGs) in software code.

1.2. Purpose. The purpose of TF is to (a) ensure that no person or entity can hack, take control of, or compromise TF or the Private Data of individuals on the Network, (b) oversee the decentralization of the network, thus ensuring security and integrity of transactions and storage, and (c) interface to public bodies for the purpose of paying bills and filing reports. Further, it will adhere to the security, administration and other policies, procedures and protocols articulated herein, as may be amended from time to time by the Board of TF. TF will ensure that data is private by design, and only utilized by the user/owner; the TF Board does not and will not have access to users’ data. Its purpose is to Safeguard the independence, transparency, security & longevity of TF so that it exists for all humanity, forever.

1.3. Mission. Create a society (systems of economic, political, cultural, social) based on transparency, fairness, agency and freedom in which individuals thrive. TF leverages decentralization and cryptography innovations to build the fundamental infrastructure required to usher in the next phase of society’s evolution.

1.4. Principles. We assert that privacy is a human right, and the individual should have control over, and effectively own, their own database of identity elements, including their biometrics; and that a user should have choice over what and with whom they share information. Due to the nature of biometric data and the information being so unique and specific to each person, TF utilizes the highest standards of care, integrity and security to ensure that users do not inadvertently expose their biometric data and that their biometric data is safe from being hacked. The principles guiding the technical and governance design of TF reflect the Principles for Identification for Sustainable Development 2[1] including the following:

1.4.1. Inclusion – Inclusion – TF is built to address the needs of a world with a projected 10+ billion population. As wealth gaps continue to strain market access for those in the global base of the pyramid, TF and its partners leverage the strength of international organizations, non-governmental organizations, governments and foundations to address the needs of the poorest and most vulnerable. The goal is to elevate all of humanity into the global market, thereby providing access to a robust set of services to enhance livelihoods and build resilience equitably. Our principle of inclusion is also reflected and integrated into our policies and governance.

1.4.2. Device independence – if an individual does not possess technology, an agent system will enable them to be enrolled and public access devices used for verification, use and updating. Public Access Devices (PADs) will use an SDK to add identity validation to devices for banking, government services, healthcare, and more. The platform is designed so that any individual, with or without a device can possess digital identity and a wallet with just their biometrics, thus reaching all 7+ billion human beings.

1.4.3. Longevity – TF non-profit foundation is endowed and will be continually funded to exist indefinitely and shall continue to provide identity verification services to its users. The internal governance of TF is constructed to provide clear, standard operating procedures and a mechanism to perpetuate, operate, govern and evolve to be relevant and secure. The system shall be available forever, with the system designed to evolve, be adaptive and bridge to other systems.

1.4.4. Specificity – The key to any economic exchange is knowing the specific individual you are dealing with and with whom you want to transact. To accomplish this, multiple types of biometric information for each identity are recorded and stored. Legacy identity documents, including national ID cards, driver’s licenses, passports, voter ID cards, etc. are captured, as are 3rd party attestations by cryptographically signing those affirmations of claims.

1.4.5. Security – All identity information is stored in TF. The system stores the individual’s information in a proprietary encrypted datagram. That datagram is then stored on a decentralized, encrypted, user-controlled storage array, and behind sets of challenge-response locks. The system is resilient against attack.

1.4.6. Rights of Individuals – TF is an organization that has the following unanimous, unchanging beliefs and principles about a person’s identity information:

1.4.6.1. All individuals should be included

1.4.6.2. If an individual does not have access to technology, they should still be able to participate

1.4.6.3. All individuals should be specifically identifiable

1.4.6.4. All information about an individual should be stored in the most secure manner possible

1.4.6.5. The individual should possess and control their identity, if they are able

1.4.6.6. The individual should be able to selectively share their identity information per interaction

1.4.6.7. The individual’s information should not be owned or controlled by any party other than the user

1.4.6.8. Individuals should be informed and compensated for access to their identity information and enabled to selectively share data with another party or deny access.

1.4.7. Network Principles – The following principles apply to the network:

1.4.7.1. No one owns the Network

1.4.7.2. No one can shut down the Network

1.4.7.3. Node Validators can secure network transactions, but cannot view, access or copy ANY personally identifiable information.

1.5. The verification network can scale to provide billions of users’ access to (i) secure, private digital identities, (ii) wallets for crypto, (iii) account for document storage and credentials, and (iv) secure and reliable transactions.

TF has Board Councillors drawn from internationally and regionally recognized international organizations, NGOs, IGOs and philanthropic organizations in existence for at least 10 years with principles aligned with the Principles of Identity for SDG. No one will have access to user data, nor possess sufficient keys to open the network. In the event of recourse (i.e. a user needs to re-enroll, or network breach), the Key-holders will bring together sufficient key holders to handle such issues.

ID Token

ID is the native access, staking, and governance token recognized by the Everest protocol. Varying amounts of ID held in an EverWallet grant access to different levels of access, functionality and time. The ID is also used to pay for various services in the network. Those who possess ID tokens in their EverWallet are “ID Holders.” Those who possess sufficient ID tokens in their EverWallet to qualify, can pledge their holdings to a Validator for a pro-rata amount of the rewards and become “Delegators.” Those who possess sufficient ID Tokens and contribute to the network by operating a network node are “Validators.”

Transaction fees are added on to each transaction to avoid spamming. Initially based on a community vote of minimum thresholds, Validators set network prices and reject transactions that have implied fees priced below this threshold. At the end of every month, the fees are (a) disbursed to the participating Validators pro-rata to stake, and (b) burned per the governance set by the network.

The primary functions of the ID are to provide access to the network, and protect the integrity of Everest ecosystem – in providing network security, node Validators and Delegators are exposed to the risks of maintaining a long-term position on a fluctuating asset. Staking Rewards therefore provide the incentive to maintain long-term ID ownership.

Staking Rewards are distributed to Validators who take a commission for providing the computer infrastructure, and then distributed to their Delegators. Delegators can delegate to a multiple Validators at the same time.

Rewards from stakes are determined largely by the relative size of each stake, and are structured in such a way that rewards increase as transaction volume increases.

Pricing for services is initially determined by a vote of ID holders with over 1,000 IDs in their EverWallet (one EverWallet = one identity, which equals one vote), and then on an on-going basis by Validators according to the governance system. Fees are priced in USD, but paid in ID. Pricing will be updated quarterly (four times per year) to match market prices, and will be determined by the governance processes. TF will offer the below services.

User Identity + Wallet (creation)
ID Verification (human & unique)
EverChain transactions
Validators

Based initially on a community vote, a percentage of transaction fees will be allocated to Validators, a percentage of the transaction will be burned, and 10 percent will be allocated to THE Foundation for the purpose of maintaining storage and access for identities.

Validators

Any amount of ID allows a holder to be a Delegator. Once a holder has pledged their holdings by Staking them while identifying their chosen Validator they will then participate and earn rewards distributed by the Validator to their Delegators. Validators are network participants that, in addition to running a full EverChain node, listen to transactions broadcasted in the network’s mempool and include them in blocks that they sign. For more details on Validators, refer to the EverChain Validator FAQ and EverChain Validator registration request form. In order to do so and reliably to meet the scalability, security, and finality requirements of the network, Validators typically run specially configured architectures that are robust against many forms of attacks on distributed networks or leverage service organizations which provide equivalent hardware as commodity cloud infrastructure to host their node. No validator will be able to vote more than 10% of the network power, and validators are prohibited from colluding. The policies described here can change, as determined by the TF board. Validators play a central role in the EverChain’s consensus, which is modeled after Ethereum and BSC. For more detailed information on the validator’s role, please refer to the official documentation.

ID holders who do not have sufficient ID to stake their tokens as a Validator, can delegate their IDs to a Validator. This allows normal ID holders who don’t want to set up a validator node to participate in staking rewards. A Validator must have at least 400,000 ID to stake for their node, however, Delegators may choose a Validator who will steward their ID Tokens, increasing the total amount of the ID Token on that Validator Node.

A validator’s voting power is proportional to the amount of ID they have put into a Vault, from all delegations (including their self-delegation). Only the top 100 Validators in voting power (with associated amount of ID) comprise the validating set. Delegators play a vital role in this ecosystem because they determine which Validators receive the designation of candidate, by voting to delegate their ID.

Running a validator is a big responsibility, which is why only the top 100 in Vaulted ID stake are the candidates to sign blocks. Validators and Delegators earn rewards based on the minimum time they commit to a staking Vault. Each of the 100 Vaults equates to running one of the validating nodes.

User Identity + Wallet (creation)
 
Org Identity + Wallet + API per year (creation)
2-10 users
11-100 users ($3.00/user/year)
101-250 ($2.50/user/year)
251-500 ($2.25/user/year)
501+ users = custom
Additional TIME
Additional STORAGE
ID Verification (human & unique)
EverChain transactions
Stakers/Validators

The 21 Validators who sign blocks are randomly chosen every 24 hours from the pool of 100 Validators. Those Validator nodes not online for the entirety of the previous hour prior to the cutover will not be eligible to be chosen for the 21 signers. Additional detail can be found in the Validator FAQ.

Every seven days up to 100 “Active Validators” are chosen from all validator candidates based on the total amount of the ID they have staked on their node. The amount of staked ID is the combination of the Validator’s pledge stake (400,000), and the Delegators’ additional pledges.

The selection of the 100 Active Validator nodes includes the following requirements for uptime and availability: a validator candidate will not be eligible if their node is:

  • offline for any 24 hour period in the 7 days preceding the selection day
  • fails to sign a designated block
  • drops any transaction when a signer

The list of the “Active Validators”starts sequentially ordered by the amount of ID the validator has staked. That list is then randomly reordered, and the 21 signers chosen as the first 21 entries in the randomly reordered list. Those “Active Validators” who are not chosen to be signers are the hot-spares for the 21 signers and are expected to swap in for a signers who goes offline in the order they were randomly sorted in (e.g. #22 would be the first alternate).

The minimum number of validator nodes to operate the network are 21, all additional nodes are hot spares, available for traffic if needed. The 21 signers are chosen from the rank-ordered list of those validator candidates who have the most ID staked every 24 hours; that rank-ordered list is refreshed every 7 days. For Delegators, staking ID can be a rewarding activity. However, as explained above, it should not be treated as a passive activity – Delegators should apply due diligence and have confidence in the Validator.

Validators get to make proposals to the collective organization, and can by default represent Delegators. The method of submitting proposals will be through a website, and the voting will take into consideration the relative stake of each entity. The greater the stake, the more voting power is attained. The governable TF Proposals (TFPs) will include (a) pricing of basic services, (b) reward percentage and (c) burning percentage.

The cycle of Proposals is quarterly, meaning that at the beginning of every calendar quarter there will be a new set of proposals to consider. Proposals that are not advanced during the quarter are discarded. Any Validator can re-propose a Proposal and get it seconded again to get another attempt to be chosen. Proposals may be created and queued from the 15th of the previous month to the beginning of the quarter. There are no limitations on the number or length of the proposal, however, proposals which do not include an EverID profile for the proposing Validator will not be considered.

CRDT Token

CRDT is the programmable, licensed, regulatory-approved stablecoin that is backed 1:1 by any fiat deposit. Use of the CRDT by TF is authorized by way of an agreement with Everest Network, Ltd. It is the lingua franca, currency, of the ecosystem that opens up fiat-on/off ramps, cross-border remittances, payments, and opens the ecosystem to regulated financial services.

Governance

Verifiable and persistent identity is the foundation of all economic systems. Industrialized societies built robust, functional identity verification platforms, and thus have access to lower cost capital (due to lower perceived risk), which promotes capital concentration, creating a self-fulfilling system of the poor staying relatively poorer. The industrialized societies have been, until now, unable to accept risk at the same rates in emerging societies. The lack of that identity is a major impediment to service access by the poor and those unable to directly participate in the global digital economy.

With the advent of the THE Foundation, that paradigm changes, bringing those communities without access to trustworthy legal identity into the 21st century digital economy. This is done by providing the people of these communities with digital identities, digital wallets, and document management stored on their own database-accessible and controllable by that individual along with the education and training to properly gain adoption.

By incorporating biometrics, (and through partnerships) existing government IDs and 3rd party attestations that are housed in this distributed, user-owned datastore, TF extends digital identity, digital wallets and document storage to populations that do not own a personal device; although enrollment requires a smartphone, usage & ownership of this user-centric identity + wallet + documents only requires biometrics (i.e. face) and a PIN. With the proverbial shirt on one’s back, one is able to be verified, access one’s wallet, manage one’s documents and engage in global value exchange in the 21st century economy.

Individuals who own mobile phones will be able to expand their digital identity with additional sources of data and leverage it in more flexible ways. A user-centric, biometrically verifiable identity solves the problems that have plagued the 3+ billion people living in poverty.

By empowering individuals with the tools to protect and manage their own identity data, and importantly allows them to profit from institutions that wish to access data or verify their identity. For example, governments, banks, hospitals, utilities and other large institutions (“Network Customers”) need to verify identities to do such things as open a bank account, provide a mobile phone and SIM card, give and track a vaccine, get a SIM card, and receive food.

Purpose, Mission and Principles

TF is a non-profit organization that leverages concepts from decentralized autonomous organizations (DAOs) to ensure that no centralized entity or person can access a user’s identity or account, thus ensuring that a global identity creation and verification network is secure and available in perpetuity. The DAO is organized to be self-funding based on the transactions processed over EverChain. That is, a percentage of the fees will be used to pay for the storage, bandwidth, and infrastructure to house identities and accounts in distributed storage around the planet. The architecture, intellectual property and infrastructure was initially developed by Everest, which also supplies ongoing support and maintenance. Since “identity” requires recourse (i.e. in case of a catastrophic hack or a user’s loss of facial or other biometrics), multiple, different keyholders can come together to fix such issues or release software that could jeopardize the security of the DAO. The TF’s keyholders are drawn from internationally and regionally recognized international organizations, NGOs, IGOs and philanthropic organizations who are aligned with the Principles of Identity for SDG; additionally, Everest holds two keys. Critical to this governance is that not a single entity, including the TF, Everest or any other organization, can open, change or alter any part of a user’s identity or account. As such, users are guaranteed (via code, not law) that their identities are private, secure, and lasting forever. Similarly, the EverChain network is governed by Validators, which, in addition to processing transactions across a permissionless network, vote on pricing of basic services, transaction burn percentage, and validator rewards, among other potential initiatives.

Jamal Khokhar

Jamal Khokhar

Jamal Khokhar has been Canada’s Ambassador to Turkey since November 2019. He also is accredited to Georgia, Azerbaijan and Turkmenistan. In January 2021, he was concurrently appointed as Canada’s Special Envoy to the Organization of Islamic Cooperation (OIC).

From 2015-2019, while on-leave from Government, he was President & CEO of the Institute of the Americas. Located on the campus of UC San Diego, the Institute advanced energy and sustainability, as well as innovation and entrepreneurship across the Americas.

From 2010-2015, he served Canada’s Ambassador to Brazil with oversight of the Embassy in Brasilia, Consulates General in Sao Paulo and Rio de Janeiro, and three regional trade offices.

Other appointments included being the Director General for Latin America and the Caribbean at Canada’s Department of Foreign Affairs and International Trade. In this capacity, he was responsible for overseeing Canada’s bilateral relationships in the region and was instrumental in leading the development of the Canada’s ‘Americas Strategy’.

Later, he was the Regional Director General for Latin America and the Caribbean at the Canadian International Development Agency (CIDA). His bureau was responsible for redefining Canada’s bilateral development assistance programming in the Americas, bringing focus to core countries of concentration and under the ‘aid-effectiveness’ agenda. As part of that portfolio, he also had oversight for what was then Canada’s second largest bilateral development assistance program — CIDA’s bilateral programming in Haiti, at the time of the 2010 earthquake.

From 2006-2008, on-leave from Government, he was served as Chief of Staff to the President of the Inter-American Development Bank (IDB) in Washington, D.C., where he supported the President in the Bank’s transformation and renewal agenda. As part of his responsibilities, he focussed on renewing institutional governance and the leadership agenda.

Also at the IDB, he led the creation of the Bank’s new Department of Outreach and Partnerships and served as its first Executive Director. That department continues to be dedicated to establishing innovative high impact and social entrepreneurship partnerships with the private sector, NGOs, and private foundations.

Amongst other key foreign assignments, he served five years at Canada’s Embassy to the United States, first as Deputy Head of the Economic and Trade Policy Section, then as Minister-Counsellor and Head of the Congressional and Legal Affairs Section. At Headquarters, Mr. Khokhar was the Executive Assistant to two Deputy Minister’s for International Trade.

He has studied at McGill University in Montreal, the University of Ottawa, and the American University in Washington D.C.

In 2002-2003, he was a Fellow at Harvard University’s Weatherhead Center for International Affairs where he studied post-9/11 issues of religion, justice and peace in foreign policy.

Mr. Khokhar is a recipient of the Queen’s Diamond Jubilee Medal for leadership and excellence in the development and implementation of Canada’s ‘America’s Strategy.

Ramsay Taum

Ramsay Taum

Recognized locally, nationally, and internationally for his work in promoting peace, forgiveness and the spirit of ALOHA, Ramsay Taum is a sought after mediator, facilitator, and transformational “revealer” dedicated to promoting peaceful, sustainable communities across Island Earth. Mentored and trained by respected kupuna, Hawaiian and Polynesian wisdom keepers and holders, Ramsay works with individuals, associations, businesses, corporations, and governmental bodies aspiring to align their operating cultures and practices with traditional, ecological knowledge, place-based values and principles rooted in natural and spiritual intelligence that are more compatible with the base operating system and culture of Island Earth.

Ramsay is the founder and president of the Life Enhancement Institute (LEI) of the Pacific, LLC. He is a graduate of the Kamehameha Schools, attended the United States Air Force Academy at Colorado Springs and earned a Bachelor of Science degree in Public Administration from the University of Southern California.

As a cultural practictioner he leads Ho’oponopono courses and is a well respected lua expert and kumu (Hawaiian martial artist).

Jordan Hall

Jordan Hall

Jordan Hall is an entrepreneur and angel investor with a focus on the internet and digital media space. Having received his law degree from Harvard and practicing for all of 93 days, he sought greener pastures, becoming an advocate for “efficient, collaborative, open” models of information dispersal.

He Co-founded DivX, Inc. (Formerly, DivXNetworks, Inc.), the digital media giant, in 2000 and served as its Chief Executive Officer & Executive Chairman through 2007. Previously, he served as Vice President of MP3.com, where he was responsible for developing and implementing MP3.com, business and content development model.

Jordan was on the Board of Trustees for the Santa Fe Institute and is involved with numerous other institutions and boards.

The Policies aim to:

  • Provide impartiality and avoid preferential treatment to specific groups and communities;
  • Provide voting in alignment with TF’s mission and vision to ensure inclusivity, and access to financial services for the world’s population
  • Establish a safe, secure and dependable set of Validators to ensure the safety and stability of the network
  • Provide an equitable process through which new users, groups and communities can establish Validators.
  • Create a governance system that empowers the community, and not TF or Everest Network, Ltd., to drive the path forward for the growth and management of its ecosystem
  • Governable items include, for example, pricing for basic services, network fees, validator rewards, burning amounts. Additional items may include such items as grant proposals or targeting a specific vertical or geography may be subject to voting on a case-by-case basis.

Governance is the process by which TF participants and node Validators can effect change for the ecosystem, by collectively supplying input to TF Proposals (TFPs) and securing the network by running independent nodes of EverChain. The ecosystem is governed by ID token holders and Validators who stake their ID tokens and submit votes via off-chain proposals that govern the ecosystem. The network utilizes the ID token on EverChain to function without the active participation of TF or Everest Network, Ltd. TF published a proposed set of schemas to determine pricing of basic services, and how node Validators will receive rewards in the future. Once the schema is determined by the community of users, Validators will be empowered to process transactions, vote on pricing. All successful proposals signify the approval of the community and must be accepted by the Validators. Validators have the ability to leave or not validate should they wish.

Governance generally, and proposals specifically, will fall within the roadmap established by TF with community input. Pricing of basic services, validator rewards, transaction fee burning percentages, and similar parameters will be voted upon by Validators (and by extension, Delegators) four times per year. Additionally, larger directional changes may be voted on as well. The policy described here can change at any time as determined by the TF Board.

The initial vote can be taken here.

Iterative Proposals in TF

TFP stands for THE Foundation Proposal. A TFP is a design document gathering information sourced from the Everest community, which describes a new feature, or a change to the platform’s processes or operating environment of the EverChain. The TFP must include a precise technical specification of the feature as well as the reason and use-case for the feature. The TFP author or team is responsible for building consensus within the community, documenting dissenting opinions, and submitting the TFP to the monthly proposal queue.

We intend TFPs to be the primary mechanism for community input, and for documenting the decisions that drove EverChain’s evolution. Because TFPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal of EverChain. For EverChain implementers, TFPs are a convenient way to track the progress of the evolution of the platform. Ideally each implementation maintainer would list the TFPs that they have implemented into their project.

It is highly recommended that a single TFP contain a single key proposal or new idea. The more focused the TFP, the more successful it tends to be. A change to one client doesn’t require a TFP; a change that affects multiple clients, or defines a standard for multiple apps to use, does.

A TFP must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly.

Before you begin writing a formal TFP, one should vet the idea. Ask the community first if an idea is original to avoid wasting time on something that will be rejected based on prior research. It is thus recommended to open a discussion thread on the forum to discuss this, and not to forget to review this repository and its history of transactions.

Once the idea has been vetted, one’s next responsibility will be to present (by means of a TFP) the idea to the reviewers and all interested parties, invite editors, developers, and the community to give feedback on the aforementioned channels. Negative community feedback will be taken into consideration and may prevent the TFP from moving past the Draft stage.

Proposals types include:

  • ParameterChangeProposal: a change to blockchain, functional or operational parameters
  • StakingParameterChangeProposal: a change to validation, pricing, and staking parameters
  • TextProposal: All other issues such as large directional changes or decisions requiring manual implementation or intervention can also be voted on by submitting a TextProposal

The following is the standardization process for all TFPs:

1. IDEA – An idea that is pre-draft. This is not tracked within the TFP Repository.

2. DRAFT – The first formally tracked stage of an TFP in development. A TFP is merged into the TFP repository only when it is properly formatted and submitted by a TFP Author.

3. REVIEW – A TFP Author marks a TFP as ready for and requesting Peer Review by issuing a pull request.

4. LAST CALL – This is the final review window for a TFP before moving to FINAL. A TFP editor will assign Last Call status and set a review end date (review-period-end), typically 14 days later.

If this period results in necessary normative changes it will revert the TFP to REVIEW.

5. FINAL – This TFP represents the final standard. A Final TFP exists in a state of finality and should only be updated to correct errata and add non-normative clarifications.

STAGNANT – Any TFP in DRAFT or REVIEW if inactive for a period of 6 months or greater is moved to STAGNANT. A TFP may be resurrected from this state by Authors or TFP Editors through moving it back to DRAFT. TFP Authors are notified of any algorithmic change to the status of their TFP

WITHDRAWN – The TFP Author(s) have withdrawn the proposed TFP. This state has finality and can no longer be resurrected using this TFP number. If the idea is pursued at a later date it is considered a new proposal.

LIVING – A special status for TFPs that are designed to be continually updated and not reach a state of finality. This includes most notably EIP-1.

Each TFP should have the following parts:

Preamble – RFC 822 style headers containing metadata about the TFP, including the TFP number, a short descriptive title (limited to a maximum of 44 characters), a description (limited to a maximum of 140 characters), and the author details. Irrespective of the category, the title and description should not include TFP number. See below for details.

Abstract – Abstract is a multi-sentence (short paragraph) technical summary. This should be a very terse and human-readable version of the specification section. Someone should be able to read only the abstract to get the gist of what this specification does.

Motivation (*optional) – A motivation section is critical for TFPs that want to change the parameter set. It should clearly explain why the existing parameters are inadequately addressing the needs of the Validators.

Specification – The technical specification should describe the syntax and semantics of any new feature.

Rationale – The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.

Backwards Compatibility – All TFPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The TFP must explain how the author proposes to deal with these incompatibilities. TFP submissions without a sufficient backwards compatibility treatise may be rejected outright.

Test Cases – Test cases for an implementation are mandatory for TFPs that are affecting consensus changes. Tests should either be inlined in the TFP as data (such as input/expected output pairs, or included in ../assets/eip-###/filename.

Reference Implementation – An optional section that contains a reference/example implementation that people can use to assist in understanding or implementing this specification.

Security Considerations – All TFPs must contain a section that discusses the security implications/considerations relevant to the proposed change. Include information that might be important for security discussions, surface risks and can be used throughout the life-cycle of the proposal. E.g. include security-relevant design decisions, concerns, important discussions, implementation-specific guidance and pitfalls, an outline of threats and risks and how they are being addressed. TFP submissions missing the “Security Considerations” section will be rejected. A TFP cannot proceed to status “Final” without a Security Considerations discussion deemed sufficient by the reviewers.

Copyright Waiver – All TFPs must be in the public domain. See the bottom of this TFP for an example copyright waiver.

TF Initial Vote

SynopsisProposal to define schema of EverChain
StatusFINAL
TypeStakingParameterChangeProposal
Created2021-11-30

The community (initially, those with over 1,000 ID tokens in their EverWallet) will vote on option A or B below: pricing for basic services in USD and paid in ID tokens, the subsequent percentage that will be allocated to Validators, and the percentage of the transaction to be burned. Each identity/wallet in the initial vote will be able to vote once, and the amount of ID tokens above 1,000 is irrelevant to the weight of the vote. Validators will vote starting in Q1, 2022.

TF has a partnership to allow those users and organizations with identities and wallets issued by TF to access regulated financial services vis a vie Everest Network, such as the following:

  • eKYC/AML
  • Credential sharing
  • Use of the CRDT, the licensed, programmable stablecoin
  • Payments
  • International remittances
  • Buy, sell, trade crypto
  • Lend/borrow
  • SDK
  • Fast API
  • Reporting
  • Minting & issuing NFTs
  • Minting & issuing tokens to run on EverChain

Such a model would look like the below, with the following assumptions: $1/ID; sample users. The PINK in the below would be drawing off of 75 million tokens in the Access Regulated Financial Services pool.

    Fees charged in USD Purchaser spends ID tokens Transaction fee Burned # of IDs rewarded to Validators
ID Verification (human & unique) 1,000,000 $0.20 400,000 200,000 40,000
Credential sharing 10,000 $0.50 10,000 5,000 1,000
eKYC/AML 1 $1.50 3.00 1.50 0.30
Org programming of CRDTs 10 $25,000 500,000 250,000 50,000
Org Fast API + reporting 10 $50,000 1,000,000 500,000 100,000
Minting & Issuing NFTs or ERC20s 2 $250,000 1,000,000 500,000 100,000
SDK with support & maintenance 1 $500,000 1,000,000 500,000 100,000
Payments: none, gold, silver, platinum 50,000 1.0% 5,000,000 2,500,000 500,000
International: none, gold, silver, platinum 50,000 1.5% 7,500,000 3,750,000 750,000
Buy, Sell, Swap (mainnet LPs) crypto: none, gold, silver, platinum 50,000 0.10% 500,000 250,000 50,000
Earning 50,000 0.10% 500,000 250,000 50,000
Borrowing 50,000 0.10% 500,000 250,000 50,000
Buy, sell, trade on EverChain 50,000 0.15% 750,000 375,000 75,000
2-10 users ($4.00/user/year) 1 $40 80 40 8
11-100 users ($3.00/user/year) 100 $300 60,000 30,000 6,000
w/ 101-250 ($2.50/user/year) 250 $625 312,500 156,250 31,250
w/ 251-500 ($2.25/user/year) 500 $1,125 1,125,000 562,500 112,500
501+ users = custom 1 $250,000 500,000 250,000 50,000
Additional TIME (custom; i.e. per year) 3 $10,000 60,000 30,000 6,000
Additional STORAGE (custom; i.e. per MB) 100,000 $1 200,000 100,000 20,000
Total     18,660,003 9,330,002 1,866,000
Allocations Existing
Circulating supply 116.7
Staking & Rewards 183.3
Community 100
Team 125
Strategic Partners, Advisors, Consultants 150
Ecosystem Development 125
Total 800

TF will retain 10 percent of the fees for the purpose of paying for the ongoing storage and access to identities. Validators are required to stake 400,000 ID tokens, and will be remunerated on a pro rata basis based on the amount of time the stake is “vaulted” per the below:

Reward =Percentage Minimum amount of ID Days/tiers
5% 400,000 90
12% 400,000 180
32% 400,000 365
  • Pricing of basic services:
Foundation: Create + Verify + ChainUsers 
User Identity + Wallet (creation)15,000,000,000FREE
 Sample # of UsersMinimum Fees charged in USD
EverChain TXN10,500,000$0.0001
ID Verification (human & unique)10,000,000$0.15
Stakers/Validators100$200,000
  • Validators: 10%
  • Transaction fee burned: 50%

A scenario with the above pricing and percentages would look like the below with the following assumptions: $1/ID; sample # of users.

Foundation: Create + Verify + ChainUsers# of IDs Reqd.total   
User Identity + Wallet (creation)15,000,000,0000.001015,000,000 APY or % of TXNs, whichever is higher 
 Sample # of UsersMinimum Fees charged in USDSpent IDs# of IDs burned for Transaction# of IDs rewarded to Validators# of IDs allocated to EF
EverChain TXN10,500,000$0.00012,1001,050210210
ID Verification (human & unique)10,000,000$0.153,000,0001,500,000300,000300,000
Stakers/Validators100$200,00020,000,000 2,000,000 
   23,002,1001,501,0502,300,210300,210
  • Pricing of basic services:
Foundation: Create + Verify + ChainUsers 
User Identity + Wallet (creation)15,000,000,000FREE
 Sample #Minimum Fees charged in USD
EverChain TXN10,500,000$0.0002
ID Verification (human & unique)1,000,000$0.20
Stakers/Validators100$200,000
  • Validators: 5%
  • Transaction fee burned: 60%

A scenario with the above pricing and percentages would look like the below with the following assumptions: $1/ID; sample # of users.

Foundation: Create + Verify + ChainUsers# of IDs Reqd.total   
User Identity + Wallet (creation)15,000,000,0000.001015,000,000 APY or % of TXNs, whichever is higher 
 Sample # of UsersMinimum Fees charged in USDSpent IDs# of IDs burned for Transaction# of IDs rewarded to Validators# of IDs allocated to EF
EverChain TXN10,500,000$0.00024,2002,520210420
ID Verification (human & unique)1,000,000$0.20400,000240,00020,00040,000
Stakers/Validators100$200,00020,000,000 1,000,000 
   20,404,200242,5201,020,21040,420
  • Pricing of basic services:

    Foundation: Create + Verify + ChainUsers 
    User Identity + Wallet (creation)15,000,000,000FREE
     Sample # of UsersMinimum Fees charged in USD
    EverChain TXN10,500,000$0.00001
    ID Verification (human & unique)10,000,000$0.01
    Stakers/Validators100$200,000
  • Validators: 0%

  • Transaction fee burned: 0%

A scenario with the above pricing and percentages would look like the below with the following assumptions: $1/ID; sample # of users.

Foundation: Create + Verify + ChainUsers# of IDs Reqd.total   
User Identity + Wallet (creation)15,000,000,0000.001015,000,000 APY or % of TXNs, whichever is higher 
 Sample # of UsersMinimum Fees charged in USDSpent IDs# of IDs burned for Transaction# of IDs rewarded to Validators# of IDs allocated to TF
EverChain TXN10,500,000$0.000011050011
ID Verification (human & unique)1$0.010.010.000.000.00
Stakers/Validators100$400,00040,000,000 0 
   40,000,1050011

Validator FAQ

IndexQuestionAnswer
1Staking NetworkEverChain (EC)
2Staking TokenID
3Validator – Staking Parameters Max Validator Count Validator Stake & Rewards Delegator Redelegate frequencyMainnet 21 active signers, up to 100 validators Testnet 11 signers, up to 100 validators Mainnet Minimum Self-delegate Amount: 400,000ID Reward Frequency: weekly at 0:00 UTC Sunday Unstaking Period: 4 weeks un-bonding Testnet Minimum Self-delegate Amount: 1,000ID on testnet. Reward frequency: every 3 hours Unstaking Period: 7 hours un-bonding Mainnet 7 days Testnet 4 hours
4Validator – What does a validator node do?It powers the blockchain network by processing transactions and signing blocks.
5Validator – What are the incentives to run a validator node?Validators and delegators earn rewards from transaction fees driven by network usage
6Validator – What’s an Identity Network Proposal?Proposals will decide: pricing in ID tokens, fees charged, validator allocation, and burning allocation.
7Validator – How to join as a validator?Mainnet: Choose your server/PC & Install software Create an EverWallet and get some ID Run your fullnode and keep it synced Stake your ID, submit your address to the Validator Node Registration form, the top 21 most staked nodes will be chosen as signers. Testnet: Choose your server/PC & Install software Create an EverWallet and get some ID Run your fullnode and keep it synced Stake your ID, the top 11 most staked nodes will be chosen as signers.
8Validator – What are hardware requirements of running a validator node?Processing transactions is mostly CPU bound. Therefore we recommend running CPU optimized servers. Directly facing internet (public IP, no NAT) 8 cores CPU 16GB of RAM 500 SSD storage
9Validator – How many ID are required to create a validator?400,000ID Validators can self-delegate, meaning they can delegate ID to themselves, and they can also receive delegations from other holders or the Validator Pool.
10Validator – When are rewards paid out?The rewards will not be sent to validator right away, instead, they will be distributed and accumulated on a contract. The reward distribution happen weekly Sunday at 00:00 GMT.
11Validator – Does an inactive validator receive any rewards?No, they will not.
12Validator – What is ‘self-delegation’? How can I increase my ‘self-delegation’?Self-delegation is delegation from a validator to themselves. This amount can be increased by creating an additional stake in the validator’s operator address.
13Validator – How are the 21 Signers selected from the Validator nodes?The 21 Validators who sign blocks are randomly chosen every 24 hours from the pool of 100 Validators. Those Validator nodes not online for the entirety of the previous hour prior to the cutover will not be eligible to be chosen for the 21 signers.Every 24 hours the validator pool will randomly select from the 100 validator nodes and choose 21 active validators. Every seven days the validator pool will be selected as the top 100 validator candidates based on the amount of ID staked.
14Validator – How do I Register as a Validator candidate with the TF?Mainnet https://forms.gle/xjwPcSyumkwVsKUM8
Testnet https://forms.gle/b5QvKgdYcA28frRu6
14Validator & Delegator – Can I receive my staking rewards if my chosen validator is inactive?No, you cannot.
15Validator & Delegator – When can I receive my unstaked ID?After you sent undelegate transaction, you have to wait 4 weeks. This period starts at UTC 00:00 the day after your undelegate transaction.
16Delegator – What’s the role of a Delegator on EverChain?A delegator can delegate its ID to a chosen Validator or the Validator Pool to participate in the consensus of the network, help secure the network, and earn rewards for that work.
17Delegator – How to delegate my ID?Please download and use the EverWallet from Everest available here: https://wallet.everest.org
18Delegator – How to undelegate my ID?Delegates and validators themselves may choose to Unstake their ID for a variety of reasons. It is important to note that these ID are subject to what is known as the Unstaking Time, an on-chain parameterized period of time upon which all delegates, including validators, must wait for their ID to become fully Unstaked. In addition, these ID are still subject to be potentially slashed upon commitment of any byzantine behavior. The UnstakingTime ensures a variety of security measures in the network, such as accounting for network synchronization, limiting the duration of certain types of attacks, and solving the “nothing-at-stake” problem.
19Delegator – EC UnstakingTimeMainnet 4 weeks Testnet 7 hours
20Delegator – How do I redelegate my ID?Redelegations between a unique Delegator, Validator or Validator Pool can only happen once every UnstakingTime
21Delegator – How many tokens are required to stake on EverChain to be a delegator?Any amount of ID
22Delegator – How to claim my rewards?The rewards will be distributed to every delegators from the ecvalidator smart contract every week.
23Delegator – When can I receive my staking rewards?Since validatorset info is updated every week at UTC 00:00 Sunday, to make some room for the error handling, we distribute the fees of week W-1 in the next block (week N+1). Thus, after you sent delegate transaction, you will receive your first staking rewards the second Sunday at UTC 00:00. Afterwards, you will receive your rewards every week at UTC 00:00 Sunday.
24Delegator – When can I receive my undelegated ID?Since Unstaking Period is 4 weeks. Thus, after you sent undelegate transaction, your staked ID will not receive any rewards until the next UTC 00:00. After 31 days start from the next UTC 00:00, you will receive your ID.
25Delegator – Can a validator run away with their delegators’ ID?By delegating to a validator, a user delegates voting power. This does not mean that the validator has custody of their delegators’ ID. By no means can a validator run away with its delegator’s funds.
Scroll to Top