├── TIPs-Template.md ├── tip-0021.md ├── tip-0022.md ├── tip-0031.md ├── tip-0026.md ├── tip-0019.md ├── tip-0015.md ├── tip-0017.md ├── tip-0029.md ├── tip-0032.md ├── ArbMinReq.md ├── DataProtectionPolicy.md ├── tip-0014.md ├── tip-0012.md ├── tip-0010.md ├── tip-0024.md ├── tip-0018.md ├── tip-0009.md ├── tip-0007.md ├── tip-0033.md ├── tip-0011.md ├── tip-0002.md ├── tip-0025.md ├── tip-0028.md ├── tip-0013.md ├── README.md ├── tip-0030.md ├── tip-0008.md ├── tip-0023.md ├── tip-0005.md ├── tip-0016.md ├── tip-0027.md ├── tip-0034.md ├── Regarb.md ├── BPMinReq.md ├── tip-0003.md ├── tip-0004.md ├── tip-0001.md ├── regproducer_human_language_contract.md ├── Regproducer.md └── TelosOperatingAgreement.md /TIPs-Template.md: -------------------------------------------------------------------------------- 1 | 2 | Title: 3 | Authors: 4 | Status: [ Draft | Accepted | Installed | Withdrawn | Deferred | Rejected | Superseded ] 5 | Type: [ Informational | Protocol ] 6 | Created: 7 | Discussion: 8 | Replaces: (optional) 9 | Superseded-By: (optional) 10 | Worker: (optional) 11 | 12 | # Abstract 13 | # Motivation 14 | # Rational 15 | # Specifications 16 | # Discussion 17 | # Summary for Token Holders 18 | # Copyright 19 | # See Also 20 | -------------------------------------------------------------------------------- /tip-0021.md: -------------------------------------------------------------------------------- 1 | Tip: 0021 2 | Title: APB Commission 3 | Authors: Jerry Huff - BlindBlocArt 4 | Status: withdrawn 5 | Type: Informational 6 | Created: 2018-10-15 7 | 8 | 9 | # Abstract 10 | 11 | There should be a commission for the important team called the APB who will launch this network 12 | 13 | # Motivation 14 | 15 | This is a hard working group that without we would have no network, I feel this is mearly a commission that has been 16 | overlooked. 17 | 18 | # Rational 19 | 20 | There should be an incentive to become part of the APB team, as this is taking away vital BP prep time. 21 | 22 | # Specifications 23 | 24 | The proposed schedule from the Bounty System call was for the APB director team (4 teams) as reccommended by all the WG 25 | chairs to receive a commission of 1500 slices and the members of the APB group to get a commission of 3500 slices. 26 | That means the 4 director teams would get a total of 5000 slices, and the other members would get 3500 slices. 27 | 28 | # Discussion 29 | 30 | (Open for discussion) 31 | 32 | # Copyright 33 | 34 | This document is in the public domain 35 | -------------------------------------------------------------------------------- /tip-0022.md: -------------------------------------------------------------------------------- 1 | TIP: 0022 2 | Title: Initial RAM buy 3 | Authors: J.T Buice - KainosBP, Jesse - CalEOS, Jerry Huff - BlindBlocArt 4 | Status: Adopted 5 | Type: Informational 6 | Created: 2018-10-15 7 | 8 | 9 | 10 | # Abstract 11 | 12 | We need TLOS to buy ram for initial account creation for genesis load 13 | 14 | # Motivation 15 | 16 | There is a cost to create accounts that has to be accounted for and transferred to the eosio account. 17 | 18 | # Rational 19 | 20 | Account creation is not free and the TLOS needed needs to be accounted for. In the launch practice we use almost 20000 to create 21 | the genesis account, and stil have to create the community rewards accounts and the Telos Foundation Launch group accounts. 22 | 23 | # Specifications 24 | 25 | 25000 TLOS to be added to the eosio account for all account creation and any leftover funds to be transferred to 26 | eosio.savings, which is the worker proposal fund. 27 | 28 | # Discussion 29 | 30 | (Discussion is closed.) Adopted by the Telos Contributors Group 2018-10-16. Voting: 34 YES / 0 NO / 0 ABSTAIN 31 | 32 | # Copyright 33 | 34 | This document is in the public domain 35 | -------------------------------------------------------------------------------- /tip-0031.md: -------------------------------------------------------------------------------- 1 | TIP: 31 2 | Title: Community Rewards Account Creation 3 | Authors: Jerry Huff - BlindBlocArt 4 | Status: Withdrawn - approved in Committee 5 | Type: Information 6 | Created: 2018-10-29 7 | 8 | 9 | # ABSTRACT 10 | 11 | We will need to have a very small amount of TLOS in each community rewards account on 12 | creation so a transaction can be made. 13 | 14 | # MOTIVATION 15 | 16 | The bounty-system work group would like the accounts created along with all the other accounts on injection 17 | so the system can buy the RAM needed to create the account, however they will not know for some time before 18 | the rewards will be distributed. 19 | 20 | # RATIONALE 21 | 22 | On injection the community rewards will not be established, however they want the accounts created so the 23 | transfer can be made at a later date. 24 | 25 | # SPECIFICATIONS 26 | 27 | We would to propose that we create each account with 1 TLOS staked (.9 CPU and .1 NET). The totl cost would be 250 TLOS - it has been reccomended that this 250 TLOS be subtracted from the community rewards pool 28 | 29 | # DISCUSSION 30 | 31 | Open for discussion. 32 | 33 | # COPYRIGHT 34 | 35 | This document is in the public domain 36 | -------------------------------------------------------------------------------- /tip-0026.md: -------------------------------------------------------------------------------- 1 | Tip: 0026 2 | Title: TFVT Distribution 3 | Author: Jerry Huff - BlindBlocArt 4 | Status: Adopted - October 26, 2018 5 | Type: Protocol 6 | Created: 2018-10-18 7 | 8 | 9 | # Abstract 10 | 11 | Propose a cap of 5 TFVT for a fair and equitable distribution of Telos Foundation Voter Tokens (TFVT) based on the pie slicing app. 12 | 13 | 14 | # Motivation 15 | 16 | As it is now, the larger slices will receive 10 TFVT, and it is broken into 10 percentile groups. We would like it broken up into 5 percentile groups making for a much closer vote potential from lowest to highest, this will empower everyone to vote and recognize their vote has value. 17 | 18 | # Rational 19 | 20 | We want the Telos Foundation to be a tight knit group, and this will help along those lines by decreasing the number of TFVT 21 | the larger pie slices would receive. 22 | 23 | # Specification 24 | 25 | That the pie slicing app participants be split into 5 groups with the smallest group getting one TFVT and the largest group 26 | getting 5 TFVT 27 | 28 | # Discussion 29 | 30 | (Discussion is closed) 31 | 32 | Adopted by the Telos Contributors Group October 26, 2018. Voting: Yes - 27 , No - 7 33 | 34 | # Copyright 35 | 36 | This document is in the public domain 37 | -------------------------------------------------------------------------------- /tip-0019.md: -------------------------------------------------------------------------------- 1 | TIP: 0019 2 | Title: Set a 1-year expiration date for unclaimed TLOS in the Exchange Token Reserve Fund (ETRF) 3 | Authors: Amplified Telos (Ian Panchèvre / telos@amplified.software) 4 | Status: Declined 5 | Type: Protocol 6 | Created: 2018–10–08 7 | 8 | # Abstract 9 | 10 | Upon launch, the Telos Blockchain Network Operating Agreement calls for approximately 140 million TLOS to be allocated to an Exchange Token Reserve Fund (ETRF). TIP 19 proposes a “claim it or lose it” policy, such that exchanges have one full calendar year post-launch to enable support for TLOS. 11 | 12 | # Motivation 13 | 14 | The ETRF should motivate exchanges to quickly enable support for TLOS. 15 | 16 | # Rationale 17 | 18 | Facing a deadline, exchanges will be more likely to act. Additionally, users on the exchanges who held EOS will put pressure on the exchanges to enable support for Telos. A smart contract will ensure that on the one year anniversary of Telos’ mainnent launch, any remaining tokens in the ETRF will be burnt. 19 | 20 | # Specification 21 | 22 | Modify text in paragraph 22 of the Telos Blockchain Network Operating Agreement (TBNOA) to read as follows: 23 | 24 | “The Telos Exchange Token Reserve Fund will receive ____ TLOS tokens, which may be distributed to exchanges that enable support for TLOS within one calendar year after the launch of the Telos mainnent.” 25 | 26 | # Discussion 27 | 28 | (Discussion period is closed.) Voted by Telos Contributors Group 2018-10-23. Voting: Yes - 0, No - 30, Abstain - 0 29 | 30 | # Copyright 31 | 32 | This document is in the public domain. 33 | -------------------------------------------------------------------------------- /tip-0015.md: -------------------------------------------------------------------------------- 1 | TIP: 0015 2 | Title: Increase funding for the Telos Foundation from 6 million TLOS to 20 million TLOS 3 | Authors: Amplified Telos (Ian Panchèvre / telos@amplified.software) 4 | Status: Declined 5 | Type: Protocol 6 | Created: 2018–10–08 7 | 8 | # Abstract 9 | 10 | The Telos Foundation is an apolitical organization with a mission to aid in the promotion and improvement of the Telos Network. Tip 15 proposes increasing the capitalization of the Foundation so that it may accomplish these goals. 11 | 12 | # Motivation 13 | 14 | Though not dependent on the Foundation, Telos’ odds for success will likely increase if the Foundation is well managed and capitalized. 15 | 16 | # Rationale 17 | 18 | Given the possibility that the crypto bear market may continue for several years, the Foundation may find itself in a position where it is forced to sell off the bulk of its treasury through Telos’ startup phase. As a result, the Foundation won’t have the capital to continue operating in the distant future. Keep in mind that the Foundation won’t earn ongoing block rewards (though it may submit proposals for funding from the worker proposal system). By further capitalizing the Foundation, its lifespan will be extended and it will have more resources to support Telos during the critical early days. 19 | 20 | # Specification 21 | 22 | Modify text in paragraph 22 of the Telos Blockchain Network Operating Agreement (TBNOA) to read as follows: 23 | 24 | “New Telos accounts will be created to fund the Telos Foundation which will receive 20,000,000 TLOS tokens…” 25 | 26 | # Discussion 27 | 28 | (Discussion period is closed.) Voted by Telos Contributors Group 2018-10-23. Voting: Yes - 0, No - 30, Abstain - 0 29 | 30 | # Copyright 31 | 32 | This document is in the public domain. 33 | -------------------------------------------------------------------------------- /tip-0017.md: -------------------------------------------------------------------------------- 1 | TIP: 0017 2 | Title: Capitalize the Worker Proposal Fund with 10 million TLOS upon mainnet launch 3 | Authors: Amplified Telos (Ian Panchèvre / telos@amplified.software) 4 | Status: Declined 5 | Type: Protocol 6 | Created: 2018–10–08 7 | 8 | # Abstract 9 | 10 | The Worker Proposal Fund (WPF) is a critical element of Telos’ overall system. The WPF accumulates TLOS from the daily inflation pool to finance value-added activities for the network. Currently, the WPF is only funded from the inflation pool. TIP 17 proposes seeding the WPF with 10 million TLOS upon launch. 11 | 12 | # Motivation 13 | 14 | A well-capitalized WPSF will benefit Telos because the network will be able to pay for more technical and community contributions. 15 | 16 | # Rationale 17 | 18 | Although the WPF will earn TLOS in perpetuity, the fund itself will not be especially wealthy when the network activates. Accordingly, Telos will struggle to finance early projects and it will be forced to make unpleasant tradeoffs in its capital allocation processes. Immediately capitalizing the WPF with 10 million TLOS will allow Telos to hit the ground running with new initiatives, as the fund gradually replenishes itself from inflation. 19 | 20 | Note that 10 million is also the approximate number of TLOS the WPF should accumulate within the first two years; TIP 17 effectively pre-populates the WPF with two years’ worth of TLOS. 21 | 22 | # Specification 23 | 24 | Modify text in paragraph 22 of the Telos Blockchain Network Operating Agreement (TBNOA) to read as follows: 25 | 26 | “Moreover, 10,000,000 TLOS will be allocated to the Worker Proposal Fund.” 27 | 28 | # Discussion 29 | 30 | (Discussion period is closed.) Voted by Telos Contributors Group 2018-10-23. Voting: Yes - 0, No - 30, Abstain - 0 31 | 32 | # Copyright 33 | 34 | This document is in the public domain. 35 | -------------------------------------------------------------------------------- /tip-0029.md: -------------------------------------------------------------------------------- 1 | ``` 2 | Withdrawn to give time for discussions to conclude on Slack. 3 | 4 | TIP: 0029 5 | Authors: Azad Halim 6 | Status: Withdrawn 7 | Type: Informational 8 | Created: 2018-10-25 9 | ``` 10 | 11 | Abstract 12 | --------- 13 | 14 | This TIP is dependent on the approval/passing of either TIP 24 or 15 | the equivalent TIP 28 (Provision 1). 16 | 17 | Octagon Labs proposes that a cap is introduced on any single entity or 18 | team at an agreed percentage share of the Telos Founders’ Reward 19 | Pool of 12 million tokens. 20 | 21 | Motivation 22 | ----------- 23 | 24 | Since its conception back in July 2018, the Telos project attracted a 25 | large number of contributors to Good Block's excellent initiative. 26 | 27 | TIP 24 recognises this fact and aims to reward those additional contributors 28 | for their hard work but falls short of it's objective by not taking into 29 | account the current slicing-pie model. 30 | 31 | Rational 32 | --------- 33 | 34 | Of the estimated total number of 300 million Telos tokens, 18 million 35 | is to be awarded to contributers who have worked tirelessly on the succesful 36 | launch of the Telos Blockchain Network. 37 | 38 | - 100% of the 18 million tokens is equivilent to 6% of the total supply. 39 | - 75% of 18 million tokens is equivalent to 4.5% of the total supply. 40 | - 66% of 18 million tokens is equivalent to 4.0% of the total supply. 41 | - 50% of 18 million tokens is equivalent to 3.0% of the total supply. 42 | 43 | The rational for creating Telos is to provide a DPoS network where token 44 | holders are given a second opportunity for the EOS community to participate 45 | more effectively and establish a wider circle of trust through fairer 46 | distribution. 47 | 48 | I encourage all Telos launch controibuters to apply the spirit of 49 | "fair distribution" to themselves as well as others, as the launch date 50 | approaches, to start with a trustworthy foundation for future Telos 51 | participents to build on. 52 | 53 | 54 | Discussion 55 | ----------- 56 | 57 | The Telos Launch Group to consider the above example percentages and agree on a 58 | limit/cap per entity on the share of the Telos Founders' Reward Pool. 59 | 60 | (Discussion period is open.) 61 | 62 | 63 | Copyright 64 | ---------- 65 | This document is in the public domain. 66 | -------------------------------------------------------------------------------- /tip-0032.md: -------------------------------------------------------------------------------- 1 | TIP: 32 2 | Title: Vesting Schedule for Telos Foundation Rewards Pool Tokens 3 | Authors: EOS Detroit (Adam Zientarski, adam@eosdetroit.io, Rob Konsdorf, rob@eosdetroit.io) 4 | Status: Defeated 5 | Type: Protocol 6 | Created: 2018-10-31 7 | Voting: 2018-11-15 Yes - 6, No - 24, Abstain - 0 8 | 9 | 10 | # ABSTRACT 11 | 12 | This proposal calls for the creation of a vesting schedule for Telos Foundation Rewards Pool tokens that were awarded to Telos Launch Group contributors. 13 | 14 | # MOTIVATION 15 | 16 | Given the increase of 12 million TLOS in the expected token supply as a result of TIP: 0024 and the potential for token price instability at launch as a result of large sales of Telos Foundation Rewards Pool Tokens by Telos Launch Group contributors. 17 | 18 | Less tradable tokens in circulation should also mean a higher initial token price for the network, which will help maintain financial sustainability for block producers and other network actors. 19 | 20 | Beyond that, vesting schedules are standard operating procedure for founder's grants in traditional and token-based startups, and showcase a longer term commitment and alignment to the project. It sends a signal to the market that Telos contributors who received grants are not just attempting to loot and run. 21 | 22 | # RATIONALE 23 | 24 | A vesting schedule is commonplace in many startup business arrangements and aligns and ensures the interests of early contributors to continue to invest in the success of the Telos Blockchain Network long-term. 25 | 26 | 27 | # SPECIFICATIONS 28 | 29 | TFRP balances will be put into special accounts that have a custom unstaking period. This enables the TFRP balances to be used the same as any staked TLOS, while disallowing immediate liquid access to the tokens. An example of this today would be how Steem Power works; when SP is being "powered down", a portion of the balance becomes liquid periodically (every week), for 13 weeks total. Our recommendation is a 1 year unstaking period (52 weeks) that provides a 1/52 of the funds every week. 30 | 31 | # DISCUSSION 32 | 33 | The total period to fully liquidate and the period by which a portion of the tokens become available are up for discussion. 34 | 35 | # COPYRIGHT 36 | 37 | This document is in the public domain 38 | -------------------------------------------------------------------------------- /ArbMinReq.md: -------------------------------------------------------------------------------- 1 | Title: Telos Blockchain Network Arbitrator Minimum Requirements 2 | Authors: Justin Buck, Mark Cohen, Jim Hewitt, Douglas Horn, Syed Mushabbar Sadiq, Adam Zientarski 3 | Adoption: Adopted by Telos Contributors Group 2018-10-12 4 | Voting: Yes - 25, No - 0, Abstain - 0 5 | 6 | 7 | # Telos Blockchain Network Arbitrator Minimum Requirements 8 | 9 | ## Phase One 10 | 11 | Initial set of Minimum Requirements 12 | 13 | ### A. Disclosures 14 | 15 | 1. Arbitrator Entity Ownership 16 | 17 | a. Disclosure of each beneficial owner of arbitrator entity along with percentage of ownership. 18 | 19 | b. Disclosure of country of residency or establishment for arbitration entity. 20 | 21 | 2. Arbitral Judges 22 | 23 | a. Disclosure of each arbitral judge in arbitration entity along with languages of proficiency. 24 | 25 | b. Secondary education to Bachelor’s degree from a 4-year accredited college or university or equivalent. 26 | 27 | c. Familiarity with the rules of arbitration. 28 | 29 | d. Understanding of mechanics of blockchain and EOSIO from provided reading list. 30 | 31 | 32 | ## Phase Two 33 | 34 | Minimum Requirements accepted by 2/3+1 of current Block Producers 35 | 36 | ### A. Disclosures 37 | 38 | 1. Arbitrator Entity Ownership 39 | 40 | a. Disclosure of each beneficial owner of arbitrator entity along with percentage of ownership. [enforced by smart contract] 41 | 42 | b. Disclosure of country of residency or establishment for arbitration entity. 43 | 44 | c. Disclosure of identity service provider and identity hash of each beneficial owner of arbitrator entity along with percentage of ownership. [enforced by smart contract] 45 | 46 | 2. Arbitral Judges 47 | 48 | a. Disclosure of each arbitral judge in arbitration entity along with languages of proficiency. [enforced by smart contract] 49 | 50 | b. Disclosure of identity service provider and identity hash of each arbitral judge along with languages of proficiency. [enforced by smart contract] 51 | 52 | c. Secondary education to Bachelor’s degree from a 4-year accredited college or university or equivalent. 53 | 54 | d. Familiarity with the rules of arbitration. 55 | 56 | e. Understanding of mechanics of blockchain and EOSIO from provided reading list. 57 | 58 | # Copyright 59 | 60 | This document is in the public domain 61 | -------------------------------------------------------------------------------- /DataProtectionPolicy.md: -------------------------------------------------------------------------------- 1 | Title: Telos Blockchain Network Data Protection Policy 2 | 3 | Key details 4 | Policy prepared by: Azad Halim 5 | Approved by: The Telos Contributors Group 6 | Approved on: October 12, 2018 7 | Policy became operational on: 8 | Next review date: 9 | Adoption: Adopted by Telos Contributors Group 2018-10-12 10 | Voting: Yes - 22, No - 0, Abstain - 0 11 | 12 | # Telos Blockchain Network Data Protection Policy 13 | 14 | ## Introduction 15 | 16 | Telos is a network of decentralised and autonomous entities known as participants, as defined in the Telos Blockchain Network Operators Agreement (TBNOA) document. From hereon, Telos will be referred to as the Telos Blockchain Network (TBN). Its Participants may include, but are not limited to, users, businesses, application developers, block producers and other entities that the TBN has a relationship with. 17 | 18 | ## Policy Summary 19 | 20 | 1. The TBN provides a public blockchain service. A public blockchain, by definition, is a public service that is open to all participants. 21 | 22 | 2 .Data provided by network participants is recorded by Block Producers on the TBN, and hence is public - visible to all participants and nonparticipants alike. Therefore, it is the responsibility of the network participants themselves, to recognize and understand they are in control of their data, and hence need to comply with the relevant data protection laws and process the data in a manner that applies to their individual use cases, and is in compliance with their individual regulatory requirements 23 | 24 | 3. The TBN requires all Block Producers to take the necessary measures to ensure the immutability, integrity and availability of the data recorded on the Telos blockchain, who may be subject to service level agreements with one or more TBN participants, but are not responsible for the confidentiality of the data. 25 | 26 | 4. The TBN does not have any employees. 27 | 28 | 5. This policy only applies to the TBN. Any future blockchain networks that may connect to the TBN shall be responsible for their own policy. 29 | 30 | 6. This policy will be reviewed annually by the TBN. 31 | -------------------------------------------------------------------------------- /tip-0014.md: -------------------------------------------------------------------------------- 1 | TIP: 0014 2 | Title: Increase the Telos Founders’ Reward Pool from 6 million TLOS to 25 million TLOS 3 | Authors: Amplified Telos (Ian Panchèvre / telos@amplified.software) 4 | Status: Declined 5 | Type: Protocol 6 | Created: 2018–10–08 7 | 8 | # Abstract 9 | 10 | TIP 14 proposes increasing the number of TLOS tokens allocated to the Telos Founders’ Rewards Pool (TFRP) from 6 million to 25 million. 11 | 12 | # Motivation 13 | 14 | A global network of contributors has emerged to support Telos. These contributors have incurred significant material and opportunity costs while the network remains unlaunched. Moreover, some community members have incorporated businesses and are pursuing outside capital to finance operational expansion (disclosure: Amplified Telos is one of those entities). Those who are involved with Telos’ mainnet launch should be appropriately rewarded. 15 | 16 | # Rationale 17 | 18 | As currently written, the TBNOA funds the TFRP with 6 million TLOS tokens. However, that sum may not sufficiently reward those involved with the Telos launch. Consider that the current token allocation outlined in the TBNOA would set aside approximately 1.8% of all the circulating TLOS for the TFRP that will be divided among over 100 launch group contributors. 19 | 20 | Simply put, for block producers and development teams that have spent real money in support of Telos, the 6 million TFRP may not be sufficient to recover sunk capital and/or attract outside investment. Increasing the size of the TFRP to 25 million is not unreasonable. If all 7 of Amplified’s TIPs were approved, then approximately 7.49% of all circulating tokens will have been distributed through the TFRP. Although the pay for each launch contributor will more than triple, it’s quite possible that the absolute value of the reward remains relatively modest, given the near-term price prospects for the greater cryptocurrency market. 21 | 22 | # Specification 23 | 24 | Modify text in paragraph 22 of the Telos Blockchain Network Operating Agreement (TBNOA) to read as follows: 25 | 26 | `“New Telos accounts will be created to fund … the Telos Founders’ Reward Pool which will receive 25,000,000 TLOS tokens …”` 27 | 28 | # Discussion 29 | 30 | (Discussion period is closed.) Voted by Telos Contributors Group 2018-10-23. Voting: Yes - 0, No - 30, Abstain - 0 31 | 32 | # Copyright 33 | 34 | This document is in the public domain. 35 | -------------------------------------------------------------------------------- /tip-0012.md: -------------------------------------------------------------------------------- 1 | TIP: 0012 2 | Title: A mechanism for establishing director salaries for the Telos Foundation 3 | Authors: EOS Detroit (Adam Zientarski, adam@eosdetroit.io) and Amplified Telos (Ian Panchevre) 4 | Status: Adopted 5 | Type: Informational 6 | Created: 2018-10-09 7 | Adopted: 2018-10-16 8 | 9 | # Abstract 10 | 11 | This proposal calls for a separate voting procedure for establishing the salaries of all Telos Foundation directors and board members. 12 | 13 | # Motivation 14 | 15 | The Telos Foundation must avoid the fates of previous cryptocurrency foundations (e.g., the Bitcoin Foundation) that have been hampered by cultures of cronyism. Accordingly, the proposal authors are concerned that directors and board members may use their positions to enrich themselves and that the close-knit nature of participants in the Foundation may breed favoritism that further corrupts the organization. This not as an indictment against any particular individual or organization, but rather as an acknowledgement of the human tendency to become corrupted by power and potential to profit. 16 | 17 | # Rationale 18 | 19 | By restricting the board’s and director’s ability to set salaries themselves, and instead empowering the broader TFVT voter base with this task, the Telos Foundation may ensure that directors and board members are motivated not by financial gain but by a sense of service. Moreover, by extracting the salary-setting mechanism from the board, it reduce the odds of quid pro quo cronyism between the board (which ought to maintain oversight of the Foundation) and the executive team (which has operational responsibility for the Foundation). 20 | 21 | # Specification 22 | 23 | Telos Foundation directors and board members may receive a salary in TLOS. This TIP proposes that the salaries of directors and board members should be voted upon by all Telos Foundation Voting Token (TFVT) holders. Independent salary proposals that are separate from overall budgets may be put forth and presented to a vote by TFVT token holders. Ideally, salaries should be voted upon at least once a year, at which point the salary line items will be folded into subsequent, quarterly budget proposals. New salaries may be proposed at any time; if approved, the new salaries will go into effect during the next quarter. 24 | 25 | # Discussion 26 | 27 | (discussion is closed) Adopted by the Telos Contributors Group 2018-10-16. Voting: 42 yes / 0 no / 0 abstain 28 | 29 | # Copyright 30 | 31 | This document is in the public domain 32 | -------------------------------------------------------------------------------- /tip-0010.md: -------------------------------------------------------------------------------- 1 | TIP: 0010 2 | Title: Telos Chain Activation Process 3 | Authors: Douglas Horn 4 | Status: Adopted 5 | Type: Protocol 6 | Created: 2018-09-27 7 | Adopted: 2018-10-02 by Telos Launch Group. Voting: Yes= 29 No= 0 Abstain = 0 8 | 9 | # Abstract 10 | 11 | Determine that the Telos Blockchain Network, once launched shall activate based on the passage of time at a block height of 1,000,000 blocks rather than when it has received 15% of TLOS holders' votes. 12 | 13 | # Motivation 14 | The Telos Blockchain Network is approaching its first launch vote meeting and will soon consider launching and activating the network. It is necessary to clearly explain the procedure for launching and activating the Telos Blockchain Network. The process for activating the network using activation voting should be revised into a time-based activation because the rationale for EOS activation is inapplicable to Telos. Because this was explained differently in the Telos white paper, it is necessary to document this change here. 15 | 16 | # Rationale 17 | 18 | The Telos white paper spoke of using 15% activation voting to determine when the network should activate, just as EOS did. EOS required this voting process because Block.One had sold EOS tokens in a public sale but removed themselves from the launch process. Therefore, to allow the EOS community to determine which of many potential EOS chains would be the most valid one, Block.One required a chain to receive 15% of votes from among all EOS genesis tokenholders. Ultimately, only one EOS chain launch attempt was made and the EOS network activated 4 days, 4 hours, and 41 minutes later. Telos has never sold any tokens and there is no danger of multiple potential Telos networks launching. The rationale for activation voting, therefore does not apply to Telos and only serves as an unnecessary and unfounded impediment. Exchanges, Dapps, and users can only begin using the network on activation and Dapp developers in particular have a strong preference for a firm date for activation. 19 | 20 | # Specification 21 | 22 | It is proposed that Telos activate its network at block 1,000,000, 5.8 days after launch. This will give users ample time to begin voting for the block producers who will operate the network, while providing all other stakeholders a predictable date and time to commence operations and activity. 23 | 24 | # Discussion 25 | 26 | Discussion is closed. Debated and adopted unanimously by the Telos Contributors Group. October 2, 2018 (Yes= 29 No= 0 Abstain = 0). 27 | 28 | # Copyright 29 | 30 | This document is public domain. 31 | -------------------------------------------------------------------------------- /tip-0024.md: -------------------------------------------------------------------------------- 1 | TIP: 0024 2 | Title: Adequately Rewarding Telos Contributors 3 | Authors: Michael Gucci, MD; Z-Meta 4 | Bhargav Kalari, ME ; Telos-21Zephyr ; bhargav.narasimha@gmail.com 5 | Status: Adopted 6 | Type: Informational 7 | Created: 2018-10-17 8 | 9 | # Abstract 10 | 11 | We propose to increase the Telos Founder’s Reward Pool from 6 Million TLOS to 18 Million TLOS: to account for the increased launch group participants since inception to receive a split of 6M TLOS and an unexpected extended launch period, to reflect the current bear market conditions and, to adequately compensate the work done by all the good people for their work in launching the Telos Network. 12 | 13 | # Motivation 14 | 15 | The original proposal called for 6 million TLOS shared amongst 6 BPs. We have since changed this to reflect community feedback and have opened up the 6 million TLOS reward pool to all participants of the network. As a result, we have on-boarded over 100+ contributors to the Telos Launch Group. However, the unintended consequence of this openness is a much lower reward compensation to each contributor in a bear market. 16 | 17 | Additionally, the expected launch of the Telos Blockchain Network was in the August – September timeframe, which has since been delayed by No-Go votes in September and October 2018. 18 | 19 | We believe an increase to 18 million TLOS will provide adequate compensation to reflect the increase in launch participants as well as the extended delay in launching the network. 20 | 21 | We are very close to launching the Telos Network and this would not have been possible without the hard work done by all the good people involved in this project. Market conditions have changed since writing the White Paper and we are currently in a bear market. The opening price of TLOS is expected to be low and this may not adequately compensate all the hard work done by all these exceptional people. 22 | 23 | # Rationale 24 | 25 | With the current bear market conditions, the opening price of TLOS is expected to be low. Increasing the Telos Founder’s Rewards Pool to 18 Million TLOS will compensate for the depressed market conditions and adequately reward the hard work done by all the unexpectedly large number of exceptional launch participants involved with the Telos Project. 26 | 27 | 28 | # Specifications 29 | 30 | The increased token supply will come from additional issuance at launch. 31 | 32 | # Discussion 33 | 34 | (discussion is closed) 35 | 36 | Adopted by the Telos Contributors Group October 26, 2018. Voting: Yes - 25, No - 3, Abstain - 3 37 | 38 | # Copyright 39 | 40 | This document is in the public domain. 41 | -------------------------------------------------------------------------------- /tip-0018.md: -------------------------------------------------------------------------------- 1 | TIP: 0018 2 | Title: Frontload TLOS inflation schedule 3 | Authors: Amplified Telos (Ian Panchèvre / telos@amplified.software) 4 | Status: Declined 5 | Type: Protocol 6 | Created: 2018–10–08 7 | 8 | # Abstract 9 | 10 | The current inflation schedule of 2.5% a year may not generate enough capital to sufficiently finance the Worker Proposal Fund (WPF) and the block producers. TIP 18 proposes frontloading the TLOS inflation schedule. 11 | 12 | # Motivation 13 | 14 | The value of annual inflation must be sufficient to pay for critical projects (as sourced through the Worker Proposal System) as well as cover the operations of at least 51 block producers. By increasing the inflation rates during the early years of network operations, Telos stakeholders will be more likely to be sufficiently capitalized. 15 | 16 | # Rationale 17 | 18 | As currently structured, daily pay rates for block producers are likely insufficient to cover operations. We must design Telos’ token economy in such a way that it may persevere through a protracted bear cycle. If Telos achieves the rank of #30 on coinmarketcap.com (and is valued similarly to Decred and Qtum), then the value of an individual TLOS will be approximately $1. According to the current block producer pay rate (annual inflation of 1% shared among 51 active and standby BPs), then active BPs will earn $252 a day and standby BPs will earn $126 a day. At these rates, many BPs will struggle to sustain operations and raise outside capital. 19 | 20 | Additionally, given that Telos will compete for market share against very well financed smart contract platforms, an annual inflation of 1.5% allocated to the WPF is also unlikely to generate sufficient capital. Again, assuming that TLOS trades at $1, then approximately $4,976,227 worth of TLOS will reach the WPF during the first year. Many smart contract platforms have hundreds of millions or even billions of dollars in operating capital; Telos needs more fire power. 21 | 22 | # Specification 23 | 24 | Modify language in the Telos Blockchain Network Operating Agreement (TBNOA) so that the annual inflation percentage is scheduled accordingly: 25 | 26 | 27 | | YEAR | WPF | BP | Annual Inflation | 28 | |-------|------|-----|--------------------| 29 | | 1 | 2.5 | 2.5 | 5.0 | 30 | | 2 | 2.25 | 2.25 | 4.5 | 31 | | 3 | 2.0 | 2.0 | 4.0 | 32 | | 4 | 1.75 | 1.75 | 3.5 | 33 | | 5 | 1.5 | 1.5 | 3.0 | 34 | | 6 | 1.5 | 1.25 | 2.75 | 35 | | 7 | 1.5 | 1 | 2.5 | 36 | | 8 | 1.5 | 1 | 2.5 | 37 | 38 | 39 | # Discussion 40 | 41 | (Discussion period is closed.) Voted by Telos Contributors Group 2018-10-23. Voting: Yes - 0, No - 30, Abstain - 0 42 | 43 | # Copyright 44 | 45 | This document is in the public domain. 46 | -------------------------------------------------------------------------------- /tip-0009.md: -------------------------------------------------------------------------------- 1 | TIP: 0009 2 | Title: Telos “Original” Snapshot Creation 3 | Authors: Douglas Horn 4 | Status: Draft 5 | Type: Protocol 6 | Created: 2018-09-26 7 | 8 | # Abstract 9 | 10 | The creation of an official Telos "original" snapshot in place of a published Telos "genesis" snapshot that would be captured at block 6,000,000, 29 days after network activation and capturing the current balance of all Telos accounts that have performed one action or more by that time to reward Telos early adopters. 11 | 12 | # Motivation 13 | 14 | Several current EOS owners who were not a part of the original EOS ERC-20 snapshot have expressed legitimate concern about Telos using this snapshot for creating our initial token balances as opposed to a more recent one. We have already discussed why this is necessary [LINK TO ARTICLE]. However, there is one element of the Telos community’s comments that we could respond to. This TIP aims to call attention to what we could improve and proposes a simple way to be more inclusive with our community and responsive to their concerns in this area. 15 | 16 | # Rationale 17 | 18 | Recently, a new point has been raised about one unintended consequence of using the EOS ERC-20 snapshot. It is that by using this snapshot, we are rewarding EOS early supporters and backers. However, if a slightly modified version of this snapshot also becomes the Telos genesis snapshot, then there is no opportunity for the Telos early supporters and participants to have their participation rewarded by future airdrops and any other type of rewards meant to include the earliest backers of the project. This is an absolutely valid concern. Why should Telos not capture a record of those who embrace the network early on? And by the same token, why should Telos capture those accounts that may never engage with the network or only to sell off their tokens immediately. And a final crucial concern is that a true genesis snapshot would not include members of the Community Rewards Program who are engaging with the world to raise the Telos profile. 19 | 20 | # Specification 21 | 22 | To solve this problem, Telos should eschew any actual “genesis” snapshot, which would really just be a slight modification of the EOS genesis snapshot with three additional accounts and replacements of lost keys. Instead, I propose the Telos “original” snapshot to occur at block 6,000,000 on the Telos mainnet (29 days after activation at block 1,000,000) which will serve as the “official” first Telos snapshot, to be maintained on the network as proposed in TIP-3 for the use of any airdrops or other rewards programs in the future that may wish to reward or distribute to the original backers of Telos. 23 | 24 | The Telos “original” snapshot will capture the balance of every Telos address that has opted-in and accepted the Telos Blockchain Network Operating Agreement but performing any action (voting, staking, unstaking, transfer, et cetera). This will allow Community Rewards Pool members, new TLOS token purchasers and others to be recorded and will encourage early participation in the Telos network. 25 | 26 | # Discussion 27 | 28 | Discussion is closed. Debated and adopted by 2/3+1 majority of Telos Contributors Group. October 2, 2018 (Yes= 22 No= 4 Abstain = 3). 29 | 30 | # Copyright 31 | 32 | This document is in the public domain 33 | -------------------------------------------------------------------------------- /tip-0007.md: -------------------------------------------------------------------------------- 1 | TIP: 0007 2 | Title: Establishment and Rules of the Telos Community Rewards Pool 3 | Authors: Douglas Horn 4 | Status: Draft 5 | Type: Informational 6 | Created: 2018-07-20 7 | 8 | # Abstract 9 | 10 | This TIP proposes the establishment of a Telos Community Rewards Pool to engage community members in the Telos project and reward them with TLOS tokens for their contributions. 11 | 12 | # Motivation 13 | 14 | The members of the Telos Launch Group overwhelmingly voted on July 18 to create a Telos Community Reward Pool to reward those who contribute to the project through media creation or similar community building and promotional efforts. Many details of the proposal are unresolved. 15 | 16 | # Rationale 17 | 18 | The Telos Launch Group has discussed this issue and deemed it important. An earlier draft of this TIP was presented in another format. The TLG has voted twice on the matter. First on 2018-07-23 to adopt the general idea of the TCRP and again on 2018-08-01 to designate that the total value of the TCRP be up to 1,000,000 TLOS with the provision that the fund's excess coins can be burned or donated if there is insufficient participation to merit this amount. 19 | 20 | # Specifications 21 | 22 | 1. The total amount of the TCRP shall be 1,000,000 TLOS tokens. There shall be a maximum amount received per person and tokens in excess of this amount will be burned or donated. 23 | 24 | 2. TLG members may choose to earn rewards under either the TFRP or the TCRP but not both. 25 | 26 | 3. The TCRP will be divided into sub-pools. For example: 27 | a. YouTube – 25% of TCRP 28 | b. Twitter – 25% 29 | c. Facebook – 20% 30 | d. Reddit – 10% 31 | e. Medium – 10% 32 | f. Steemit – 7% 33 | g. Bitcointalk.org – 3% 34 | 35 | 4. It is a priority to also consider social media outlets that are popular in other parts of the world besides North America and Europe where the majority of the current TLG members reside. Suggestions include China's Weibo/WeChat and Korea's KakaoTalk apps. 36 | 37 | 5. A suggestion has been made to include exchange-related bounty programs or campaigns to get large numbers of people to approach their exchanges asking to add TLOS tokens. 38 | 39 | 6. The rules for TCRP participants. Suggestion: 40 | a. Each participant must register with TLG listing the social media channel(s) they will contribute in, as well as a Telos public key rewards will be deposited to. 41 | b. Each piece of content must include links to at least one official Telos social media outlet (e.g. web site, YouTube channel, Telos twitter). 42 | c. Content must not be negative to Telos. 43 | 44 | 7. Each sub-pool will have its own definitive metric. Suggestion: 45 | a. YouTube – # of total minutes watched 46 | b. Twitter – # of __ 47 | c. Facebook – # of likes 48 | d. Reddit – # of upvotes 49 | e. Medium – # of upvotes 50 | f. Steemit – # of upvotes 51 | g. Bitcointalk.org – # of messages posted with Telos Footer with 2x multipliers for each bitcointalk.org membership level starting at Jr Member. (e.g. Jr member = 1, Member = 2, Sr Member = 4, etc) 52 | 53 | 8. At Telos network activation, each contributor’s metrics will be calculated in each sub-pool. Each contributor’s share of the rewards will be their percentage of any sub-pool’s total shares. 54 | a. It is expected to take up to 4 weeks to calculate and distribute TCRP rewards. 55 | 56 | # Discussion 57 | 58 | The Telos Contributors Group voted to enact the terms of this TIP with some modifications. 59 | 60 | # Copyright 61 | 62 | This document is in the public domain. 63 | -------------------------------------------------------------------------------- /tip-0033.md: -------------------------------------------------------------------------------- 1 | TIP: 33 2 | Title: Voting Restrictions on Telos Foundation Rewards Pool Tokens 3 | Authors: EOS Detroit (Adam Zientarski, adam@eosdetroit.io, Rob Konsdorf, rob@eosdetroit.io) 4 | Status: Withdrawn 2015-11-15 5 | Type: Protocol 6 | Created: 2018-10-31 7 | 8 | 9 | # ABSTRACT 10 | 11 | This proposal calls for creating a restriction on Telos Launch Group contributors voting with Telos Foundation Rewards Pool (TFRP) tokens. 12 | 13 | # MOTIVATION 14 | 15 | Creating a new group of whales is against the spirit of why the Telos was created in the first place; an experiment into different token economics and token voting mechanics to create a blockchain more resilient to the over influence of a group of a select few. 16 | 17 | # RATIONALE 18 | 19 | Contributors in the Telos Launch Group have accrued tokens through their contributions to the project over the past 4 months. In many cases, individuals, block producers, and other organizations will receive many more tokens than the 40,000 per account cap during the airdrop, creating a new whale class within the Telos Blockchain Network. Even with inverse-weighted voting and other whale mitigation mechanisms, Telos Launch Group contributors running as block producer candidates may be able to vote themselves into an active or standby position. Furthermore, an active or standby block producer may be able to sustain their position even if Telos Blockchain Network Members decide to withdraw their support for a block producer. 20 | 21 | The restriction should also extend to Telos Launch Group contributors who are not running block producers for a few reasons. The first is that these individuals or entities may decide to run block producers in the future. The second is that the TFRP distributions will still make some of these members voting whales. Even if these whales end up benevolent in nature, systematic creation of voting whales is counterintuitive to the ethos of the Telos Blockchain Network. 22 | 23 | # SPECIFICATIONS 24 | 25 | This TIP is intended to be passed in tandem with TIP: 0032, but was published as two separate documents to allow ease of discussion and potential amendments. 26 | 27 | ## Amend the Telos Blockchain Network Operating Agreement (TBNOA) to include the following clauses: 28 | 43. Telos Foundation Rewards Pool Token Distribution and Accounts 29 | The Telos Contributors must register a separate account using the “regrewards” contract to receive their Telos Foundation Rewards Pool tokens. 30 | 31 | 44. Telos Foundation Rewards Pool Token Vesting Schedule 32 | The voting power of accounts that have called the “regrewards” contract shall be capped at 40,000 TLOS regardless of account balance. 33 | 34 | AND 35 | 36 | Renumbering of the TBNOA contract clauses to reflect the amendment. 37 | 38 | ## Amend the regproducer contract to include the following clause and changes: 39 | 23. Respect of Telos Foundation Rewards Pool Token Restrictions 40 | I, {{producer}}, agree to not circumvent or aid another block producer in circumventing checks and balances put in place by the “regrewards” contract in regards to the Telos Foundation Rewards Pool tokens. Apparent intentional violation of the preceding, as judged by a majority of 2/3+1 of all block producers, shall be cause for my disqualification from all service as a block producer for 32,000,000 block (approximately 180 days) on first offence or 63,000,000 blocks (approximately 365 days) on second or subsequent offenses. Examples of circumventing include but are not limited to “token washing” or sale of the account to a third party. 41 | 42 | AND 43 | 44 | Renumbering of the regproducer contract clauses to reflect the amendment. 45 | 46 | ## Create or amend the “regrewards” contract with the following functionality: 47 | Regardless of the amount of tokens in the account that calls the contract, the maximum vote power of an account shall not exceed 40,000 Telos. 48 | 49 | # DISCUSSION 50 | 51 | Open for discussion. 52 | 53 | # COPYRIGHT 54 | 55 | This document is in the public domain. 56 | -------------------------------------------------------------------------------- /tip-0011.md: -------------------------------------------------------------------------------- 1 | TIP: 0011 2 | Title: TLOS Token Exchange Reserve 3 | Authors: Douglas Horn 4 | Status: Draft 5 | Type: Protocol 6 | Created: 2018-09-27 7 | 8 | # Abstract 9 | 10 | An Exchange Reserve of 140,279,973 TLOS tokens should be created to capture all of the expected TLOS tokens that will eventually need to be created for EOS genesis token holders whose tokens were on exchanges at the time of the EOS snapshot. Creating a consistent and clearly defined TLOS token supply from network launch has several advantages including providing a more consistent public message about the value of the Telos Blockchain Network. 11 | 12 | # Motivation 13 | 14 | Telos is committed to reserving or printing tokens for those EOS owners as of the ERC-20 snapshot whose EOS tokens were locked on exchanges at that time. The Telos white paper called for a process whereby these tokens would not be created at network launch and instead would be created from time to time as exchanges and similar entities such as web wallets or investment funds who hold tokens for multiple beneficial owners in comingled accounts. However, printing new tokens ad hoc has disadvantages compared to printing all of the expected tokens in the money supply into a block producer-controlled multi-sig Exchange Reserve account at launch and distributing these locked funds to exchanges instead of printing new ones. 15 | 16 | # Rationale 17 | 18 | The Telos white paper calls for new TLOS tokens to be minted in the future by the block producers at the time when each exchange, web wallet, or other entity that held EOS for multiple beneficial owners at the time of the EOS ERC-20 snapshot agrees to the terms of the Telos Blockchain Network’s agreement (such as subjecting each individual account to the 40,000 cap, providing TLOS tokens to the customers at the time, et cetera). Lately, it has become apparent that this poses some problems and that it would be better to create all the tokens at network launch and allow future block producers to disburse these tokens rather than newly mint them. This avoids several small problems and is a better approach than to greatly expand the TLOS token supply in the future. 19 | 20 | Creating a more realistic full money supply at launch allows Telos to report a more accurate initial money supply to exchanges who consider this value for listing. It eliminates future shifts of value when large new amounts of tokens are minted for exchange customers. It more accurately presents the real inflation of the system for block producer pay and worker proposal system reserves. It anticipates the possibility of resources being allocated directly to token holders at some future point, which exchange customers would otherwise miss out on. 21 | 22 | Authority for disbursing tokens in the future is the same as it would be for minting new tokens: the block producers at any time my vote to either create new tokens or disburse the locked up tokens by a vote of 2/3+1. If the amount of tokens reserved should prove to not be enough to provide tokens to all EOS token owners of record, block producers will still have the ability to print more tokens for these owners. 23 | 24 | # Specification 25 | 26 | It is proposed that Telos create an Exchange Reserve account holding 140,279,973 TLOS tokens to make the money supply at the launch of the Telos Blockchain Network 331,753,222 TLOS. This account shall be controlled by a multi-sig wallet requiring 2/3+1 of the current block producers at any time in order to disburse funds. This is the same standard that would have been required to print new tokens. This provides a much more realistic initial TLOS token-supply, which is beneficial for all Telos stakeholders. If it should occur that in the future, these reserved funds are not sufficient to create tokens for all EOS genesis tokenholders, the block producers at that time may still print new tokens to make up the insufficiency. If it should happen that all genesis EOS token holders have claimed their tokens and there are excess tokens remaining in the reserve funds, the block producers and community at that time may determine how to dispose of the excess tokens. Possible actions include destroying the excess tokens, applying them to the worker proposal fund accounts, or distributing them among all current TLOS tokenholders. 27 | 28 | # Discussion 29 | 30 | Discussion is closed. Debated and adopted by 2/3+1 majority of Telos Contributors Group. October 2, 2018 (Yes= 27 No= 0 Abstain = 3). 31 | 32 | # Copyright 33 | 34 | This document is in the public domain. 35 | -------------------------------------------------------------------------------- /tip-0002.md: -------------------------------------------------------------------------------- 1 | TIP: 0002 2 | Title: A Bounty System for Slicing the Telos Founders Rewards Pool Proportionally Amongst Contributors 3 | Authors: Robert Konsdorf 4 | Douglas Horn 5 | Status: Draft 6 | Type: Informational 7 | Created: 2018-07-29 8 | Discussion: https://www.youtube.com/watch?v=FNSQ3s8a09A 9 | 10 | # Abstract 11 | 12 | This proposal provides contributors to the launch of the Telos network the ability to earn slices of the Telos Founders Rewards Pool (TFRP) proportional to the quantity of their contributions. The TFRP is a distribution of 6 MM TLOS for the purpose of incentivizing the growth and development of the Telos network pre-launch. Contributions are units of risk that are measured by cash value. Some examples include time spent working on a task, or spending money in a manner that contributes to a successful Telos launch. Contributions can also be assigned as a fixed bounty on higher value tasks, such as negotiating to earn a Tier 1 exchange’s support or onboarding a high profile DApp project to Telos. 13 | 14 | # Motivation 15 | 16 | This proposal aims to create incentive structures for those risking time and money to lay the groundwork to launch the Telos network. Creating incentives for initial contributors will increase the chances for success of the Telos project as a whole. The proposed method is based on the “Slicing Pie” model and aims to be transparent, objective, and fair for all participants who would like to contribute. 17 | 18 | # Rationale 19 | 20 | The bounty system design is based on the Slicing Pie methodology which can be summarized as a framework for objectively measuring a fair split given a group of contributors that are all risking varying amounts of time and/or cash. The goal is to achieve a split where each contributor’s: 21 | 22 | 23 | % share of the reward = % share of what’s at risk 24 | 25 | Each contributor’s split is calculated as follows: 26 | 27 | Contributor % of the TFRP = [The adjusted Fair Market Value of your contributions / The Total Adjusted FMV of all contributors] 28 | 29 | The concept of “slices” are used to measure the adjusted Fair Market Value of each contribution. Normalizing hourly rates and cash spend to be denominated in USD and setting 1 slice = 1 USD, we can create an accounting system for quantitatively assigning a number of slices to each contribution and thus an objective measure for value. The more slices you earn prior to the TFRP distribution, the higher your percentage of the TFRP split. 30 | 31 | # Specification 32 | 33 | This design proposes a system for tracking self-reported contributions, that are approved by the chair of each work group. The system should be flexible enough to allow disputes to be raised and settled manually via majority vote of the named chairs. The system can keep most of the metadata off-chain and potentially keep an on-chain total updated for each contributor. 34 | 35 | ## Auth 36 | 37 | EOS + Scatter? Blockchain identity provider is ideal. Keybase is another potential avenue. 38 | ## Data Schema 39 | 40 | ### Contributors 41 | 42 | ### Contributions 43 | 44 | Field Name | Data Type | Description 45 | ---------- | --------- | ----------- 46 | id | (int) | primary identifier 47 | user_id | (string?) | the user that owns the contribution 48 | type | (enum) | (cash, time, commission) 49 | fmv_rate | (double) | the number of slices earned per unit contribution. 50 | hours_spent | (double) | Multiplied with fmv_rate to calculate the total slices earned. Fixed to 1 for cash and commission types. 51 | status | (enum) | (reported, approved, denied, appealed) 52 | contribution_datetime | (timestamp) | When the contribution happened. 53 | 54 | ## API Integrations 55 | 56 | ### Time Reporting 57 | 58 | Use a time tracking integration to Trello to automate reporting of time-based contributions. 59 | 60 | # Open Questions 61 | 62 | 1. When should the TFRP be distributed? 63 | Suggestion: After the Telos network activates. 64 | 65 | 2. What does the approval process for finalizing a contribution look like? 66 | Suggestion: work group chairs to approve. Disputes handled by arbitration forum consisting of all of the chairs. 67 | 68 | 3. What are the appropriate FMVs for each role? And what are the roles? 69 | 70 | 4. What are the appropriate number of slices to award for high-value one-off tasks with a fixed bounty? 71 | 72 | 5. What is the process for requesting one-off high-value tasks that aren’t already accounted for? Who decides the task’s value and if it even needs to be done? 73 | 74 | # Summary for Token Holders 75 | Non-applicable; there are no TLOS token holders yet. 76 | 77 | # Copyright 78 | This document is placed in the public domain. 79 | -------------------------------------------------------------------------------- /tip-0025.md: -------------------------------------------------------------------------------- 1 | TIP: 0025 2 | Title: Contribute unclaimed TCRP funds to free Telos account creation fund 3 | Author: Douglas Horn 4 | Status: Adopted - October 26, 2018 5 | Type: Protocol 6 | Created: 2018-10-18 7 | 8 | # Abstract 9 | 10 | If any funds remain after all claims for the Telos Community Rewards Pool have been distributed, they should be transferred to an account that creates free Telos accounts for new users. 11 | 12 | # Motivation 13 | 14 | Creating free accounts for new users is one of the best uses of available Telos funds, as long as it is not abused. Our promise to create at least 1 million free accounts has met with overwhelming support. 15 | 16 | The Telos Contributors Group has created the Telos Community Reward Pool, a fund of 1 million TLOS to be given away to community members as bounties for expanding the reach of Telos through social media and similar community outreach. The rules of the program explain what will happen if more funds are claimed than actually exist. However, it is more likely that some funds, perhaps a significant amount, will remain unclaimed after all TCRP participants have been paid. As there is no provision for what to do with these funds, this TIP proposes that they be dedicated to an account controlled by the block producers (eosio.prods) that creates free new Telos accounts for new users via teclos or a simple portal on telosfoundation.io or the Telos block explorer. This action would have protections against abuse and would be in addition to other free account efforts promoted by the Telos Foundation. 17 | 18 | # Rationale 19 | 20 | Bringing new users into the Telos system is clearly one of the most beneficial uses for common funds. When the TCRP is fully retired—after all reasonable submissions have been received—there is likely to be a surplus of funds in the TCRP account. Using these funds to allow an additional route for new users to join the Telos chain at no cost is beneficial to both the chain and to the individual users. This can be accomplished in a responsible way that has protections against abuse. 21 | 22 | In this scenario the surplus TCRP funds would be transferred, 15 days after the final submission deadline for the TCRP program to allow ample time for all participants to claim their rewards, to an account for the creation of free accounts. The Telos developers from Goodblock will create a contract that can be accessed from either teclos or a free account portal on the TelosFoundation.io website, that will create exactly one new address for any existing teclos installation address and no free addresses for addresses already created using the freeaccount. This will provide a reasonable protection against abuse. The suggested implementation is to add this feature to the Telos block explorer that Amplified Telos has built, which already has such functionality for the testnet. Along with the previously described command line abuse protections, the block explorer could provide a Captcha-like control and IP filtering to reduce abuse. 23 | 24 | While there may very likely be a benefit to the network from creating ongoing community rewards campaigns, this program currently places a high demand on human resources and no provision has been made for such administration after the launch period. Future programs in this vein would be more appropriate as WPS proposals that include provisions for program administration. This proposal for free accounts is expected to have no administration costs after the initial development. 25 | 26 | This mode of free account generation would be separate from other methods such as a Telos Foundation grant or WPS proposal. Although if this proves popular, more funds could be allocated to the account through either of these methods to continue the program after the initial funds are depleted. 27 | 28 | # Specifications 29 | 30 | 1. Create an account called ‘freetelosact’ controlled by eosio.prods. 31 | 32 | 2. Stipulate that after the completion and payout of Telos Community Rewards, all remaining funds shall be transferred to ‘freetelosact’. 33 | 34 | 3. Develop a smart contract for ‘freetelosact’ with protections against command line (teclos) abuse, but with the provision for privileged portals to access it repeatedly (the official portal). 35 | 36 | 4. Modify the Telos block explorer by Amplified Telos (and also the one from Telos Madrid if feasible) to create free accounts, after limiting abuse potential with protections such as a Captcha, cookies, and/or IP checking. 37 | 38 | # Discussion 39 | 40 | (discussion is closed) 41 | 42 | Debated and Adopted by the Telos Contributors Group October 26, 2018. Voting: Yes - 25, No - 9, Abstain - 3 43 | 44 | # Copyright 45 | 46 | This document is in the public domain. 47 | 48 | -------------------------------------------------------------------------------- /tip-0028.md: -------------------------------------------------------------------------------- 1 | Title: TIP 0028 — Modifying the TLOS token economy 2 | Authors: Amplified Telos (Ian Panchèvre / telos@amplified.software) 3 | Co-sponsors: TelosDAC, BlindBlocArt, TELOS/EOS Sweden, InfinityBloc 4 | Status: Withdrawn October 26, 2018 5 | Type: Protocol 6 | Created: 2018–10–23 7 | 8 | # Abstract 9 | 10 | To ensure a healthy network that is sufficiently capitalized, Amplified Telos proposes the following changes to the TLOS token economy. 11 | 12 | 1) Increase the Telos Founders’ Reward Pool from 6 million TLOS to 12 million TLOS 13 | 14 | 2) Increase funding for the Telos Foundation from 6 million TLOS to 12 million TLOS 15 | 16 | 3) Capitalize the Worker Proposal Fund with 1 million TLOS upon launch 17 | 18 | 4) Set a 1-year expiration date for the unclaimed TLOS in the Exchange Token Reserve Fund 19 | 20 | # Motivation 21 | 22 | It is critical that the various stakeholders and systems that support Telos are appropriately compensated. Otherwise, if Telos is insufficiently capitalized, then it will struggle to grow and retain a robust network. 23 | 24 | # Rationale 25 | 26 | For provision 1, we believe that the Founders Reward Pool ought to double in size for several reasons: (i) the pre-launch period was initially expected to last about two months, and it now appears it will last closer to six months; (ii) initially the launch group intended to include six different contributors, and now there are over one hundred contributors; (iii) doubling the size of the pool will help launch group contributors recover their material investments without unduly jeopardizing the egalitarian nature of the token economy. 27 | 28 | For provision 2, we believe that the Telos Foundation deserves more working capital. In just the past few weeks, we have identified several new responsibilities and expenses that the foundation will have to undertake (e.g., purchasing indemnification coverage for contributing attorneys). With more capital, the Telos Foundation will have a greater chance of surviving a protracted bear market. 29 | 30 | For provision 3, we recognize that the Worker Proposal System is a critical element of the overall Telos Blockchain Network. The WPS finances ongoing engineering, marketing, and business efforts in support of Telos. Unfortunately, the WPS will be broke upon network launch. Capitalizing it with 1 million TLOS will provide approximately 10 weeks worth of capital upfront. 31 | 32 | For provision 4, we want to create a sense of urgency among exchanges and their users to enable support for Telos. We believe that 1 year is sufficient time for exchanges to support Telos. 33 | 34 | # Specification 35 | 36 | By passing TIP 28, we commit to modifying the language in Paragraph 22 of the Telos Blockchain Network Operating Agreement(TBNOA) to read as follows: 37 | 38 | `The initial distribution of TLOS tokens on the Telos network (“Telos Initial Distribution”) will follow the EOS ERC-20 token snapshot as recorded on June 2, 2018 from records of the EOS token sale as recorded on the Ethereum blockchain (the “EOS Snapshot”) on a 1:1 basis. The Telos Initial Distribution will create all accounts that were included on the EOS Snapshot with the same account names and public keys that match except that the prefix “TLOS” may be used instead of “EOS”. These accounts will each be recorded as having the same number of TLOS tokens as the number of EOS on the corresponding account in the EOS Snapshot, except that each account that has a balance of over 40,000 tokens will receive exactly 40,000 TLOS tokens. EOS token holders who provide cryptographically signed messages requesting new keys for their accounts in the publicly documented process shall have their keys changed up until the time of network launch. New Telos accounts will be created to fund the Telos Founders Rewards Pool which will receive 12,000,000 TLOS tokens, the Telos Foundation which will receive 12,000,000 TLOS tokens, the Worker Proposal Fund which will receive 1,000,000 TLOS, and the Telos Community Rewards Pool which will receive 1,000,000 TLOS tokens. Moreover, the Telos Exchange Token Reserve Fund will receive 117,766,908.88 TLOS tokens, which may be distributed to exchanges that enable support for TLOS within one calendar year after the launch of the Telos mainnet. Finally, 25,000 TLOS will be created to provide the initial account creation distribution.` 39 | 40 | Moreover, Telos code and technical work product will be modified to enable the specification set forth in the above paragraph. 41 | 42 | # Discussion 43 | 44 | (Discussion period is open.) 45 | 46 | Amplified removed language concerning the inflation schedule. 47 | 48 | Discussed by Telos Contributors Group and Withdrawn by author October 26, 2018 49 | 50 | # Copyright 51 | 52 | This document is in the public domain. 53 | -------------------------------------------------------------------------------- /tip-0013.md: -------------------------------------------------------------------------------- 1 | TIP: 0013 2 | Title: Lower the maximum airdrop in the Telos Initial Distribution from 40,000 TLOS to 20,000 TLOS per EOS wallet 3 | Authors: Amplified Telos (Ian Panchèvre / telos@amplified.software) 4 | Status: Draft 5 | Type: Protocol 6 | Created: 2018–10–08 7 | 8 | # Abstract 9 | 10 | TIP 13 proposes lowering the cap of airdropped TLOS tokens during the Telos Initial Distribution from 40,000 TLOS to 20,000 TLOS per EOS genesis wallet. 11 | 12 | # Motivation 13 | 14 | It is important to positively engage the EOS community upon launch. Airdropping TLOS to EOS genesis wallets accomplishes that goal. Moreover, capping the maximum number of airdropped tokens allows Telos to activate a more economically egalitarian network and diminishes the power of potentially hostile EOS actors. However, this TIP argues that 40,000 is too high of a cap. 40,000 likely exceeds the optimally sized cap and it enlarges attack surfaces for potentially hostile actors. Telos should consider a cap of 20,000. 15 | 16 | # Rationale 17 | 18 | We recognize the importance of positively engaging the EOS community upon launch. Airdropping TLOS to EOS genesis wallets pays tribute to the parent chain and may encourage EOS community members to learn more about (and even support) Telos. 19 | 20 | Similarly, we recognize the importance of capping the maximum number of airdropped tokens. The extreme inequality of EOS — 1.6% of the addresses control 90% of the tokens — turns off prospective community members and creates governance challenges for the network (i.e., because of EOS’ onchain governance mechanisms, economic inequality translates into political inequality, and thereby undermines the network’s democratic ethos and participatory incentives). 21 | 22 | That said, if the objective is to acknowledge EOS and engage their community, 40,000 tokens seems excessive. Although 40,000 is a mathematically elegant number from the perspective of statistical distribution, it may not be optimal from an economic perspective. An economic rationalist would argue that Telos should pay EOS token holders the maximum number of tokens necessary in order to constructively engage their community, and not any more. Beyond the optimal distribution, Telos earns diminishing marginal returns whereby more tokens result in fewer incremental units of goodwill. Meanwhile, the large pool of tokens in the Initial Distribution will dilute the value of tokens earned by active Telos contributors. 23 | 24 | Moreover, it’s very possible that many of the EOS token holders had split up their addresses prior to the EOS snapshot, and are therefore able to accumulate much more than 40,000 tokens during the Telos Initial Distribution. A subset of these “mini whales” will likely see Telos as a competitive threat and engage in hostile acts. They may, for example, coordinate dumps of TLOS tokens to suppress its price. Or they may keep their tokens and collude with one another to wage hostile political campaigns (by voting for adversarial block producers, for example). 25 | 26 | Given that Telos will likely engender the same amount of goodwill from EOS token holders with an airdrop of 20,000 TLOS as it would with an airdrop of 40,000 TLOS (after all, these are still “free” tokens that were never promised to EOS token holders during the EOS Initial Coin Offering), and given that a smaller cap would reduce the power of potentially hostile EOS “mini whales,” the question that naturally follows is how the reduced cap will affect the overall token distribution. Skeptics may be relieved to learn that the vast majority of EOS addresses will remain unaffected. We reference the research in this article published by the Telos Foundation as well as the EOS genesis snapshot to note the following: 27 | 28 | A 20,000 cap will lower the total amount of tokens in the Initial Distribution from 178,473,249.31 to 149,830,672.87. 29 | The percentage of accounts affected will increase from 0.6631% to 1.2536% — approximately 98.75% of all EOS addresses will not be affected if the cap is lowered to 20,000. 30 | The number of tokens allocated to the Exchange Token Reserve Fund will likely decrease from approximately 140,279,973.96 to 117,766,908.88 (assuming another 78.6% Fibonnaci level). 31 | With a price of approximately $15 per EOS token on June 2, 2018, only addresses that stored an excess of $300,000 worth of EOS at the time of its mainnet launch will be affected by a token cap of 20,000. 32 | 33 | # Specification 34 | 35 | Modify text in paragraph 22 of the Telos Blockchain Network Operating Agreement (TBNOA) to read as follows: 36 | 37 | “These accounts will each be recorded as having the same number of TLOS tokens as the number of EOS on the corresponding account in the EOS Snapshot, except that each account that has a balance of over 20,000 tokens will receive exactly 20,000 TLOS tokens… and the Telos Exchange Reserve Fund which will receive 117,766,908.88 TLOS tokens.” 38 | 39 | # Discussion 40 | 41 | Discussion period is open. 42 | 43 | # Copyright 44 | 45 | This document is in the public domain. 46 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Telos Improvement Proposal 2 | TIP stands for Telos Improvement Proposal. A TIP is a design document 3 | providing information to the Telos community, or describing a new feature for 4 | Telos or its processes or environment. TIPs provide a concise 5 | technical specification of features and a rationale for them. 6 | 7 | The distinct document [TIP Purpose and Guidelines](tip-0001.md) gives a more 8 | detailed explanation. 9 | 10 | # Governance Documents 11 | 12 | Document | Title | Status 13 | -------------------|----------------------------------------------------------|------------------ 14 | [TBNOA](TelosOperatingAgreement.md) | Telos Blockchain Network Operating Agreement | Adopted 15 | [TBNARP](TBNARP.md) | Telos Blockchain Network Arbitration Rules and Procedures | Adopted 16 | [Regproducer](Regproducer.md) | Telos "regproducer" Contract Human Language Terms | Adopted 17 | [BPMinReq](BPMinReq.md) | Block Producer Minimum Requirements | Adopted 18 | [Regarb](Regarb.md) | Telos "regarb" Contract Human Language Terms | Adopted 19 | [ArbMinReq](ArbMinReq.md) | Arbitrator Minimum Requirements | Adopted 20 | [DataProtect](DataProtectionPolicy.md) | Telos Blockchain Network Data Protection Policy | Adopted 21 | 22 | # Available TIPs 23 | 24 | Number | Title | Owner | Type | Status 25 | -------------------|----------------------------------------------------------|-------------------|----------------|-------- 26 | [1](tip-0001.md) | TIP Purpose and Guidelines | Robert Konsdorf | Informational | Draft 27 | [2](tip-0002.md) | A Bounty System for Slicing the Telos Founders Rewards Pool Proportionally Amongst Contributors | Robert Konsdorf | Informational | Adopted 28 | [3](tip-0003.md) | Establishment of common-use snapshots for airgrabs | Jesse Schulman | Informational | Adopted 29 | [4](tip-0004.md) | TIP-4 Premium names and name squatting prevention | Josep Rosich | Protocol | Draft 30 | [5](tip-0005.md) | TIP-5 Single Token Registry Standard | Craig Branscom | Protocol | Adopted 31 | [7](tip-0007.md) | Establishment and Rules of the Telos Community Rewards Pool (formerly TIP-1B) | Douglas Horn | Informational | Adopted 32 | [8](tip-0008.md) | The First Sustainable Blockchain | Sukesh Kumar Tedla | Informational | Draft 33 | [9](tip-0009.md) | Telos “Original” Snapshot Creation | Douglas Horn | Protocol | Adopted 34 | [10](tip-0010.md) | Telos Chain Activation Process | Douglas Horn | Protocol | Adopted 35 | [11](tip-0011.md) | TLOS Token Exchange Reserve | Douglas Horn | Protocol | Adopted 36 | [12](tip-0012.md) | A mechanism for establishing director salaries for the Telos Foundation | Adam Zientarski, Ian Panchevre | Informational | Adopted 37 | [13](tip-0013.md) | Lower the maximum airdrop in the Telos Initial Distribution from 40,000 TLOS to 20,000 TLOS per EOS wallet | Ian Panchevre | Protocol | Defeated 38 | [14](tip-0014.md) | Increase the Telos Founders’ Reward Pool from 6 million TLOS to 25 million TLOS | Ian Panchevre | Protocol | Defeated 39 | [15](tip-0015.md) | Increase funding for the Telos Foundation from 6 million TLOS to 20 million TLOS | Ian Panchevre | Protocol | Defeated 40 | [16](tip-0016.md) | Fund a “give away” contest of 10 million TLOS | Ian Panchevre | Protocol | Defeated 41 | [17](tip-0017.md) | Capitalize the Worker Proposal Fund with 10 million TLOS upon launch | Ian Panchevre | Protocol | Defeated 42 | [18](tip-0018.md) | Frontload the TLOS inflation schedule | Ian Panchevre | Protocol | Defeated 43 | [19](tip-0019.md) | Set a 1-year expiration date for unclaimed TLOS in the Exchange Token Reserve Fund | Ian Panchevre | Protocol | Defeated 44 | [21](tip-0021.md) | ABP Commission | Jerry Huff | Informative | Withdrawn 45 | [22](tip-0022.md) | Initial RAM buy to create accounts | J.T, Jesse, Jerry | Informational | Adopted 46 | [23](tip-0023.md) | Increase block producer inflation on a one year schedule | Douglas Horn | Protocol | Adopted 47 | [24](tip-0024.md) | Adequately Rewarding Telos Contributors | Michael Gucci, MD | Protocol | Adopted 48 | [25](tip-0025.md) | Contribute unclaimed TCRP funds to free Telos account creation fund | Douglas Horn | Protocol | Adopted 49 | [26](tip-0026.md) | TFVT Distribution | Jerry Huff | Protocol | Adopted 50 | [27](tip-0027.md) | Creating RAM reserve for RAM Administration| Jan Smit | Protocol | Adopted 51 | [28](tip-0028.md) | Modifying the TLOS token economy | Ian Panchevre | Protocol | Withdrawn 52 | [29](tip-0029.md) | Impose a cap on the TFRP rewards paid to any one contributor group | Azad Halim | Protocol | Withdrawn 53 | [30](tip-0030.md) | EOS genesis snapshot on-chain | Viterbo Rodríguez | Protocol | Draft 54 | [31](tip-0031.md) | Community Rewards Account Creation | Jerry Huff | Informational | Draft 55 | [32](tip-0032.md) | Vesting Schedule for Telos Foundation Rewards Pool Tokens | Adam Zientarski, Rob Konsdorf | Protocol | Defeated 56 | [33](tip-0033.md) | Voting Restrictions on Telos Foundation Rewards Pool Tokens | Adam Zientarski, Rob Konsdorf | Protocol | Withdrawn 57 | [34](tip-0034.md) | Sentiment Token Standard | Douglas Horn | Protocol | Draft 58 | -------------------------------------------------------------------------------- /tip-0030.md: -------------------------------------------------------------------------------- 1 | TIP: 0030 2 | Title: EOS genesis snapshot on-chain 3 | Authors: Viterbo Rodríguez 4 | Status: Draft 5 | Type: Protocol 6 | Created: 2018-10-27 7 | Discussion: 8 | 9 | # Abstract 10 | This TIP proposes that the Telos Foundation should create a smart contract (which I am going to refer to as **eossnapshot**) and then load the EOS genesis snapshot once and for all. This eossnapshot contract then should provide services to query information for a specific account. That service may be used to perform futures airdrops (based on the snapshot information) without incurring in resource costs (RAM and bandwidth). 11 | 12 | # Motivation 13 | I plan to deploy more than one token on the blockchain and I will perform an airdrop for each one. The problem I face is that I will have to pay for the airdrop resources usage several times (once for each token). This proposal delegates that cost to the Telos Foundation, who will pay for it just once and then serve it for free to all new Tokens. 14 | 15 | # Rational 16 | Although it is not mandatory to perform an airdrop, most of the new Tokens on Telos will do so and that means a significant expense for those who perform this task. 17 | 18 | One solution that is already being handled is to wait for each user to "register" and thus pay the cost of using the RAM, but this is a problem since it means to wait from every user to take action. 19 | 20 | If the Telos Foundation takes care of the RAM costs of storing the EOS snapshot data as an immutable balance token on-chain, that info can be used in order to resolve the balance of any unregistered account but includding the its airdrop balance. 21 | 22 | This will be another great argument when talking about how developer-friendly the TELOS blockchain is. Plus the cost of implementing this solution will be paid once by Telos Foundation and will be usefull for everyone (not only airdrops). 23 | 24 | # Specifications 25 | 26 | ## EOS Snapshot Smart Contract 27 | The following pseudo code is an abstract proposal for the eossnapshot smart contract that will implement the eosio.token api parcially. The whole idea is to replicate the snapshot that currently exist on Ethereum blockchian as EOS ERC20 Token and load it on a token-like smart contract on the TELOS blockchian. This way everyone may get everybody's balances like in any other token. This information may be used from real new Tokens to perform an airdrop without actually storing anything on memory, **reducing RAM costs to zero**. 28 | 29 | CONTRACT eossnapshot : public contract { 30 | public: 31 | // hardcoded issuer should be "eossnapshot" 32 | // hardcoded max_supply should be "1000000000.0000 GENESIS" 33 | ACTION create(); 34 | 35 | // should be called once for every account in the snapshot 36 | ACTION issue(name to, asset quantity, string memo ); 37 | 38 | // this token is inmutable. So, there's no transfer 39 | // NO_ACTION transfer(name from, name to, asset quantity, string memo); 40 | 41 | static asset get_supply(); 42 | 43 | static asset get_balance(name owner); 44 | 45 | private: 46 | TABLE account { 47 | asset balance; 48 | uint64_t primary_key() const { return balance.symbol.code().raw(); } 49 | }; 50 | 51 | TABLE currency_stats { 52 | asset supply; 53 | asset max_supply; 54 | name issuer; 55 | uint64_t primary_key() const { return supply.symbol.code().raw(); } 56 | }; 57 | 58 | typedef eosio::multi_index< "accounts"_n, account > accounts; 59 | typedef eosio::multi_index< "stat"_n, currency_stats > stats; // should have only one row globally 60 | }; 61 | 62 | ## Token with Airdrop Smart Contract 63 | 64 | Let's say I want to create a **NEW** token with a maximum supply of "500000000.0000 NEW" (500 Million NEW tokens). I also want to perform an airdrop (with ratio 1:2) but I want to cap every airdrop at (let's say) 50K and more important, without any RAM cost. 65 | 66 | Immediately after the token smart contract is created, its tables will be empty. But if I ask for any account's balance, the answer should be the airdrop instead of zero. To achieve this, the get_balance function should query the account's balance from the eossnapshot contract, and (in this example) divide it by 2 and finally capping it at 50K. This way each Token can implement the airdrop with any complex logic. 67 | 68 | At some point the people will use their NEW Tokens and transfer them to some other account. In this moment is when the actual airdrop take place because we can charge the user as the RAM payer (for both, sender and receiver RAM usage). That means that the first transfer of all accounts will trigger the actual airdrop and store the final sender's balance and the receiver's balance *. 69 | 70 | account | final balance 71 | ----------|--------------- 72 | sender | sender's airdrop minus transfer 73 | receiver | receiver's airdrop plus transfer 74 | 75 | * if the receiver has already paid for his or her RAM, the sender will not be charged. 76 | 77 | # Discussion 78 | ... 79 | 80 | # Summary for Token Holders 81 | This TIP proposes to delegate to Telos Foundation the responsability of keeping abailable for everyone the EOS snapshot data. This way the aidrops will cost much less and potencialy atract developers to TELOS blockchain. 82 | 83 | # Copyright 84 | N/A 85 | 86 | # See Also 87 | ... 88 | -------------------------------------------------------------------------------- /tip-0008.md: -------------------------------------------------------------------------------- 1 | TIP: 0008 2 | Title: The First Sustainable Blockchain 3 | Authors: Sukesh Kumar Tedla, sukeshtedla@telosgreen.com 4 | Status: Draft 5 | Type: Informational 6 | Created: 2018-09-01 7 | Discussion: TIP channel in slack 8 | 9 | # Abstract 10 | 11 | This proposal outlines a plan to make Telos-The First Sustainable Blockchain in the market. Based on research it's estimated that bitcoin network alone consumes 1% of total power consumption in the world which is quite huge and it's just waste of energy, bad to the environment. It's important to think about the impacts of our actions on society, nature and future generation. During this year the world has seen the rise in temperatures like they have never seen before. Though a long summer seems to be nice but we have to realise that increase in temperatures have a drastic effort on the environment. 12 | 13 | # Motivation 14 | 15 | We all agree that blockchain is a great innovative technology of the current generation and it's here to stay. But we have to at some point in time realize, what price we are paying for this technology. The POW blockchains have proven to be de-centralised, secure but at the same time they are not efficient [1]. When it comes POS and DPOS blockchains we still have a certain level of decentralization and better efficiency but as they scale they can become un-sustainable as well. EOS have proven to be better when compared to other blockchains but it still have its own issues to address. 16 | As Telos is driving towards a more decentralised blockchain and addressing the concerns of EOS, it has already started the work in the direction of becoming the top-notch blockchain in the market. This proposal will hopefully take it to the next level and make Telos-The first sustainable blockchain in the world. 17 | 18 | # Rational 19 | 20 | We have BP requirements in Telos and we are on a path to do something great. So this proposal puts some additional requirements on BPs and Telos Network to address the Sustainable Development Goals put forth by the United Nations. If we adapt this proposal and live by its standards, it can attract the real industries and applications to use Telos. The organisations, applications can get an extra accreditation for working towards SDGs and using Telos infrastructure. 21 | 22 | # Specifications 23 | 24 | List of Green Energy Sources: http://listverse.com/2009/05/01/top-10-renewable-energy-sources/ 25 | It’s divided into 2 sections: 26 | 1) BP – Requirements: All the BPs of Telos network are required to use Green energy before we reach 1 year from the mainnet activation date. If there are no sources for Green energy usage in the regions where BPs are located they can suffice by buying green offsets. 27 | 2) Telos Blockchain Network – Worker Proposal System: We have a worker proposal fund which is funded by the inflation of Telos tokens. As they say “actions speak better than words” It would be great if 0.25% of WPS fund goes to the UN for working towards Sustainable Development Goals. By doing this it will not only benefit Telos but also the whole planet. And Good Karma for everyone. 28 | 29 | # Actions to be taken 30 | 31 | 1) To address BP requirements: We need to add additional points to the BP requirements document. This has to be further approved and accepted by 2/3rd of the BPs. 32 | 2) Regarding SDG fund: First we have to reach out to UN - SDG team and setup an account for them and make modifications to the worker proposal system code to send tokens every 3 months. 33 | 34 | # Auditability & Verification 35 | 36 | 1) Using a smart contract or by just creating a transaction on the chain all BPs will need to submit the proof of using green energy every 3 months. And once published all the other BPs can verify each other proofs and if they find any issues they can reach out to the BP. If the issue still persists, they can call for a vote to penalise. The penality would be a ban for 90 days for first warning and for second warning the penality would be 1 year. 37 | 38 | 2) When it comes to transferring the funds to UN or similar entities, these organisations will be subject to show the proof of how funds are used. Here this can be also done under the supervision of Telos Foundation Board Members. 39 | 40 | # Stats 41 | 42 | The current power consumption stats from EOS mainnet, as of date[26/08/18]: 43 | 74 paid BPs * Rio norm 1,8KW *24 hours = 3196 kWh /day =0,0032 million kWh /day 44 | Ethereum Consumption: 45 | https://digiconomist.net/ethereum-energy-consumption 46 | 47 | # Frequently Asked Questions 48 | 49 | Q) What are green energy sources? 50 | A: Here is a list: http://listverse.com/2009/05/01/top-10-renewable-energy-sources/ 51 | Q) What if BPs didn't find any green energy data centres? 52 | A: In majority of the countries there are certified green data centres, if it's impossible to find one then a BP can buy Carbon offsets and show it's proof. The goal is to empower Sustainability. 53 | Q) What are Carbon Offsets? 54 | A: Here is a good link: https://science.howstuffworks.com/environmental/green-science/carbon-offset.htm 55 | Q) Do you think it will be too much work for a BP? 56 | A: Not in long term. But probably in the beginning. 57 | Q) Why do we need to do this? Telos is not too much power consuming? 58 | A: Yes, Telos is not consuming too much power but the goal here is to empower society. This will also bring businesses towards using Telos. 59 | 60 | # References 61 | 62 | [1] https://www.ofnumbers.com/2018/08/26/how-much-electricity-is-consumed-by-bitcoin-bitcoin-cash-ethereum-litecoin-and-monero/ 63 | -------------------------------------------------------------------------------- /tip-0023.md: -------------------------------------------------------------------------------- 1 | TIP: 0023 2 | Title: Increase block producer inflation on a one year schedule 3 | Author: Douglas Horn, Goodblock 4 | Status: Adopted 5 | Type: Protocol 6 | Created: 2018-10-16 7 | Adopted: 2018-10-23 8 | 9 | # Abstract 10 | 11 | A one-year, fixed schedule of increased block production rewards of 4% for months 1-4, 3% for months 5-8, and 2% for months 9-12 should be implemented to better ensure sustainability for block producers at the beginning of the network until suitable TLOS price discovery and network maturity can establish a stable price. 12 | 13 | # Motivation 14 | 15 | The existence of the Telos Blockchain Network depends on the ability of block producers to operate their infrastructure and staffing requirements profitably. There is a high likelihood that the initial months of operation will find the amount of tokens Telos block producers earn at the specified 1% inflation will not be sufficient to meet this need. Should this happen, block producers will have to decide whether to produce blocks at a loss to keep the network alive, or follow their profit motive. It is crucial that the network keep block production profitable so that high caliber block producers will be enticed to support the network. 16 | 17 | # Rationale 18 | 19 | The Telos blockchain is maintained by up to 51 block producers and standby block producers and the health of the network depends on their being able to operate profitably. The market price of TLOS is unknown at launch and a low price could threaten the ability to maintain sustainable operations of block producers. With a token supply of about one-third that of EOS, Telos block producers are already earning 1% inflation based on a smaller token supply. While it is expected that in time the network value should equalize toward the additional network resources value of each TLOS token compared to EOS tokens, during the first year of the network, it is likely that TLOS tokens will have a market price well below their actual relative value. Of note, Telos block producers must meet minimum requirements higher than what is required of EOS block producers including participation in multiple networks. 20 | 21 | During this crucial nascence of the network, it is important that block producers not fall into a trap of producing blocks at a loss. The result would be a shortage of high caliber block producers, which poses a threat to the network. 22 | 23 | A conservative estimate for the break-even cost for operating a block producer is US $15,000-20,000 per month. This may be higher in some regions due to operating costs. As of this writing, top 21 EOS block producers earn an average of US $125,616 per month in gross revenues from block producing (average of 753.1 EOS per day X US $5.56 per EOS.) At 1% annual inflation, Telos block producers will earn approximately 7,700 TLOS per day for a block producer and 3,850 for a standby. For a Telos block producer to match what an average EOS block producer earns in one month, TLOS would have to be priced at about US $16.31. For a Telos block producer to earn the anticipated monthly operational cost of US $15,000-20,000, TLOS would have to be priced at US $1.95-$2.60 (at 1% annual inflation). While there is no necessity for Telos block producers to match the income of EOS block producers performing the same function, it is necessary for them to be able to break even in their operational costs. 24 | 25 | No one knows what the initial price of TLOS tokens are likely to be, but it is probable that they may initially be much closer to US $0.50 (approx 0.1 EOS) than to $2.50 (approx 0.5 EOS). This is particularly true at the outset of trading. While this low price may present an excellent opportunity for investors, block producers will need to pay their costs regularly. 26 | 27 | Providing a schedule of increased inflation that ramps down over a predictable timeline will support block producers and keep their income closer to their anticipated costs throughout the first year of operations. 28 | 29 | Month | Inflation Rate | Monthly BP Income | TLOS Price to Breakeven 30 | ------|-----------------|-------------------|------------------------ 31 | 1-4 | 4% | 30,750 TLOS | US $0.49-0.65 32 | 5-8 | 3% | 24,950 TLOS | US $0.60-0.80 33 | 9-12 | 2% | 17,900 TLOS |US $0.84-1.12 34 | 13+ | 1% | 9,600 TLOS |US $1.56-2.08 35 | 36 | (Note, money supply grows at 2.5% annually) 37 | 38 | This inflation schedule is limited to one year and decreases at a regular rate toward the eventual rate of 1% for block producers. It is a limited response that allows block producers to operate at a price that is in line with reasonable expectations about TLOS market prices. 39 | 40 | # Specifications 41 | 42 | The Telos Blockchain Network Operating Agreement (TBNOA), Clause 10, “Block Producer Pay” shall be amended to read as follows: 43 | 44 | `Block Producer and Standby Block Producers shall be paid each day from a daily fund consisting of the daily share of 1% annual inflation (the “BP Inflation Rate”) of the entire value of the Telos blockchain as measured in TLOS tokens. Every day, this total amount shall be allocated such that each Block Producer receives the same pay for the time spent as a Block Producer as every other Block Producer and each Standby receives pay that is half of the rate of each Block Producer for its time spent as a Standby, with the provision that Block Producers and Standby Block Producers may have their daily pay allotment deducted in proportion with the percentage of blocks they were expected to produce in their most recent production period of 180,000 blocks (approximately 24 hours) or fewer, but failed to produce. Loss of pay from failing to regularly execute the “claimrewards” action, shall be borne by the Block Producer or Standby Block Producer, not the network. For blocks 1,000,001 (activation) through 22,000,000 blocks (approximately 122 days), the BP Inflation Rate shall be equivalent of 4% annually instead of 1%. For blocks 22,000,001 through 43,000,000 blocks (approximately 122 days), the BP Inflation Rate shall be equivalent of 3% annually instead of 1%. For blocks 43,000,001 through 64,000,000 blocks (approximately 122 days), the BP Inflation Rate shall be equivalent of 2% annually instead of 1%.` 45 | 46 | # Discussion 47 | 48 | (discussion is closed) 49 | 50 | Adopted by the Telos Contributors Group 2018-10-23. Voting: Yes - 28, No - 3, Abstain - 6 51 | 52 | # Copyright 53 | 54 | This document is in the public domain. 55 | -------------------------------------------------------------------------------- /tip-0005.md: -------------------------------------------------------------------------------- 1 | TIP: 0005 2 | Title: TIP-5 Single Token Registry Standard 3 | Authors: Stephen Craig Branscom 4 | Status: Draft 5 | Type: Protocol 6 | Created: 2018-08-01 7 | Adopted: 2018-10-30 Voting - Yes: 39, No: 0, Abstain: 0 8 | 9 | # Abstract 10 | 11 | This proposal outlines a plan to standardize Token Registries across the Telos Network, as well as define a common interface for use by third parties. 12 | 13 | # Motivation 14 | 15 | As the Telos Network grows, standardized communication interfaces will become necessary in order to allow complex token transactions. Declaring a network-wide standard will allow any tokens developed on Telos to be reused by other applications and services. 16 | 17 | # Rationale 18 | 19 | In the Telos Network, a token or groups of tokens are collectively tracked and managed by a single contract, which will henceforth be known as a Token Registry. Due to the free nature of the network, anyone can write their own Token Registry, which will likely result in a multitude of different interfaces across the network. 20 | 21 | # Specification 22 | 23 | The TIP-5 Single Token Registry Standard defines an interface that allows third-party support for token contracts that implement a single token. The interface is defined as follows: 24 | 25 | ### Tables 26 | 27 | The following tables store information such as token balances, allotments, and global token settings. 28 | 29 | * `typedef multi_index< N(balances), balance> balances_table` 30 | 31 | The balances table will hold all accounts and their respective token balances. The table is indexed by account_name. 32 | 33 | * `typedef multi_index< N(allotments), allotment> allotments_table` 34 | 35 | The allotments table holds all approved account allotments, indexed by the token owner's account_name. 36 | 37 | * `typedef eosio::singleton settings_singleton` 38 | 39 | The settings singleton holds all token related information such as max supply, circulating supply, and a human-readable name. 40 | 41 | ### Structs 42 | 43 | The following structs and their members are stored in tables and referenced by their primary keys. 44 | 45 | * `setting` 46 | 47 | **Issuer** refers to the account authorized to mint new tokens. 48 | 49 | **Max Supply** holds the maximum supply of tokens to be allowed in circulation. 50 | 51 | **Supply** stores the total tokens currently in circulation. 52 | 53 | **Name** holds the human-readable name of the token. 54 | 55 | * `balance` 56 | 57 | **Owner** refers to the account that owns the tokens. 58 | 59 | **Tokens** holds the balance of tokens owned by the owner. 60 | 61 | * `allotment` 62 | 63 | **Recipient** refers to the account that has the authority to withdraw from the tokens field. 64 | 65 | **Sender** refers to the account that sent the tokens that have been allotted. 66 | 67 | **Tokens** holds the allotment to be withdrawn by the recipient. 68 | 69 | ### ABI Actions 70 | 71 | The following function signatures define how users can interact with the token contract. 72 | 73 | * `void mint(account_name recipient, asset tokens)` 74 | 75 | Mints new tokens into the circulating supply and sends them to the recipient. Only the account publishing the contract has the authority to mint new tokens. 76 | 77 | * `void transfer(account_name sender, account_name recipient, asset tokens)` 78 | 79 | Transfers tokens from the sender account to the recipient account. 80 | 81 | * `void allot(account_name sender, account_name recipient, asset tokens)` 82 | 83 | Allows recipient to withdraw from the sender account, multiple times, up to the value of tokens. Subsequent allotments called by the same owner to the same recipient are added together. 84 | 85 | * `void unallot(account_name sender, account_name recipient, asset tokens)` 86 | 87 | Reverses an allotment of tokens back into the sender's balance, up to the amount of tokens still remaining in the allotment. 88 | 89 | * `void claim(account_name sender, account_name recipient, asset tokens)` 90 | 91 | Claims tokens from an allotment to the recipient account, up to the amount alloted by the sender. 92 | 93 | * `void createwallet(account_name recipient)` 94 | 95 | Creates a zero balance entry in the balances table for the recipient. Users should call this action first to create a balance entry for holding their future tokens. This will consume a small amount of RAM, which can be reclaimed should the user ever choose to delete their balance entry. 96 | 97 | * `void deletewallet(account_name recipient)` 98 | 99 | Deletes an entry in the balances table for the recipient. Ensure the entry has a balance of zero, otherwise tokens will be deleted. 100 | 101 | # Discussion 102 | 103 | * Q: Why do users need to call the createwallet() action before receiving tokens? 104 | 105 | A: In short, it has to do with ram consumption. In order to store a balance of tokens, a certain amount of ram must be allocated to save that information. By calling createwallet(), a user is reserving this storage space up front for their own use. This ram will be reclaimed later when the user chooses to delete their wallet. 106 | 107 | * Q: Does this interface only work for single token contracts? 108 | 109 | A: Yes. A forthcoming Multi Token Registry Standard will declare an interface for interacting with contracts that implement more than one token on a single contract. 110 | 111 | * Q: What's the purpose of an allotment? 112 | 113 | A: Allotments can be thought of as a deferred payment. Any user can make an allotment to any other user, even if the recipient doesn't have an existing wallet on that contract (they will, however,need a wallet when they go to claim the allotment). The recipient can then claim their allotment whenever they want, even a few tokens at a time, until either the account that made the allotment unallots the remaining tokens, or the allotment is fully claimed by the recipient. Only the intended recipient can withdraw from an allotment, and unclaimed tokens can be reclaimed by the allotter at any time. 114 | 115 | * Q: Why can't a user delete their wallet until it has zero tokens? 116 | 117 | A: Deleting a wallet that still retains a token balance would effectively burn those tokens from circulation. 118 | 119 | # Summary for Shareholders 120 | 121 | The changes suggested in this TIP will declare a standard for developing token contracts. This will pave the way for contract integration with exchanges and other third-party developers. 122 | 123 | # Copyright 124 | 125 | Open Source under MIT License. 126 | -------------------------------------------------------------------------------- /tip-0016.md: -------------------------------------------------------------------------------- 1 | TIP: 0016 2 | Title: Fund a “give away” contest of 10 million TLOS 3 | Authors: Amplified Telos (Ian Panchèvre / telos@amplified.software) 4 | Status: Declined 5 | Type: Protocol 6 | Created: 2018–10–08 7 | 8 | # Abstract 9 | 10 | TIP 16 proposes the creation of a “giveaway” contest of 10 million TLOS, which will be randomly distributed to contest participants for free. 11 | 12 | # Motivation 13 | 14 | Telos should use its capital to introduce itself to the broader blockchain/cryptocurrency ecosystem, show off its technology to a large audience, and attract new community members. 15 | 16 | # Rationale 17 | 18 | Although Telos will NOT sell tokens prior to network launch (i.e., ICO), Telos can give away tokens for free. If properly structured, a “giveaway” contest could attract hundreds of thousands of new community members. Moreover, the giveaway rewards could be relatively egalitarian, such that the contest avoids the creation of many losers and prevents the formation of small whales among the winners. 19 | 20 | To provide further detail: 21 | 22 | Upon network activation, 10 million TLOS will be initialized in a “giveaway jackpot” smart contract. The giveaway jackpot contract will serve as a reserve that holds the 10 million tokens indefinitely. Once the active Telos block producers are satisfied with all web infrastructure necessary to administer a successful decentralized contest, they will vote to move the funds from the jackpot contract to the contest contract, thereby launching the contest. 23 | 24 | 5 million TLOS will be given immediately to individuals when they register for the contest (see schedule below). Accordingly, the giveaway will reward people for registering quickly. 25 | 26 | 5 million TLOS will be given randomly, in various increments, to the contest winners at the conclusion of the contest (see schedule below). Accordingly, the giveaway will promise big payouts for select winners, resembling a lottery of sorts. 27 | 28 | The giveaway is NOT an ICO nor a lottery. Participants won’t be asked to send any form of payment (cryptocurrency or otherwise) in order to participate. 29 | 30 | The giveaway is NOT an airdrop. Participants don’t need to already own cryptocurrency in a registered address in order to participate. 31 | Any person may participate in the giveaway by visiting a website and registering before a clearly marked deadline. The registration process will involve submitting basic information (full name and email), verifying one’s identity (through a third-party digital identity provider, such as Civic), and provisioning/linking a Telos wallet. 32 | 33 | Identities will be independently verified to ensure that each person participates once. We want to prevent people from entering the contest multiple times for themselves. Additionally, by collecting emails from registered users, the Telos Foundation will be able to send marketing and informational activity to all participants (so long as they don’t opt-out of receiving these emails). 34 | 35 | Community members may submit worker proposals for building an informational website, a giveaway contest contract, and a web application for user interaction (e.g., an informative landing page, the onchain contract to administer the contest, a portal for registering for the contest, a notification system for winners, integration with a TLOS wallet, etc.). 36 | 37 | Once contest infrastructure is complete, block producers will review and debug the submitted work product. The block producers will note their satisfaction with the submitted items when at least 2/3s + 1 of the active BPs vote in favor of releasing the funds from the “giveaway jackpot” contract to the “giveaway contest” contract that will then execute the contest. 38 | 39 | Once the 77,000th person registers for the giveaway, the contest contract will begin a 1-week countdown. During this 1-week window, new participants may register (although they will not earn TLOS tokens upon registration). The contest will stop accepting further participants the moment the countdown expires. Concurrently, the contest contract will administer onchain computations and allocate TLOS to the addresses of all the contest winners. The giveaway web application will also notify participants of their outcome. 40 | 41 | OR (replacing the previous paragraph): The contest will cap the number of registered participants to 100,000. Once the 100,000th participant registers, the contest will stop accepting further participants and will set a countdown for one hour. Once the one hour elapses, the contest contract will administer onchain computations and allocate TLOS to the addresses of all the contest winners. The giveaway web application will also notify participants of their outcome. 42 | 43 | If a team never submits acceptable contest infrastructure, then the funds in the giveaway jackpot will remain locked. Block producers could vote at any time to burn the tokens, thereby removing them from circulation and terminating the contest before it begins. 44 | 45 | If the funds are somehow “hacked” out of the jackpot or the contest contracts, block producers can immediately move to freeze and return the funds, thereby censoring the thieves. 46 | 47 | To incentivize participants to quickly register, the giveaway contest will distribute 5 million TLOS tokens to the first 77,000 registered participants according to the following schedule: 48 | 49 | ## Giveaway contest token distribution upon registration 50 | 51 | Order of Registered Participants | Total Participants | TLOS Reward | Total 52 | ----------------------------------|--------------------|-------------|------- 53 | 1 - 2,000 | 2,000 | 500 | 1,000,000 | 54 | 2,001 - 7,000 | 5,000 | 200 | 1,000,000 | 55 | 7,001 - 17,000 | 10,000 | 100 | 1,000,000 | 56 | 17,001 - 37,000 | 20,000 | 50 | 1,000,000 | 57 | 37,001 - 77,000 | 40,000 | 25 | 1,000,000 | 58 | TOTAL | 77,000 | - | 5,000,000 | 59 | 60 | 61 | When the giveaway contest contract pays out 5 million tokens to random winners, it may do so according to this schedule: 62 | 63 | ## Giveaway prize schedule 64 | 65 | Number of Winners | Reward | Total 66 | --------------|-------------|------------- 67 | 20,000 | 50 | 1,000,000 | 68 | 10,000 | 100 | 1,000,000 | 69 | 1,000 | 1,000 | 1,000,000 | 70 | 100 | 10,000 | 1,000,000 | 71 | 40 | 25,000 | 1,000,000 | 72 | 31,140 | - | 77,000 | 73 | 74 | Note that the vast majority of all participants will likely earn TLOS during registration. Nearly 1/3 of all participants will earn additional tokens during the lottery. 75 | 76 | # Specification 77 | 78 | TIP 16 requests that new language be added to paragraph 22 of the Telos Blockchain Network Operating Agreement (TBNOA): 79 | 80 | “Additionally, 10,000,000 million TLOS will fund a ‘giveaway jackpot’ for a contest to be administered at a later date as determined by the active block producers.” 81 | 82 | # Discussion 83 | 84 | (Discussion period is closed.) Voted by Telos Contributors Group 2018-10-23. Voting: Yes - 0, No - 30, Abstain - 0 85 | 86 | # Copyright 87 | 88 | This document is in the public domain. 89 | -------------------------------------------------------------------------------- /tip-0027.md: -------------------------------------------------------------------------------- 1 | TIP: 0027 2 | Title: A controlled RAM launch on Telos 3 | Author: Jan Smit, Interim RAM Administration Director 4 | Status: Draft 5 | Type: Protocol 6 | Created: 2018-10-29 7 | 8 | # Abstract 9 | 10 | This tip proposes that the RAM Administration: 11 | 12 | 1) Before launch: Buys or receives such amount of RAM (~5.2GB) that at launch 50% of RAM is reserved 13 | 2) During hours and days after launch: Sells 4.1GB of RAM slightly above the PGP (Public Guidance Price) to firmly support the PGP 14 | 3) Maintains an initial RAM reserve of ~10% of all system RAM ( ~1.1GB) 15 | 16 | # Motivation 17 | 18 | The RAM Administration has 3 instruments to influence the RAM price long term. These are described in the “RAM Administration Position Paper” on Telos Logical. 19 | 20 | 1) Publish a Public Guidance Price (PGP) for RAM every 10 Million blocks (approximately 58 days) 21 | 2) Call adhoc RAM meetings to increase RAM supply (setram). The automatic RAM growth rate (setramrate) will be set to 0 initially. 22 | 3) Trade RAM on the basis of a RAM reserve 23 | 24 | These 3 instruments will however not avoid the heavy speculation which happened during the launch of EOS and is likely to happen again on Telos in the first hours and days after launch. This is caused by the Bancor RAM pricing mechanism (see graph 2 below) which establishes the RAM price solely on the percentage of RAM reserved until RAM is added (if RAM is added the curve effectively drops). This model makes RAM therefore relatively cheap for those speculators who get to buy first. Table 1 below shows the profits for early RAM buyers assuming they sell at the price corresponding with a 50% RAM reserved situation. During the EOS launch RAM prices and therefore profits went significantly higher as 80% RAM reserved was reached when genuine DApp buyers started to buy after the speculators had purchased the cheapest tranches. 25 | 26 | As RAM speculators have developed sophisticated algorithms to trade and buy the first tranches of EOS RAM, the Telos RAM Administration is, without this TIP, also at risk of not being able to buy its RAM reserve (~10% of available RAM) at a competitive price. This reduces the effectiveness of the 3rd instrument mentioned above and will effectively result in an unnecessary transfer of wealth from the RAM Administration to the early speculators. 27 | 28 | The above measures allow the RAM administration to set a PGP before launch (e.g. corresponding with a RAM reserved situation between 50 and 55%) and maintain this PGP as it has sufficient RAM to sell if RAM demand causes the RAM price to exceed the PGP by more than a certain margin. It makes it impossible for speculators to buy the cheapest tranches and it also sends a clear message that Telos’ objective is to create a stable RAM price environment conducive to DApps. Finally, we propose that the profits of selling the RAM will be used to provide RAM grants to DApps. 29 | 30 | # Rationale 31 | 32 | The reason the RAM Administration suggests to launch the Telos chain with 50% of RAM reserved is that during the last 2 months the RAM prices at EOS Mainnet have reached a fairly constant level of ~0.1 EOS per kB (see graph 1). This price level corresponds with around 55 to 60% of RAM being reserved (see shaded area in graph 2). 33 | 34 | Graph 1: EOS RAM price over time 35 | ![alt text](https://github.com/TallJanSmit/tips/blob/JanSmit-TIP-27-v2/EOS_RAM_price.png) 36 | 37 | As ~0.8 GB will be staked in the creation of the genesis accounts and as the chain will launch with 12GB of RAM, this means that this TIP proposed to allocate 5,2 GB of RAM before launch to the RAM Administration. The RAM Administration will sell most of this RAM in the hours and days after launch to the Bancor contract when the RAM price exceeds the PGP by a certain margin. 38 | 39 | Graph 2: Telos RAM price as a function of percentage of RAM reserved 40 | ![alt text](https://github.com/TallJanSmit/tips/blob/JanSmit-TIP-27-v2/TLOS_RAM_price.png) 41 | 42 | The RAM administration will retain some RAM (order of magnitude 10% of all RAM) as a reserve to discourage speculation in the future. The purchase cost for 5,2 GB is ~320k TLOS. Below table breaks down this purchase in 8 tranches purchased each with 40k TLOS. For each tranch the table below shows the RAM size purchased, the purchase price and profits assuming the tranch was sold at the Purchase Price of the last and most expensive tranch. 43 | 44 | Table 1: Potential profit per tranch 45 | ![alt text](https://github.com/TallJanSmit/tips/blob/JanSmit-TIP-27-v2/RAM_profits.png) 46 | 47 | Selling the RAM of tranches 3 to 9 (i.e. excluding the first 1.1 GB tranch which we propose to reserve for future trading) will cause a profit of ~160k TLOS. The RAM Administration proposes to use this profit to support DApps through RAM grants. 48 | 49 | Once most tranches are sold and the RAM Director is of the view that the RAM price is still too high, he/she will resort to the instruments mentioned above. 50 | 51 | With regard to the Telos RAM price, you can see in graph 2 above that at the 50% level the RAM price is around ~0.1 TLOS per kB (the same level as EOS today). However assuming the TLOS-USD rate will be well below the EOS-USD rate, the Telos RAM price will be well below the EOS RAM price in USD terms. Future RAM increases will reduce the RAM price expressed in TLOS (or EOS) as it moves the price curve, shown above, down . At comparable market cap of TLOS and EOS (note that this requires TLOS price to be ~3x the EOS price as EOS has 3x the token supply), at same amount of RAM (max_ram_size) and at a comparable percentage RAM reserved the RAM prices in USD will be similar for both chains. 52 | 53 | # Security on RAM Administration accounts 54 | 55 | The following risks, amongst others, need to be prevented: 56 | 57 | - $5 Wrench attacks (incl extortion) on the RAM Administration 58 | - Hacking of smart contracts which may be used by RAM Administration to trade RAM 59 | - Fraud 60 | 61 | To limit hacking risks we propose to compartmentalise RAM from the start (as it can not be transferred between accounts). We propose the RAM and 1,000 TLOS (for CPU and Bandwidth) are spread equally over 8 accounts. Each account will then hold a market value of approximately 85k TLOS each (=(320k purchase price +240k profit)/8)). Each account will be a multisig account involving TF directors, board members and potentially trusted 3rd parties (e.g. notary). The latter group shouldn’t have sufficient keys to enable transactions independently. 62 | 63 | # Specifications 64 | 65 | The Telos Blockchain Network Operating Agreement (TBNOA), Clause 22, “Initial Token Allocation” shall be amended to read as follows: 66 | 67 | New Telos accounts will be created to fund the Telos Foundation which will receive 6,000,000 TLOS tokens`, the Telos Foundation RAM Administration which will receive 5.2GB of RAM (or such amount of RAM which will bring the total reserved RAM amount at 50% at launch) and 1,000 TLOS, which is the equivalent of approximately 321,000 TLOS tokens`, the Telos Founders’ Rewards Pool which will receive 6,000,000 TLOS tokens, the Telos Community Rewards Pool which will receive 1,000,000 TLOS tokens, and the Telos Exchange Token Reserve Fund which will receive 140,279,973 TLOS tokens. 68 | 69 | # Discussion 70 | (discussion is open) 71 | 72 | # Copyright 73 | This document is in the public domain. 74 | -------------------------------------------------------------------------------- /tip-0034.md: -------------------------------------------------------------------------------- 1 | TIP: 0034 2 | Title: TIP-34 Sentiment Token Standard 3 | Authors: Douglas Horn 4 | Status: Draft 5 | Type: Protocol 6 | Created: 2019-03-10 7 | 8 | 9 | # Abstract 10 | 11 | The following standard describes a novel token implementation of a standard API for tokens within smart contracts. This standard provides basic functionality to issue tokens and transfer them under the control of the issuer, not the third-party account where they are recorded. 12 | 13 | Sentiment tokens are more fully described in the paper: [_Like, Trust and Respect: Tokenizing Sentiment and Opinion on the Telos Blockchain_](https://github.com/goodblockio/sentiment-tokens/blob/master/Like%20Trust%20Respect%20-%20tokenized%20sentiment%20paper%20v1.pdf). 14 | 15 | # Motivation 16 | 17 | The development of a new form of blockchain token that can be used to record persistent sentiment or opinion about another account creates many new technical possibilities for integrating sentiment, opinion, ratings, certifications, and social media into blockchain technology. 18 | 19 | # Rationale 20 | 21 | Sentiment or opinion about another account can be a powerful and important force within a blockchain network or community like Telos. By having a standard token that may be applied to another account like a badge, either from a single issuer, such as a ratings organization, or from multiple issuers, where measuring aggregate commmunity sentiment increases meaning, accounts may gain persistent but maleable reputations reflecting the sentiment of others. Such sentiment measurements could serve many purposes, such as warning users away from untrustworthy customers or suppliers, designating an account user to be a widely respected authority on a topic, or serving as an community poll about the actions of a company on their actions or offerings. 22 | 23 | # Specification 24 | 25 | The TIP-34 Sentiment Token Standard defines an interface that allows third-party support for token contracts that implement sentiment tokens. The interface is defined as follows: 26 | 27 | ### Tables 28 | 29 | The following tables store information such as token balances and global token settings. 30 | 31 | * `typedef multi_index< N(balances), balance> balances_table` 32 | 33 | The balances table will hold all accounts and their respective token balances. The table is indexed by account_name. 34 | 35 | * `typedef eosio::singleton settings_singleton` 36 | 37 | The settings singleton holds all token related information such as max supply, circulating supply, and a human-readable name. 38 | 39 | ### Structs 40 | 41 | The following structs and their members are stored in tables and referenced by their primary keys. 42 | 43 | * `setting` 44 | 45 | **Issuer** refers to the account authorized to mint new tokens. This may be a single account or, if blank, then any account may issue tokens which are further scoped by their account name. 46 | 47 | **Max Supply** holds the maximum supply of tokens to be allowed in circulation. If blank, the token has no maximum supply. 48 | 49 | **Supply** stores the total tokens currently in circulation. 50 | 51 | **Minting Period** defines the minimum about of time that must pass since the last minting before new tokens can be minted. 52 | 53 | **Minting Amount** defines a fixed amount of tokens that will be minted each time new minting occurs. 54 | 55 | **Name** holds the human-readable name of the token. 56 | 57 | **Name Anti** holds the human-readable name of the anti-token or opposite opinion form of the sentiment token, when used. If blank, the token does not employ an anti-token. 58 | 59 | **Maximum Balance Per Account** holds the maximum value of either tokens or anti-tokens that any recipient account may hold from any single issuer account. If blank then there is no maximum. 60 | 61 | * `balance` 62 | 63 | **Owner** refers to the account where the tokens reside (although this account cannot transfer these tokens). 64 | 65 | **Tokens** holds the balance of tokens owned by the owner. 66 | 67 | ### ABI Actions 68 | 69 | The following function signatures define how users can interact with the token contract. 70 | 71 | * `void mint(account_name issuer, asset tokens, account_name mintbank)` 72 | 73 | Mints new tokens into the circulating supply, associated with issuer, and sends them to the mintbank account. Tokens may be minted either only by the account publishing the contract, when Issuer is defined in the Setting Struct, or by any account, when Issuer is blank in the Setting Struct. Any time a token that has an anti-token is minted, the anti-token is also minted in the same amount (and vice versa). 74 | 75 | * `void transfer(account_name sender, account_name recipient, asset tokens)` 76 | 77 | Transfers tokens from the sender account to the recipient account. Only the issuer has the authority to transfer tokens. Tokens may only be transferred either from or to the mintbank. Tokens may not be transferred to issuer. When a transferring a token that has an anti-token, the balance of the anti-token must be zero before the token can be transferred. When an anti-token balance exists and a positive token balance is transferred to that account by the same issuer account, the anti-token must be reduced (transferred to the mintbank). The reverse is also true when transferring an anti-token to an account with a token balance from the same issuer account. 78 | 79 | # Discussion 80 | 81 | * Q: Why can only issuers transfer tokens, not owners? 82 | 83 | A: Sentiment tokens reflect the opinions of others regarding an account. Allowing owners to acquire or remove them defeats the purpose. 84 | 85 | * Q: What is the mintbank and why is it used? 86 | 87 | A: The mintbank holds sentiment tokens not currently assigned to another account. Once minted, tokens must reside somewhere. The mintbank is a common account to hold all the unassigned sentiment tokens and their anti-tokens from any given sentiment token account. One mintbank could hold the tokens of many different types of sentiment tokens or even all sentiment tokens on the network. Tokens and anti-tokens can only be transferred to or from the mintbank and never from one account directly to another. 88 | 89 | * Q: What is an anti-token and how is it used? 90 | 91 | A: For sentiment tokens that employ a balanced opposite sentiment such as RESPECT and DISRESPECT, the Anti-token is this opposite form (If the token is RESPECT, then the anti-token is DISRESPECT). Since tokens cannot express negative values, but opinion often does, an anti-token is required. When no anti-token is specified, then the token is unidirectional, such as a ratings system that may only be positive values. When transferring tokens, it is necessary to ensure that, First: any anti-token balance is reduced and has reached zero before any positive token balance is applied (and vice versa for anti-token balances), and Second: that the token balance does not exceed the maximum_balance_per_account of either the token or the anti-token. 92 | 93 | * Q: Are the same tokens from different issuers fungible? 94 | 95 | A: No. Sentiment tokens are semi-fungible in that any RESPECT token from the issuer account (accountname1) is fungible with any other RESPECT token from the issuer account (accountname1), but not with RESPECT tokens from any other issuer account. 96 | 97 | # Copyright 98 | 99 | Open Source under GNU GPLv3 License. 100 | -------------------------------------------------------------------------------- /Regarb.md: -------------------------------------------------------------------------------- 1 | Title: Telos "regarb" Human-language Contract 2 | Authors: Mark Cohen, Beth Farnham, Azad Halim, Jim Hewitt, Douglas Horn, Syed Mushabbar Sadiq, Jan Smit, Sukesh Kumar Tedla, Adam Zientarski 3 | Adoption: Adopted by Telos Contributors Group 2018/10/12 4 | Voting: Yes - 20, No - 0, Abstain - 0 5 | 6 | # Telos “regarb” Human-language Contract. 7 | 8 | ## Data Structures 9 | 10 | Arbitrator account name: {{arbitrator}} 11 | Arbitration judges: {Judge:{name}, Languages of proficiency {language:{language}}, 12 | identity_provider_service{idprovider}, ID_hash {idhash}} 13 | Arbitrator ownership information {owner:{name}, percentage_owned{percentage}, country of residence/establishment {country}, identity_provider_service{idprovider}, ID_hash {idhash}} 14 | 15 | ## 1. Intent of Action - {{ regarb }} 16 | 17 | The intent of the {{ regarb }} action is to register an account as an arbitrator candidate, to enumerate the obligations and rules of arbitrator candidacy and service, and to inform arbitrators about the penalties and penalty process for violation of these rules and obligations. 18 | 19 | ## 2. Nomination 20 | 21 | I, {{arbitrator}}, hereby nominate myself for consideration as an Elected Arbitrator. This nomination includes the express agreement to all human-language terms of this contract by the arbitrator candidate entity and all of its owners. I attest that all disclosures I make as part of this nomination contract are true and that no important details have been omitted. 22 | 23 | ## 3. Disclosure of Arbitrator 24 | 25 | If I, {{arbitrator}}, am selected to arbitrate a Case by the voter contract, I will sign messages with {{arbitrator_key}} and I hereby attest that I will keep this key secret and secure. If I suspect my key has been compromised, I will call this contract again with a new secure key. 26 | 27 | ## 4. Penalty Enforcement via Arbitration Tribunal 28 | 29 | I, {{arbitrator}}, acknowledge that if I or a Judge within my entity fail to fulfill the obligations or violate the rules set forth in this contract, that arbitrator and/or said Judge may receive the penalties enumerated for the corresponding violation. The vehicle for this enforcement shall be an arbitration tribunal in which arbitrator and/or said Judge is named as the Respondent. If a majority of the judges of arbitration determine that the infraction did occur, then the associated penalty shall be imposed. 30 | 31 | ## 5. No Other Role 32 | 33 | I, {{arbitrator}}, agree that I, and any owners, if {{arbitrator}} is an entity, shall not seek to serve in another role of trust on the Telos Blockchain Network such as block producer candidate or core developer during the time that I am a candidate for arbitrator. Violation of the preceding by any Judge, as judged by an arbitration tribunal, shall be cause for the disqualification of said Judge from all service as a judge of arbitration for 365 days on first offence or 3 years on second or subsequent offenses. 34 | 35 | ## 6. Resignation and Removal for Inability to Perform Obligations 36 | 37 | If I, {{arbitrator}}, am unable to perform obligations under the human-language terms of this contract I will resign my position by executing the ‘unregarb’ action. 38 | 39 | ## 7. Recusal 40 | 41 | Any time I, {{arbitrator}}, detect a conflict of interest, a family, personal, or business relationship with one or more party(s) of an arbitration, I shall recuse myself from service in that Case by using the recusal action of the ‘arbitration’ contract. I shall also recuse myself from a Case any time I receive attempts of undue influence regarding that Case from a terrestrial government or other entity that may have power over me. I shall not recuse myself from service for any other reason and shall endeavor to bring each Case to a just and timely resolution. Violation of the preceding by any Judge, as judged by an arbitration tribunal, shall be cause for the disqualification of said Judge from all service as a judge of arbitration for 365 days on first offence or 3 years on second or subsequent offenses. 42 | 43 | ## 8. Impartiality 44 | 45 | I, {{arbitrator}}, agree to remain impartial and to conduct arbitration fairly and according to the documented practices of the selected rules of arbitration. I will seek to be consistent with precedents in similar Cases so as to apply a consistent application of the arbitration process. Violation of the preceding by any Judge, as judged by an arbitration tribunal, shall be cause for the disqualification of said Judge from all service as a judge of arbitration for 365 days on first offence or 3 years on second or subsequent offenses. 46 | 47 | ## 9. Ownership 48 | 49 | I, {{arbitrator}}, attest under penalty of perjury that I hereby disclose all owners of my ownership entity and all shareholders who own more than 5%. When required by the Arbitrator Minimum Requirements, I shall also provide an identity verification hash from an accepted third-party identity verification service along with the name of that service. All owners of my ownership entity are listed herein: {owner{name}, (percentage}, (idprovider}, {idhash}}. No owner is currently under penalty for violating the human language terms of the regarbitrator contract. Violation of the preceding by Arbitrator, as judged by an arbitration tribunal, shall be cause for the disqualification of said Arbitrator and all associated Judges from all service as an arbitrator or judge of arbitration for 180 days on first offence or 2 years on second or subsequent offenses. 50 | 51 | ## 10. Arbitrator Personnel 52 | 53 | I, {{arbitrator}}, attest that I, each registered arbitrator personnel listed herein meets the minimum requirements for a Telos Arbitrator Candidate and is proficient in the language or languages indicated. When required by the Arbitrator minimum requirements, I shall also provide an identity verification hash from an accepted third-party identity verification service along with the name of that service. All personnel of my ownership entity who shall serve as Arbitrators are listed herein: {personnel{name}, {(language}}, (idprovider}, {idhash}}. And no Judge is currently under penalty for violating the human language terms of the regarbitrator contract. Violation of the preceding by Arbitrator, as judged by an arbitration tribunal, shall be cause for the disqualification of said Arbitrator and all associated Judges from all service as an arbitrator or judge of arbitration for 180 days on first offence or 2 years on second or subsequent offenses. 54 | 55 | ## 11. Amending Human-language Terms of ‘regarb’ Contract 56 | 57 | I acknowledge that the human-language terms of this contract may be amended from time to time by TLOS owners voting on the ‘ratifyamend’ contract as described in the Telos Blockchain Network Operating Agreement. If I do not consent to the new terms of the amended human-language contract, I must remove myself from service as an arbitrator candidate. Remaining registered as an arbitrator candidate more than 180,000 blocks (approximately 24 hours) after the human-language terms are amended indicates my acceptance of the amended version. 58 | 59 | ## 12. Definitions 60 | 61 | The term “Arbitrator” means an individual or entity such as an arbitration firm serving or seeking to serve in the role of a Judge, as defined below, of arbitration on the Telos Blockchain Network. The term “Judge” means an individual person within the Arbitrator entity who serves the role of a judge of arbitration. The “human-language terms” of a contract means the portion of a smart contract that is written in a human language such as English or Korean as opposed to a computer language such as C++, with the goal of clearly expressing the intent of the transaction between the user executing the contract and the person or entity that controls it. The term “second or subsequent offences” shall refer to violations of any offence described within the same paragraph of this contact’s human-language terms, but not to offences described in different paragraphs. A second or subsequent offence shall only apply if an arbitration tribunal imposed a penalty on a previous alleged offence. 62 | 63 | 64 | # Copyright 65 | 66 | This document is in the public domain 67 | -------------------------------------------------------------------------------- /BPMinReq.md: -------------------------------------------------------------------------------- 1 | Title: Telos Block Producer Minimum Requirements 2 | Authors: J.T. Buice, Mark Cohen, Azad Halim, Jim Hewitt, Douglas Horn, Jerry Huff, Josep Rosich, Syed Mushabbar Sadiq, Sukesh, Adam Zientarski 3 | Adoption: Adopted by Telos Launch Group 2018-10-09 4 | Voting: 2018-10-09 Yes - 25, No - 0, Abstain - 0 5 | Amendment: Amended by Telos Launch Group 2018-12-06 6 | Voting: 2018-12-06 Yes - 33, No - 0, Abstain - 1 7 | 8 | 9 | # Telos Block Producer Minimum Requirements: 10 | 11 | The intent of this document is to clarify the minimum requirements for Block Producer’s to participate in the Telos Blockchain Network (herein referred to as the “TBN”). There are multiple phases of participation, with each level having more stringent requirements than the previous - this is intended to address the growing requirements of the network over time. 12 | 13 | The specifications stated herein are subject to revision, as well as when the network will move from stage to stage - as determined by a vote of ⅔ + 1 of the current Block Producers at the time of the proposed revisions. 14 | 15 | Regardless of their level of participation, to participate in the TBN at any phase - Block Producer candidates are required to provide, and abide by the following: 16 | 17 | ### A. Disclosures: 18 | 19 | #### 1. Block Producer Account Name 20 | 21 | #### 2. Block Producer Public Key 22 | 23 | #### 3. Block Producer Organization Info: 24 | 25 | a. Candidate Name 26 | 27 | b. Candidate Website URL 28 | 29 | c. Candidate country of registration for registered entity or residence of primary owner if not a registered entity as 2-letter ISO country coded. 30 | 31 | d. Candidate server location(s) 32 | 33 | i. Location name 34 | 35 | ii. Country as 2-letter country code 36 | 37 | iii. latitude 38 | 39 | iv. Longitude 40 | 41 | #### 4: Network Emergency Contact(s) 42 | 43 | a. Name 44 | 45 | b. email address 46 | 47 | c. phone number - in a non-public, password protected, repository commonly accessible to any of the 51 paid Block Producers and Standbys. 48 | 49 | #### 5. Block Producer Entity Ownership 50 | 51 | Disclosure of each beneficial owner of block producer entity along with percentage of ownership. [enforced by smart contract] 52 | 53 | Disclosure of accepted third-party identification verification service and identification hash for each beneficial owner (* to be implemented). 54 | 55 | ### B. Practices: 56 | 57 | 1. Sync with an approved NTP server at least once per 24 hours. 58 | 59 | 2. Adoption of account blacklist maintained by the Elected Arbitrators. 60 | 61 | ## Phase One - Minimum Requirements 62 | 63 | #### 1. Endpoints: 64 | 65 | a. P2P endpoint 66 | 67 | b. HTTP API endpoint 68 | 69 | c. HTTPS API endpoint 70 | 71 | #### 2: Nodes: 72 | 73 | a. Testnet Node 74 | 75 | i. Minimum RAM (per node): 8GB 76 | 77 | ii. Minimum Disk (per node): 100GB 78 | 79 | iii. A minimum of 1,200,000 blocks (approximately 7 days) of synched and registered operation of a Telos testnet block production node. 80 | 81 | iv. Ongoing operation of a synched, registered, and publicly accessible Telos testnet block production node within 500,000 blocks (approximately 70 hours). 82 | 83 | v. A maximum total of 1,000,000 blocks of Telos testnet non-operational time within the most recent 5,000,000 blocks (approximately 29 days). Enforcement of which commences at Telos mainnet block height 5,000,000. 84 | 85 | 86 | b. Producing Node 87 | 88 | i. Minimum RAM (per node): 16GB 89 | 90 | ii. Minimum Disk (per node): 100GB 91 | 92 | iii. Firewall: Active 93 | 94 | iv. Plugins: chain, producer. 95 | 96 | c. Full Node 97 | 98 | i. Minimum RAM (per node): 16GB 99 | 100 | ii. Minimum Disk (per node): 100GB 101 | 102 | iii. Firewall: Active 103 | 104 | iv. Plugins: chain, chain_api 105 | 106 | 107 | ## Phase Two - Minimum Requirements 108 | 109 | ### 1. Endpoints: 110 | 111 | a. P2P endpoint 112 | 113 | b. HTTP API endpoint 114 | 115 | c. HTTPS API endpoint 116 | 117 | ### 2. Nodes 118 | 119 | a. Testnet Node 120 | 121 | i. Minimum RAM (per node): =/> current set ram + 2GB 122 | 123 | ii. Minimum Disk (per node): 150GB 124 | 125 | iii. Firewall: Active 126 | 127 | iv. A minimum of 1,200,000 blocks (approximately 7 days) of synched and registered operation of a Telos testnet block production node. 128 | 129 | v. Ongoing operation of a synched, registered, and publicly accessible Telos testnet block production node within 500,000 blocks (approximately 70 hours). 130 | 131 | vi. A maximum total of 1,000,000 blocks of Telos testnet non-operational time within the most recent 5,000,000 blocks (approximately 29 days). 132 | 133 | b. Staging Net Node 134 | 135 | i. Minimum RAM (per node): =/> current set ram + 2GB 136 | 137 | ii. Minimum Disk (per node): 150GB 138 | 139 | iii. Firewall: Active 140 | 141 | iv. Operation of a synched, registered, and operational staging net block producer node for a period of at least 150,000 blocks (approximately 21 hours) during the most recent staging net deployment. Any period of time that a block producer’s node is unregistered or otherwise disabled or removed as the direct result of a staging net test operation shall contribute to this minimum requirement period. 142 | 143 | c. Producing Node 144 | 145 | i. Minimum RAM (per node): =/> current set ram + 2GB 146 | 147 | ii. Minimum Disk (per node): 150GB 148 | 149 | iii. Firewall: Active 150 | 151 | iv. Plugins: chain, producer 152 | 153 | d. Full Node 154 | 155 | i. Minimum RAM (per node): =/> current set ram + 2GB 156 | 157 | ii. Minimum Disk (per node): 150GB 158 | 159 | iii. Firewall: Active 160 | 161 | iv. Plugins: chain, chain_api 162 | 163 | v. SSL Proxy 164 | 165 | 166 | ## Phase Three - Minimum Requirements 167 | 168 | ##### 1. Endpoints 169 | 170 | a. P2P endpoint 171 | 172 | b. HTTP API endpoint 173 | 174 | c. HTTPS API endpoint 175 | 176 | ##### 2. Nodes 177 | 178 | a. Testnet Node 179 | 180 | i. Minimum RAM (per node): =/> current set ram + 2GB 181 | 182 | ii. Minimum Disk (per node): 300GB 183 | 184 | iii. Firewall: Active 185 | 186 | iv. A minimum of 1,200,000 blocks (approximately 7 days) of synched and registered operation of a Telos testnet block production node. 187 | 188 | v. Ongoing operation of a synched, registered, and publicly accessible Telos testnet block production node within 500,000 blocks (approximately 70 hours). 189 | 190 | vi. A maximum total of 1,000,000 blocks of Telos testnet non-operational time within the most recent 5,000,000 blocks (approximately 29 days). 191 | 192 | b. Staging Net Node 193 | 194 | i. Minimum RAM (per node): =/> current set ram + 2GB 195 | 196 | ii. Minimum Disk (per node): 300GB 197 | 198 | iii. Firewall: Active 199 | 200 | iv. Operation of a synched, registered, and operational staging net block producer node for a period of at least 150,000 blocks (approximately 21 hours) during the most recent staging net deployment. Any period of time that a block producer’s node is unregistered or otherwise disabled or removed as the direct result of a staging net test operation shall contribute to this minimum requirement period. 201 | 202 | c. Producing Node 203 | 204 | i. Minimum RAM (per node): =/> current set ram + 2GB 205 | 206 | ii. Minimum Disk (per node): 300GB 207 | 208 | iii. Firewall: Active 209 | 210 | iv. Plugins: chain, producer 211 | 212 | d. Full Node 213 | 214 | i. Minimum RAM (per node): =/> current set ram + 2GB 215 | 216 | ii. Minimum Disk (per node): 300GB 217 | 218 | iii. Firewall: Active 219 | 220 | iv. Plugins: chain, chain_api 221 | 222 | v. SSL Proxy 223 | 224 | # Copyright: 225 | 226 | This document is in the public domain. 227 | -------------------------------------------------------------------------------- /tip-0003.md: -------------------------------------------------------------------------------- 1 | TIP: 0003 2 | Title: Establishment of common-use snapshots for airgrabs 3 | Authors: Jesse Schulman 4 | Status: Adopted 5 | Type: Informational 6 | Created: 2018-07-30 7 | Adopted: 2018-10-30 Voting - Yes: 27, No: 0, Abstain: 6 8 | 9 | 10 | # Abstract 11 | 12 | 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. 13 | 14 | # Motivation 15 | 16 | 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. 17 | 18 | # Rationale 19 | 20 | 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. 21 | 22 | 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. 23 | 24 | # Specification 25 | 26 | 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. 27 | 28 | 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. 29 | 30 | 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. 31 | 32 | 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. 33 | 34 | 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. 35 | 36 | # Optional proposal A: 37 | 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. 38 | 39 | # Optional proposal B: 40 | 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. 41 | 42 | # Open Questions 43 | 44 | 1. How the contract RAM and CPU/Bandwidth for performing the snapshot will be paid for? (Suggestion: paid for by the Telos Foundation endowment.) 45 | 46 | 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. 47 | 48 | 2. Who controls the keys and performs the ongoing snapshots? (Suggestion: the TF voters or their elected representatives.) 49 | 50 | Douglas.tf: The Telos Foundation board controls the keys for the account: snapshots.tf 51 | 52 | 3. How frequently to perform snapshots and how many historical snapshots to keep? (Suggestion: perform every two months; keep 2 snapshots at any given time.) 53 | 54 | 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. 55 | 56 | 4. Do we also want to pursue the optional proposals? 57 | 58 | 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. 59 | 60 | # Copyright 61 | This document is placed in the public domain. 62 | -------------------------------------------------------------------------------- /tip-0004.md: -------------------------------------------------------------------------------- 1 | TIP: 0004 2 | Title: Premium names and name squatting prevention 3 | Authors: Josep Rosich 4 | Status: Draft 5 | Type: Informational 6 | Created: 2018-07-23 7 | 8 | # Abstract 9 | This proposal defines some guidelines to improve how account names are created in Telos, and what we can do to prevent impersonating and provide trademark protection. 10 | 11 | # Motivation 12 | Name squatting already happened on EOS main net during the first minutes of launch process when a few BPs got their names registered by someone else. Now there is a case of impersonating a BP account (Cryptolions) that is used for a scam and EOS main net is unable to do anything to fix it. Many users/companies are interested in buy affordable premium names, with less than 12 characters. 13 | 14 | # Rationale 15 | 1. There is no trademark/name/domain protection on EOS main net. 16 | 2. There is no process to claim a squatted name account. 17 | 3. Premium names are part of a bidding process but only 1 a day is released. That means many names will never be released. 18 | 4. There is no mechanism to buy vanity names. 19 | 20 | # Specification 21 | 1. Arbitration in name squatting cases. TF should be able to transfer squatted account names to legal trademark or internet domain holder. 22 | 2. TLD domains (.com,.net,.org...etc) should be controlled by TF and accounts using it can be sold like any other internet domain. 23 | 3. Premium and vanity names: any user should be able to buy premium names (6-11 characters). 24 | 4. All name purchases should be paid in TLOS and should be handled by smart contracts. 25 | 5. Premium names may be granted before main net activation to individuals, BPs, DAPPs and Exchanges involved in launch process. This process must be open to everyone. 26 | 27 | # Name prices 28 | 1. TLD: 100 TLOS* (any .com, .net, .org, etc... subdomain). Can be freely bought but account owner must be rquired to prove copyright/trademark ownership. First-come, first-served. 29 | 2. Premium names-vanity names, brand Names/trademark (max 6-12 characters): 100 TLOS* 30 | 3. High Value names: (3-5 characters): to be decided (10,000 TLOS*) 31 | 32 | *All prices are subject to change. This is only a proposal. 33 | 34 | # Special names 35 | 36 | 1. BPs in launching group will be able to reserve up to 5 names related to its brand and projects they sponsor before main net open to public. 37 | 2. DAPPs committed to launch in Telos main net during the first 3 months will have 5 free account names (TLD or/and Names/trademark) as part of the Telos DAPPs Welcome Pack. All names can be reserved before main net is open. This should be advertised in advance across the media channels, and added to Telos selling points. 38 | 39 | # What to do with Fees from name selling? 40 | 1. Burn them all (reducing inflation) 41 | 2. Distribute among staked users generating passive income 42 | 3. Create a fund for DAPPs grants 43 | 4. Use them for Workers Proposals 44 | 5. Create an insurance fund for stolen/hacked accounts 45 | 46 | In my opinion, we either should burn them all or distribute among staked users for passive income. The insurance fund for stolen/hacked accounts is also something we should consider. 47 | 48 | # Special cases 49 | 1. b1 name account should be preserved 50 | 2. There must be a Telos Foundation account. 51 | 3. Block Producers account names from EOS Main Net must be preserved if the BP requires it. We should reach them with the offer. This does not imply any support to Telos but we do want to prevent impersonation. We must protect those names (see Cryptolions impersonation/scam account on main net for example). 52 | 53 | # Copyright 54 | This document is placed in the public domain. 55 | 56 | # Discussion 57 | The area below is for recording comments. Please add your name and thoughts. These will help develop the document and will be preserveed historically, but will not be included in the final document. 58 | 59 | Douglas Horn: 60 | 61 | I have been putting a lot of thought into this recently and was planning a position paper once I got through all the really crucial stuff. 62 | 63 | Let's first remember that even though all of us are working hard to build Telos, none of us have any special rights or priveledges on it. So the concept of reserving names must be in the context. 64 | 65 | Motivation: 66 | We can address the squatting of BP names as I discuss below under Special Cases 3. 67 | 68 | Rationale: 69 | 1. Trademark does not apply to account names at all. 70 | 2. Other than the concept of BP names, I don't believe there's any such thing as a squatted name on Telos. Only Members have ANY rights whatsoever on the Telos Network and mo Member has a right to any specific combination of 12 letters + 1-5 (BPs don't either, but we'll address it as part of avoiding voter confusion). 71 | 3. The EOS 1 premium name per day rule feels ridiculous to me. There should instead be an amount of time that each proposed premium name should be on offer once proposed--a length of time that gets shorter the higher the value goes. At a certain price level, there needs to be a new bid every minute, or the auction ends. By the way, these do vastly favor the early adopters (as everything in blockchain tends to and which serves as an incentive to early engagement.) 72 | 4. A mechanism for buying vanity names is good. I agree that we should develop this.There's a lot of space between premium names and regular names. Lots of good 8-character names to be had. I support this and think we should get on it, though it is not a launch requirement. 73 | 74 | Regarding trademarks, I don't think they apply or are something we should seek to honor. Trademarks vary country to country. Honoriog tradmarks mean we will be asked to decide which country's should take precdidence. Even within one country, Trademarks can be granted to multiple companies under the same name as long as they are in different categories. Consider Amazon Canoes is excited about joining Telos and that they have the TM for Amazon as it applies to canoes. If they are excited about telos and want to register AmazonTelos1 how do they have less right to it than Amazon.com? What if there's some girl who everyone calls "Amazon" because she's an amazing MMA fighter - not famous, but someday, who knows. And she loves telos too! Can She be telosamazon1, or do we have to just save those for companies with trademarks? Because all that smells to me like the big guys having some (more) special priveledges over the little guys. There is a reason why ICANN abandoned trying to adjudicate exactly this matter: it's not possible. We can only embrace first come, first served. It's the only way that works. Trademarks are only about preventing purchaser confusion, nothing else. There is nothing in Trademark law that confers any rights whatsoever to a specific username. Who even knows what Amazon.com might pick, the possibilities are endless. Do we have to protect anything they might possibly want? I say no. The people who engage with Telos earlier get the advantages of an unclaimed landscape and that includes the free names. At least to my way of thinking. 75 | 76 | Specification 77 | 1. There's nothing that establishes anyone has any special right to a specific 12-digit name. Let's not gum up arbitration with this. 78 | 2. This gives the TF a new role that's never been discussed before. We should talk about it. 79 | 3. If any character can buy these names, what if they buy something another feels is squatted? Can they arbitrate, even though the name was sold? 80 | 3. 3-5 character names - aren't these the ones that we are proposing auctioning? 81 | 4. I disagree with pre-access to the blockchain for names. Let's keep the genesis as clean as possible. 82 | 83 | Name Prices: 84 | 1. See my thoughts on the quagmire that will be the proving ownership process. (Plus, who is volunteering to do this work?) 85 | 2. General premium vanity names (6-11 characters -- 12 characters are free) Yes, this is good and I support it. But understand that if we let people buy these, it's just another first come, first served situation. Why would we sweat to proactively reserve amazontelos1 and just let anyone buy amazoncom for 100 TLOS? 86 | 87 | What to do with fees: 88 | I think burning is kind of a waste. Burning and distributing 'dividends' both equally distribute the value to owners. From a tax standpoint, burning is actually less hassle than distributing, but it's mostly invisible, whereas people love getting distributions. It keeps more value in the coin. Alternatively, we can just send them to worker proposals where the voters could decide to use, burn, or distribute dividends. 89 | 90 | Special names: 91 | 1. Reserving a specific list of names to avoid voter confusion for BPs is different than letting each TLG contributor get a free list of 5 names they would like. That would constitute a special priveledge that non-members don't have. We want to limit these. Frankly we all haev a big advantage in that we are on the network early and can quickly create a lot of accounts on Telos before many squatters roll in. That is just playing by the same rules as everyone else. 92 | 2. I don't think we'll have any DApps commit until we launch. Let them grab the names they like. It will be an incentive to get involved early. 93 | 94 | Special cases: 95 | 1. b1 account name will already be preserved by the genesis snapshot. 96 | 2. The Telos Foundation will have an account created on the Telos genesis to hold its reserved tokens. 97 | 3. The The RegProducer contract includes terms making running a misleading BP name cause for being unregistered. In that we do extend the courtesy to any BPs registered on the EOS blockchain in the first 30 days. I think that in the name of reducing voter confusion, we could create a pool of these names and assign them 1 TLOS each to hold them for claiming in the future. We can allow any existing BPs to opt out of the list and grab their own names immediately instead. I don't want to violate the genesis snapshot. 98 | 99 | The only reason we would ever try to arbitrate an account name from a person who registered it is that it has some value. Therefore, taking it away from someone who got there first is taking value from them without cause. I don't think we stand for that as a network. 100 | 101 | -------------------------------------------------------------------------------- /tip-0001.md: -------------------------------------------------------------------------------- 1 | TIP: 0001 2 | Title: TIP Purpose and Guidelines 3 | Authors: Robert Konsdorf 4 | Status: Draft 5 | Type: Informational 6 | Created: 2018-07-30 7 | 8 | # What is a TIP? 9 | 10 | TIP stands for Telos Improvement Proposal but can also seen as an 11 | improvement *protocol*. A TIP is a design document providing information to the Telos community, or describing a new feature for Telos or its processes 12 | or environment. The TIP should provide a concise technical specification of the 13 | feature or the idea and a rationale for it. It may not only describe technical 14 | improvements but also document *best-practises* and recommendations. 15 | 16 | We intend TIPs to be the primary mechanisms for proposing new features, for 17 | collecting community input on an issue, and for documenting the design decisions 18 | that have gone into Telos. The TIP author is responsible for building 19 | consensus within the community and documenting dissenting opinions. 20 | 21 | Because the TIPs are maintained as text files in a versioned repository, their 22 | revision history is the historical record of the feature proposal. 23 | 24 | # TIP Types 25 | 26 | There are two kinds of TIPs: 27 | 28 | * An **Informational** TIP describes a Telos design issue, or provides general 29 | guidelines or information to the Telos community, but does not propose a 30 | new feature, protocol change or any other modification. Informational TIPs do 31 | not necessarily represent a Telos community consensus or recommendation, 32 | so users and implementors are free to ignore Informational TIPs or follow 33 | their advice. Examples would be *best-practises* or *recommendations*. 34 | * A **Protocol** Upgrade TIP describes any change that affects most or all 35 | Telos implementations, such as a change to the protocol, a change in block 36 | or transaction validity rules, or any change or addition that affects the 37 | interoperability of applications using Telos. 38 | 39 | # Contributing 40 | 41 | People wishing to submit TIPs first should propose their idea as github 42 | issue first. After discussion you will be assigned a number for the TIP 43 | and can send a pull request for your *draft*. Once consensus among 44 | discussion participants is reached, the status can be switched to 45 | *accepted*. From this time on, major changes of the document will not be 46 | permitted. 47 | 48 | If the proposal requires a protocol upgrade, the proposal is considered 49 | *implemented* only if shareholders have approved a corresponding worker or 50 | hard fork proposal. Informational TIPs can only reach the *accepted* 51 | state since their implementation is not enforced by the blockchain. 52 | 53 | We are fairly liberal with listing TIP drafts here since the 54 | final decision of its actual implementation is made solely by Telos 55 | shareholders via approval voting. 56 | 57 | It is highly recommended that a single TIP contain a single key 58 | proposal or new idea. Small enhancements or patches often don't need a 59 | TIP and can be injected into the Telos development work flow with a 60 | patch submission to the Telos issue tracker. The more focused the 61 | TIP, the more successful it tends to be. The TIP editor reserves the 62 | right to reject TIP proposals if they appear too unfocused or too 63 | broad. If in doubt, split your TIP into several well-focused ones. 64 | 65 | Vetting an idea publicly before going as far as writing a TIP is meant to save 66 | the potential author time. Many ideas have been brought forward for changing Telos that have been rejected for various reasons. Asking the Telos 67 | community first if an idea is original helps prevent too much time being spent 68 | on something that is guaranteed to be rejected based on prior discussions 69 | (searching the internet does not always do the trick). It also helps to make 70 | sure the idea is applicable to the entire community and not just the author. 71 | Just because an idea sounds good to the author does not mean it will work for 72 | most people in most areas where Telos is used. 73 | 74 | Following a discussion, the proposal should be sent to the Telos developers 75 | and the TIP editors with the draft TIP. This draft must be written in TIP 76 | style as described below, else it will be sent back without further regard until 77 | proper formatting rules are followed. 78 | 79 | If the TIP editor approves, he will assign the TIP a number, label it, give it 80 | status "Draft", and add it to the git repository. The TIP editor will not 81 | unreasonably deny a TIP. Reasons for denying TIP status include duplication 82 | of effort, being technically unsound, not providing proper motivation or 83 | addressing backwards compatibility, or not in keeping with the Telos 84 | philosophy. 85 | 86 | The TIP author may update the Draft as necessary in the git repository. Updates 87 | to drafts may also be submitted by the author as pull requests. 88 | 89 | For a TIP to be accepted it must meet certain minimum criteria. It must be a 90 | clear and complete description of the proposed enhancement. The enhancement must 91 | represent a net improvement. The proposed implementation, if applicable, must be 92 | solid and must not complicate the protocol unduly. 93 | 94 | Once a TIP has been published, the reference implementation must be 95 | completed. When the reference implementation is complete and accepted 96 | by the shareholders via approval voting, the status will be changed to 97 | "Accepted". A TIP can also be "Rejected" by shareholders. 98 | 99 | Furthermore, a TIP can be assigned status "Deferred". The TIP author or editor 100 | can assign the TIP this status when no progress is being made on the TIP. Once 101 | a TIP is deferred, the TIP editor can re-assign it to draft status. 102 | 103 | TIPs can also be superseded by a different TIP, rendering the original 104 | obsolete. This is intended for Informational TIPs, where version 2 of an API 105 | can replace version 1. 106 | 107 | # What belongs in a TIP? 108 | 109 | Each TIP *should* have the following parts: 110 | 111 | * Preamble -- RFC 822 style headers containing meta-data about the TIP, 112 | including the TIP number, a short descriptive title (limited to a maximum of 113 | 44 characters), the names, and optionally the contact info for each author, 114 | etc. 115 | 116 | * Abstract -- a short (~200 word) description of the technical issue being 117 | addressed. 118 | 119 | * Copyright/public domain -- Each TIP must either be explicitly labelled as 120 | placed in the public domain (see this TIP as an example) or licensed under 121 | the Open Publication License. 122 | 123 | * Motivation -- The motivation is critical for TIPs that want to change the 124 | Telos protocol. It should clearly explain why the existing protocol 125 | specification is inadequate to address the problem that the TIP solves. TIP 126 | submissions without sufficient motivation may be rejected outright. 127 | 128 | * Rationale -- The rationale fleshes out the specification by describing what 129 | motivated the design and why particular design decisions were made. It should 130 | describe alternate designs that were considered and related work, e.g. how the 131 | feature is supported in other languages. The rationale should provide evidence 132 | of consensus within the community and discuss important objections or concerns 133 | raised during discussion. 134 | 135 | * Specification -- The technical specification should describe the syntax and 136 | semantics of any new feature. The specification should be detailed enough to 137 | allow competing, interoperable implementations for any of the current 138 | Telos platforms. 139 | 140 | * Discussion -- The TIP shall include a discussion on positive and negative 141 | effects on the Telos ecosystem shall it be accepted by shareholders. This 142 | section is supposed to be the most important section for shareholders to grasp 143 | the full impact of the TIP and help shareholders to make a decision. 144 | 145 | * Summary for Shareholders -- Most TIPs will probably be of technical nature. 146 | However, many shareholders are not as technical as the author of a particular 147 | TIP. This non-technical paragraph serves as a place which can be used to 148 | to interact with shareholders and help them form their opinion. It is not 149 | meant to be a marketing driven paragraph to convince shareholders to vote 150 | **for** or **against** a proposal, though. 151 | 152 | # TIP Formats and Templates 153 | 154 | TIPs should be written in mediawiki or markdown format. Image files should be 155 | included in a subdirectory for that TIP. A template including the header 156 | preamble is provided in [this repository](TIPs-Template.md). 157 | 158 | # TIP Editors 159 | 160 | The current TIP editors are: 161 | 162 | * Robert Konsdorf 163 | * Douglas Horn 164 | * James Davis 165 | 166 | The editors don't pass judgement on TIPs. We merely do the administrative & 167 | editorial part. 168 | 169 | Many TIPs are written and maintained by developers with write access to the Telos codebase. The TIP editors monitor TIP changes, and correct any 170 | structure, grammar, spelling, or markup mistakes we see. 171 | 172 | For each new TIP that comes in an editor does the following: 173 | 174 | * Read the TIP to check if it is ready: sound and complete. The ideas must make 175 | technical sense, even if they don't seem likely to be accepted. 176 | * The title should accurately describe the content. 177 | * Edit the TIP for language (spelling, grammar, sentence structure, etc.), 178 | markup (for reST TIPs), code style (examples should match TIP 8 & 7). 179 | 180 | Once the TIP is ready for the repository it should be submitted as a "pull 181 | request" to the [https://github.com/Telo-Foundation/tips] repository 182 | on GitHub where it may get further feedback. 183 | 184 | The TIP editor will: 185 | 186 | * Assign a TIP number (almost always just the next available number, but 187 | sometimes it's a special/joke number, like 666 or 3141) in the pull request 188 | comments. 189 | * Merge the pull request when the author is ready (allowing some time for 190 | further peer review). 191 | * List the TIP in [[README.mediawiki]] 192 | * Send email back to the TIP author with next steps (post to Telos mailing 193 | list). 194 | 195 | # History 196 | 197 | This document was forked from Bitshare's BSIP, which is derived heavily from Python's PEP-0001 and Bitcoin BIP-0001. 198 | In many places text was simply copied and modified. Although the 199 | PEP-0001/BIP-0001 text was written by Barry Warsaw, Jeremy Hylton, and David 200 | Goodger, they are not responsible for its use in the Telos Improvement 201 | Process, and should not be bothered with technical questions specific to Telos or the TIP process. Please direct all comments to the TIP editors. -------------------------------------------------------------------------------- /regproducer_human_language_contract.md: -------------------------------------------------------------------------------- 1 | # Telos regproducer Human-language Contract. 2 | 3 | ## 1. Intent of Action - {{ regproducer }} 4 | The intent of the {{ regproducer }} action is to register an account as a block producer candidate, to enumerate the obligations and rules of block producer candidacy and operation, and to inform producers about the penalties and penalty process for violation of these rules and obligations. 5 | 6 | ## 2. Nomination 7 | I, {{producer}}, hereby nominate myself for consideration as an elected block producer. This nomination includes the express agreement to all terms of this human-language contract by the block producer candidate entity and all of its owners. 8 | 9 | ## 3. Disclosure of Producer Key 10 | If {{producer}} is selected to produce blocks by the eosio contract, I will sign blocks with {{producer_key}} and I hereby attest that I will keep this key secret and secure. 11 | 12 | ## 4. Penalty Enforcement via ‘enforecebprules’ Contract 13 | I acknowledge that if I fail to fulfill the obligations or violate the rules set forth in this contract, that the other block producers shall impose upon me the penalties enumerated for the corresponding violation. The vehicle for this enforcement shall be the ‘enforcebprules’ contract which may be executed by any block producer to allege a violation of the rules and present evidence of the violation. The ‘enforcebprules’ contract shall alert me if I am accused of a violation and I will have a maximum of six hours to post a rebuttal to the evidence presented against me prior to other block producers voting. If a 2/3+1 majority of elected block producers votes that they are convinced the infraction did occur, then the associated penalty shall be imposed. 14 | 15 | ## 5. Obligation to Enforce Block Producer Rules 16 | I acknowledge that at any time I serve as a block producer, I shall enforce the rules and associated penalties set forth in this human-language contract when another block producer reports evidence of an alleged violation in the form of executing the ‘enforcebprules’ contract. When ‘enforcebprules’ is executed by any block producer, I have the obligation to assess all evidence presented both by the accuser and the accused and vote whether the evidence persuades me that the alleged infraction has occurred. I shall, within 12 hours of the contract being first executed in the case, cast a definitive yes or no vote via the ‘enforcebprules’ contract as to whether I am convinced the violation occurred. Failure to vote within 12 hours shall place me in violation of the block producer minimum requirements until either I vote or the ‘enforcebprules’ contract is enacted by a majority of 2/3+1 of all block producers. If I discover evidence of a violation of this human-language contract by another block producer, I am obligated to execute the ‘enforcebprules’ contract and provide evidence of the alleged violation as quickly as I may fully investigate and collect evidence. 17 | 18 | ## 6. Resignation and Removal for Inability to Perform Obligations 19 | If {{producer}} is unable to perform obligations under this human-language contract I will resign my position by resubmitting this contract with the null producer key. If {{producer}} fails to resign when unable to perform said obligations, {{producer}} shall be removed after 30 minutes of non-performance by automated contract or by actions of the remaining block producers. 20 | 21 | ## 7. Objectively Valid and Invalid Blocks 22 | I acknowledge that a block is “objectively valid” if it conforms to the deterministic blockchain rules in force at the time of its creation, and is “objectively invalid” if it fails to conform to those rules. 23 | 24 | ## 8. Signing of Messages with Producer Key 25 | {{producer}} hereby agrees to only use {{producer_key}} to sign messages under the following scenarios: proposing an objectively valid block at the time appointed by the block scheduling algorithm, pre-confirming a block produced by another producer in the schedule when I find said block objectively valid, confirming a block for which {{producer}} has received 2/3+1 pre-confirmation messages from other producers. Apparent intentional violation of the preceding, as judged by a majority of 2/3+1 of all block producers, shall be cause for my disqualification from all service as a block producer for 90 days on first offence or 365 days on second or subsequent offenses. I may also be liable for liabilities due to this action. 26 | 27 | ## 9. Acceptance of Liability and Damages 28 | I hereby accept liability for any and all provable damages that result from my: signing two different block proposals with the same timestamp with {{producer_key}}, signing two different block proposals with the same block number with {{producer_key}}, signing any block proposal which builds off of an objectively invalid block, signing a pre-confirmation for an objectively invalid block, signing a confirmation for a block for which I do not possess pre-confirmation messages from 2/3+1 other producers. Apparent intentional violation of the preceding, as judged by a majority of 2/3+1 of all block producers, shall be cause for my disqualification from all service as a block producer for 90 days on first offence or 365 days on second or subsequent offenses. I may also be liable for liabilities due to this action. 29 | 30 | ## 10. Malicious Collusion 31 | I hereby agree that double-signing for a timestamp or block number in concert with 2 or more other producers shall automatically be deemed malicious and subject to a fine equal to the past year of compensation received, and other damages. An exception may be made if {{producer}} can demonstrate that the double-signing occurred due to a bug in the reference software; the burden of proof is on {{producer}}. Apparent intentional violation of the preceding, as judged by a majority of 2/3+1 of all block producers, shall be cause for my disqualification from all service as a block producer for 365 days on first offence or 5 years on second or subsequent offenses. 32 | 33 | ## 11. Interference with Block Producer Election Process 34 | I hereby agree not to interfere with the producer election process. I agree to process all producer election transactions that occur in blocks I create, to sign all objectively valid blocks I create that contain election transactions, and to sign all pre-confirmations and confirmations necessary to facilitate transfer of control to the next set of producers as determined by the system contract. Apparent intentional violation of the preceding, as judged by a majority of 2/3+1 of all block producers, shall be cause for my disqualification from all service as a block producer for 90 days on first offence or 365 days on second or subsequent offenses. 35 | 36 | ## 12. Adherence to Block Producer Minimum Requirements 37 | I hereby acknowledge that violation of the block producer minimum requirements shall be cause for disqualification from service of {{producer}} as a block producer until {{producer}} is once again in compliance. Compliance with the block producer minimum requirements shall be monitored and enforced by smart contract, oracle, or other objective, disinterested party as the network shall initially designate on network launch or subsequently amend. The current block producer minimum requirements shall be recorded on chain at a publicly disclosed address. 38 | 39 | ## 13. Authentication of Network Peers 40 | The community agrees to allow {{producer}} to authenticate peers as necessary to prevent abuse and denial of service attacks; however, {{producer}} agrees not to discriminate against non-abusive peers. Apparent intentional violation of the preceding, as judged by a majority of 2/3+1 of all block producers, shall be cause for my disqualification from all service as a block producer for 30 days on first offence or 180 days on second or subsequent offenses. 41 | 42 | ## 14. Fair Dealing in Processing Transactions 43 | I agree to process transactions on a first-in, first-out, best-effort basis and to honestly bill transactions for measured execution time. Apparent intentional violation of the preceding, as judged by a majority of 2/3+1 of all block producers, shall be cause for my disqualification from all service as a block producer for 30 days on first offence or 180 days on second or subsequent offenses. 44 | 45 | ## 15. No Reordering Transactions to Profit 46 | I {{producer}} agree not to manipulate the contents of blocks in order to derive profit from the order in which transactions are included the hash of the block that is produced. Apparent intentional violation of the preceding, as judged by a 2/3+1 majority of all block producers, shall be cause for my removal from all service as a block producer for 90 days on first offence or 365 days on second or subsequent offenses. 47 | 48 | ## 16. Ownership 49 | I, {{producer}}, hereby agree to disclose and attest under penalty of perjury all ultimate beneficial owners of my ownership entity who own more than 5% and all direct shareholders. I will not misrepresent ownership or the penalty status of any owners in an attempt to evade penalties. Misrepresentation includes misspelling or using an alternate writing of the same person or entity’s name, listing the name of an entity owned or controlled more than 5% by a listed owner, listing the name of any person or entity who is not the true beneficial owner or their fiduciary. Apparent intentional violation of the preceding, as judged by a majority of 2/3+1 of all block producers, shall be cause for my disqualification from all service as a block producer for 90 days on first offence or 365 days on second or subsequent offenses. 50 | 51 | ## 17. Ownership of More than One Block Producer 52 | I acknowledge that no entity, whether an individual, corporation, nonprofit, or decentralized organization, shall own any interest in more than one block producer candidate at any time. For the purpose of this paragraph, spouses, parents, children and siblings of an owner shall be considered the same as the owner. Any block producer with any owner currently under penalty by the ‘enforcebprules’ contract is disqualified for the entire term of the penalty. 53 | 54 | ## 18. Producing Blocks on Schedule 55 | I, {{producer}}, agree not to produce blocks before my scheduled time unless I have received all blocks produced by the prior producer. Apparent intentional violation of the preceding, as judged by a majority of 2/3+1 of all block producers, shall be cause for my disqualification from all service as a block producer for 30 days on first offence or 90 days on second or subsequent offenses. 56 | 57 | ## 19. Producing Blocks on Accurate Time 58 | I, {{producer}}, agree not to publish blocks with timestamps more than 500ms in the past or future unless the prior block is more than 75% full by either CPU or network bandwidth metrics. Apparent intentional or negligent violation of the preceding, as judged by a majority of 2/3+1 of all block producers, shall be cause for my disqualification from all service as a block producer for 30 days on first offence or 90 days on second or subsequent offenses. 59 | 60 | ## 20. Setting Accurate RAM Supply 61 | I, {{producer}}, agree not to set the RAM supply to more RAM than my nodes contain. Apparent intentional violation of the preceding, as judged by a majority of 2/3+1 of all block producers, shall be cause for my disqualification from all service as a block producer for 30 days on first offence or 90 days on second or subsequent offenses. 62 | 63 | ## 21. Voter-confusing Block Producer Names 64 | Block producer candidates shall not register names intended or deemed likely to create confusion among Telos voters as to their identity compared to other Telos block producers. Priority of names will be granted to the block producer candidate who first registered on the Telos network or Telos pre-launch testnet. Until the Telos network has been activated for six months, the same priority will be granted to block producer candidates who registered a block producer name during the first 30 days of the original EOS mainnet. Violation of the preceding, as judged by a majority of 2/3+1 of all block producers, shall be cause for my disqualification from all service as a block producer until a new block producer name is registered. There shall be no further penalty for this violation. 65 | 66 | ## 22. Amending ‘regproducer’ Human-language Contract 67 | I acknowledge that the terms of this human-language contract may be amended from time to time by Telos owners voting on the ‘ratifyamend’ contract as described in the Telos Network Operating Agreement. If I do not consent to the new terms of the amended human-language contract, I must remove my block producer candidate from service. Remaining registered as a block producer more than 24 hours after this human-language contract is amended indicates my acceptance of the new version. 68 | 69 | ## 23. Definitions 70 | The term “block producer” shall be deemed to mean one of the up to 21 block producer candidates actually validating transactions on the Telos network, including any non-elected block producer candidate serving the validating function due to the failure of another block producer, or rotation schemes intended to aid network health, or any other reason. The term “second or subsequent offences” shall refer to violations of any offence described within the same paragraph of this human-language contract, but not to offences described in different paragraphs. A second or subsequence offence shall only apply if a majority of 2/3+1 block producers voted to impose a penalty on a previous alleged offence. A majority of “2/3+1” shall mean a number greater than or equal to 2/3rds of the total number plus one additional. For clarity, when the total is 21 block producers, a 2/3+1 majority would require the votes of 15 block producers. A “human-language contract” means the portion of a smart contract that is written in a human language such as English or Korean as opposed to a computer language such as C++, with the goal of clearly expressing the intent of the transaction between the user executing the contract and the person or entity that controls it. 71 | -------------------------------------------------------------------------------- /Regproducer.md: -------------------------------------------------------------------------------- 1 | Title: Telos "regproducer" Human-language Contract 2 | Authors: Mark Cohen, Beth Farnham, Azad Halim, Jim Hewitt, Douglas Horn, Ian Panchevre, Syed Mushabbar Sadiq, Jan Smit, Sukesh Kumar Tedla,Adam Zientarski 3 | Adoption: Adopted by Telos Contributors Group 2018-10-9 4 | Voting: Yes - 21, No - 2, Abstain - 1 5 | 6 | # Data Structures 7 | 8 | Producer account name: {{producer}} 9 | Producer signing key: {{producer_key}} 10 | Producer ownership information: {owner:{name}, percentage_owned{percentage}, identity_provider_service {idprovider}, ID_hash {idhash}} 11 | Candidate Name: {{producer_name}} 12 | Candidate Website URL: {{producer_URL}} 13 | Candidate Domicile Country (2-letter country code): {{entity_domicile_country}} 14 | Candidate server location(s): {server:{location_name}, {server_location_country}, {server_location_latitude}, {server_location_longitude}} 15 | 16 | # Human Language Terms 17 | 18 | ## 1. Intent of Action — {{ regproducer }} 19 | 20 | The intent of the {{ regproducer }} action is to register an account as a block producer candidate, to enumerate the obligations and rules of block producer candidacy and operation, and to inform producers about the penalties and penalty process for violation of these rules and obligations. 21 | 22 | ## 2. Nomination 23 | 24 | I, {{producer}}, hereby nominate myself for consideration as an elected block producer. This nomination includes the express agreement to all terms of this human-language contract by the block producer candidate entity and all of its owners. 25 | 26 | ## 3. Disclosure of Producer Key 27 | 28 | If {{producer}} is selected to produce blocks by the “eosio” contract, I will sign blocks with {{producer_key}} and I hereby attest that I will keep this key secret and secure. If I suspect my key has been compromised, I will call this contract again with a new secure key. 29 | 30 | ## 4. Disclosure of Entity and Server Information 31 | 32 | I, {{producer}}, acknowledge that I have disclosed accurate information about my block producer entity and server location(s). Server location data is accurate to within two degrees of latitude and longitude. The country of domicile of my ownership entity, expressed as a 2-letter ISO code is {{entity_domicile_country}}. The location(s) or my block producer server(s) is {{location_name}}, location country, expressed as a 2-letter ISO code is {{server_location_country}}. The location of my block producer server(s), expressed as latitude and longitude is {{server_location_latitude}}, {{server_location_longitude}}. 33 | 34 | ## 5. Penalty Enforcement via “enforcebprules” Contract 35 | 36 | I, {{producer}}, acknowledge that if I fail to fulfill the obligations or violate the rules set forth in this contract, that the other block producers shall impose upon me the penalties enumerated for the corresponding violation. The vehicle for this enforcement shall be the “enforcebprules” contract which may be executed by any block producer to allege a violation of the rules and present evidence of the violation. The “enforcebprules” contract shall alert me if I am accused of a violation and I will have a maximum of 50,000 blocks (approximately seven hours) to post a rebuttal to the evidence presented against me prior to other block producers voting. If a 2/3+1 majority of elected block producers votes that they are convinced the infraction did occur, then the associated penalty shall be imposed. 37 | 38 | ## 6. Obligation to Enforce Block Producer Rules 39 | 40 | I, {{producer}}, acknowledge that at any time I serve as a block producer, I shall enforce the rules and associated penalties set forth in this human-language contract when another block producer reports evidence of an alleged violation in the form of executing the “enforcebprules” contract. When “enforcebprules” is executed by any block producer, I have the obligation to assess all evidence presented both by the accuser and the accused and vote whether the evidence persuades me that the alleged infraction has occurred. I shall, within 100,000 blocks (approximately 14 hours) of the contract being first executed in the case, cast a definitive yes or no vote via the “enforcebprules” contract as to whether I am convinced the violation occurred. Failure to vote within 100,000 blocks shall place me in violation of the block producer minimum requirements until either I vote, or the “enforcebprules” contract is enacted by a majority of 2/3+1 of all block producers. If I discover evidence of a violation of this human-language contract by another block producer, I am obligated to execute the “enforcebprules” contract and provide evidence of the alleged violation as quickly as I may fully investigate and collect evidence. 41 | 42 | ## 7. Resignation and Removal for Inability to Perform Obligations 43 | 44 | If {{producer}} is unable to perform obligations under this human-language contract I will resign my position by resubmitting this contract with the null producer key. If {{producer}} fails to resign when unable to perform said obligations, {{producer}} shall be removed by automated contract or by actions of the remaining block producers. {{producer}} may be removed at any time when it fails to produce 15% or more of its assigned blocks in a rotation of the block producer scheduling routine, or when 1/3–1 block producers are failing to produce blocks on the current schedule and {{producer}} is the block producer with the highest number of missed blocks or the lowest percentage of Member votes among the group of block producers that is failing to produce blocks. 45 | 46 | ## 8. Objectively Valid and Invalid Blocks 47 | 48 | I, {{producer}}, acknowledge that a block is “objectively valid” if it conforms to the deterministic blockchain rules in force at the time of its creation, and is “objectively invalid” if it fails to conform to those rules. 49 | 50 | ## 9. Signing of Messages with Producer Key 51 | 52 | I, {{producer}}, hereby agree to only use {{producer_key}} to sign messages under the following scenarios: proposing an objectively valid block at the time appointed by the block scheduling algorithm, pre-confirming a block produced by another producer in the schedule when I find said block objectively valid, confirming a block for which {{producer}} has received 2/3+1 pre-confirmation messages from other producers. Apparent intentional violation of the preceding, as judged by a majority of 2/3+1 of all block producers, shall be cause for my disqualification from all service as a block producer for 16,000,000 blocks (approximately 90 days) on first offence or 63,000,000 blocks (approximately 365 days) on second or subsequent offenses. I may also be liable for liabilities due to this action. 53 | 54 | ## 10. Acceptance of Liability and Damages 55 | 56 | I, {{producer}}, hereby accept liability for any and all provable damages that result from my: signing two different block proposals with the same timestamp with {{producer_key}}, signing two different block proposals with the same block number with {{producer_key}}, signing any block proposal which builds off of an objectively invalid block, signing a pre-confirmation for an objectively invalid block, signing a confirmation for a block for which I do not possess pre-confirmation messages from 2/3+1 other producers. Apparent intentional violation of the preceding, as judged by a majority of 2/3+1 of all block producers, shall be cause for my disqualification from all service as a block producer for 16,000,000 blocks (approximately 90 days) on first offence or 63,000,000 blocks (approximately 365 days) on second or subsequent offenses. I may also be liable for damages due to this action. 57 | 58 | ## 11. Malicious Collusion 59 | 60 | I, {{producer}}, hereby agree that double-signing for a timestamp or block number in concert with 2 or more other producers shall automatically be deemed malicious and subject to a fine equal to the past year of compensation received, and other damages. An exception may be made if {{producer}} can demonstrate that the double-signing occurred due to a bug in the reference software; the burden of proof is on {{producer}}. Apparent intentional violation of the preceding, as judged by a majority of 2/3+1 of all block producers, shall be cause for my disqualification from all service as a block producer for 63,000,000 blocks (approximately 365 days) on first offence or 315,000,000 blocks (approximately 5 years) on second or subsequent offenses. 61 | 62 | ## 12. Interference with Block Producer Election Process 63 | 64 | I, {{producer}}, hereby agree not to interfere with the producer election process. I agree to process all producer election transactions that occur in blocks I create, to sign all objectively valid blocks I create that contain election transactions, and to sign all pre-confirmations and confirmations necessary to facilitate transfer of control to the next set of producers as determined by the system contract. Apparent intentional violation of the preceding, as judged by a majority of 2/3+1 of all block producers, shall be cause for my disqualification from all service as a block producer for shall be cause for my disqualification from all service as a block producer for 16,000,000 blocks (approximately 90 days) on first offence or 63,000,000 blocks (approximately 365 days) on second or subsequent offenses. 65 | 66 | ## 13. Adherence to Block Producer Minimum Requirements 67 | 68 | I, {{producer}}, hereby acknowledge that violation of the Telos Block Producer Minimum Requirements shall be cause for disqualification from service of {{producer}} as a block producer until {{producer}} is once again in compliance. Compliance shall be monitored and enforced by smart contract, oracle, other objective, or disinterested party as the network developers shall initially designate on network launch or subsequently amend. The current Telos Block Producer Minimum Requirements shall be recorded on chain at a publicly disclosed address. 69 | 70 | ## 14. Authentication of Network Peers 71 | 72 | The community agrees to allow {{producer}} to authenticate peers as necessary to prevent abuse and denial of service attacks; however, {{producer}} agrees not to discriminate against non-abusive peers. Apparent intentional violation of the preceding, as judged by a majority of 2/3+1 of all block producers, shall be cause for my disqualification from all service as a block producer for 5,000,000 blocks (approximately 29 days) on first offence or 32,000,000 block (approximately 180 days) on second or subsequent offenses. 73 | 74 | ## 15. Fair Dealing in Processing Transactions 75 | 76 | I, {{producer}}, agree to process transactions on a first-in, first-out, best-effort basis and to honestly bill transactions for measured execution time. Apparent intentional violation of the preceding, as judged by a majority of 2/3+1 of all block producers, shall be cause for my disqualification from all service as a block producer for 5,000,000 blocks (approximately 29 days) on first offence or 32,000,000 block (approximately 180 days) on second or subsequent offenses. 77 | 78 | ## 16. No Reordering Transactions to Profit 79 | 80 | I, {{producer}}, agree not to manipulate the contents of blocks in order to derive profit from the order in which transactions are included in the hash of the block that is produced. Apparent intentional violation of the preceding, as judged by a 2/3+1 majority of all block producers,shall be cause for my disqualification from all service as a block producer for 16,000,000 blocks (approximately 90 days) on first offence or 63,000,000 blocks (approximately 365 days) on second or subsequent offenses. 81 | 82 | ## 17. Ownership 83 | 84 | I, {{producer}}, hereby agree to disclose and attest under penalty of perjury all ultimate beneficial owners of my ownership entity who own more than 5% and all direct shareholders. When required by the Telos Block Producer Minimum Requirements, I shall also provide an identity verification hash from an accepted third-party identity verification service along with the name of that service. All owners of my ownership entity are listed herein:{{owner{name}, (percentage}, (idprovider}, {idhash}}. I will not misrepresent ownership or the penalty status of any owners in an attempt to evade penalties. No owner is currently under penalty for violating the human language terms of the “regproducer” contract. Misrepresentation includes misspelling or using an alternate writing of the same person or entity’s name, listing the name of an entity owned or controlled by more than 5% of a listed owner, or by listing the name of any person or entity who is not the true beneficial owner or their fiduciary. Apparent intentional violation of the preceding, as judged by a majority of 2/3+1 of all block producers, shall be cause for my disqualification from all service as a block producer for 16,000,000 blocks (approximately 90 days) on first offence or 63,000,000 blocks (approximately 365 days) on second or subsequent offenses. 85 | 86 | ## 18. Ownership of More than One Block Producer 87 | 88 | I, {{producer}}, acknowledge that no entity, whether an individual, corporation, nonprofit, or decentralized organization, shall own any interest in more than one block producer candidate at any time. For the purpose of this paragraph, spouses, parents, children and siblings of an owner shall be considered the same as the owner. Any block producer with any owner currently under penalty by the “enforcebprules” contract is disqualified for the entire term of the penalty. 89 | 90 | ## 19. Producing Blocks on Schedule 91 | 92 | I, {{producer}}, agree not to produce blocks before my scheduled time unless I have received all blocks produced by the prior producer. Apparent intentional violation of the preceding, as judged by a majority of 2/3+1 of all block producers, shall be cause for my disqualification from all service as a block producer for 5,000,000 blocks (approximately 29 days) on first offence or 32,000,000 block (approximately 180 days) on second or subsequent offenses. 93 | 94 | ## 20. Producing Blocks on Accurate Time 95 | 96 | I, {{producer}}, agree not to publish blocks with timestamps more than 500ms in the past or future unless the prior block is more than 75% full by either CPU or network bandwidth metrics. Apparent intentional or negligent violation of the preceding, as judged by a majority of 2/3+1 of all block producers, shall be cause for my disqualification from all service as a block producer for 5,000,000 blocks (approximately 29 days) on first offence or 32,000,000 block (approximately 180 days) on second or subsequent offenses. 97 | 98 | ## 21. Setting Accurate RAM Supply 99 | 100 | I, {{producer}}, agree not to set the RAM supply to more RAM than my block producing nodes can currently support. Apparent intentional violation of the preceding, as judged by a majority of 2/3+1 of all block producers, shall be cause for my disqualification from all service as a block producer for 5,000,000 blocks (approximately 29 days) on first offence or 32,000,000 block (approximately 180 days) on second or subsequent offenses. 101 | 102 | ## 22. Voter-confusing Block Producer Names 103 | 104 | I, {{producer}}, agree not to register a block producer name intended or deemed likely to create confusion among Telos voters as to their identity compared to other Telos block producers. Priority of names will be granted to the block producer candidate who first registered on the Telos network or Telos pre-launch testnet. Until the Telos network has been activated for six months, the same priority will be granted to block producer candidates who registered a block producer name during the first 30 days of the original EOS mainnet. Violation of the preceding, as judged by a majority of 2/3+1 of all block producers, shall be cause for my disqualification from all service as a block producer until a new block producer name is registered. There shall be no further penalty for this violation. 105 | 106 | ## 23. Amending “regproducer” Human-language Contract 107 | 108 | I, {{producer}}, acknowledge that the terms of this human-language contract may be amended from time to time by Telos owners voting on the “ratifyamend” contract as described in the Telos Network Operating Agreement. If I do not consent to the new terms of the amended human-language contract, I must remove my block producer candidate from service. Remaining registered as a block producer more than 180,000 blocks (approximately 25 hours) after this human-language contract is amended indicates my acceptance of the new version. 109 | 110 | ## 24. Definitions 111 | 112 | The term “block producer” shall be deemed to mean one of the up to 21 block producer candidates actually validating transactions on the Telos network, including any non-elected block producer candidate serving the validating function due to the failure of another block producer, or rotation schemes intended to aid network health, or any other reason. The term “second or subsequent offences” shall refer to violations of any offence described within the same paragraph of this human-language contract, but not to offences described in different paragraphs. A second or subsequence offence shall only apply if a majority of 2/3+1 block producers voted to impose a penalty on a previous alleged offence. A majority of “2/3+1” shall mean a number greater than or equal to 2/3rds of the total number plus one additional. For clarity, when the total is 21 block producers, a 2/3+1 majority would require the votes of 15 block producers. A “human-language contract” means the portion of a smart contract that is written in a human language such as English or Korean as opposed to a computer language such as C++, with the goal of clearly expressing the intent of the transaction between the user executing the contract and the person or entity that controls it. An “accepted third-party verification service” means a service or entity providing identification verification as a cryptographic hashed value that is listed on a list maintained on-chain by the Telos Block Producers and amended by a vote of 2/3+1 Block Producers. The “‘regproducer’ contract” means any Telos system contract or contracts that is designed to nominate an entity as a block producer candidate, whether or not the contract is actually named “regproducer”. The “‘enforcebprules’ contract” means any Telos system contract or contracts that is designed to enforce the Block Producer Minimum Requirements or “regproducer” contract, whether or not the contract is actually named “enforcebprules”. The “‘ratifyamend’ contract” means any Telos system contract or contracts that is designed to allow Telos Members to ratify or amend any of the Telos Governance Documents, whether or not the contract is actually named “ratifyamend”. The terms “‘eosio’ contract” and “system contract” mean the core operating system contract or contracts of the Telos EOSIO system, whether or not the contract is actually named “eosio”. 113 | 114 | # Copyright: 115 | 116 | This document is in the public domain. 117 | -------------------------------------------------------------------------------- /TelosOperatingAgreement.md: -------------------------------------------------------------------------------- 1 | Title: Telos Blockchain Network Operating Agreement 2 | Authors: Mark Cohen, Beth Farnham, Azad Halim, Jim Hewitt, Douglas Horn, Syed Mushabbar Sadiq, Jan Smit, Sukesh Kumar Tedla, Adam Zientarski 3 | Adoption: Unanimously Approved and Adopted by the Telos Contributors Group - October 5, 2018 17:00 UTC. | Amended by Telos Contributors Group - October 26, 2018 16:00 UTC | Amended by Telos Contributors Group - November 20, 2018 16:00 UTC 4 | Voting: 2018-10-05 Yes - 22, No - 0, Abstain - 0 | 2018-10-26 Yes - 20, No - 0, Abstain - 0 | 2018-11-20 Yes - 35, No - 0, Abstain 0 5 | 6 | # Telos Blockchain Network Operating Agreement 7 | 8 | ## 1. Preamble 9 | 10 | This document is intended to set common agreements among all users of the Telos Blockchain Network in order to establish a secure, stable, and governable blockchain where value and information can be stored and all disputes shall be arbitrated solely using the methods described herein and within the “Telos Governance Documents” comprised of this Agreement, the Telos Blockchain Network Arbitration Rules and Procedures, the Telos “regproducer” contract human language terms, the Telos “regarb” contract human language terms, the Telos Block Producer Minimum Requirements, the Telos Arbitrator Minimum Requirements and Telos Blockchain Network Data Protection Policy. Each document in the Telos Governance Documents is hereby incorporated herein by reference as if fully set forth herein. The Telos Blockchain network is comprised of Members (as defined below) who have chosen to organize themselves using a computer blockchain as a form of transnational exchange of value, information, and commerce. This network has agreed to govern the Telos blockchain, its transactions and native token by means of this Telos Blockchain Network Operating Agreement (this “Agreement”) which enumerates a set of mutual representations and agreements amongst its users. 11 | 12 | ## 2. Jurisdiction and Choice of Law 13 | 14 | The Jurisdiction of the Telos Governance Documents shall be the British Virgin Islands. The choice of law of the Telos Governance Documents shall be the laws of the British Virgin Islands. The seat of jurisdiction shall be Road Town, Tortola, British Virgin Islands. Arbitration proceedings may occur via computer network, teleconferencing or video conferencing from any geographic location pending arbitrator approval. Any person or entity who uses the Telos Blockchain Network to store, exchange, or process value or information shall be herein referred to as a “Member.” Each Member agrees to be bound exclusively by the terms of this Agreement or the most current Telos Governance Documents ratified or amended in accordance with the terms herein, and to select the terms of the current Agreement at the time of the transaction as binding in the interactions between them regarding any and all value and information stored on the Telos blockchain. It is the responsibility of each Member to abide by their local terrestrial laws and statutes. 15 | 16 | ## 3. Recording of Values and Information 17 | 18 | The Telos blockchain shall be used to record value and information and to perform computations pertaining to these. This information shall be recorded in a continuous chain of blocks of transactions and cryptographic security information (“Blocks”) which are tested and validated by computer nodes on the network (“Validating Nodes”). 19 | 20 | ## 4. Accounts 21 | 22 | Each Member may control one or more accounts on the blockchain. Accounts record the ownership of various tokens and resources and are controlled by cryptographic keys. Accounts may publish smart contracts including contracts that issue new tokens. 23 | 24 | ## 5. Native Unit of Value 25 | 26 | The native unit of value on the Telos blockchain shall be the TLOS token. Each TLOS token shall represent a percentage of the usage of the Telos blockchain shared resources in direct relation to the total number of TLOS tokens that are recorded on the blockchain. As a pro rata percentage of shared resource usage rights, each TLOS token shall entitle the account holding it to proportional voting rights and use of the Telos blockchain’s operational computer resources. 27 | 28 | ## 6. Operation and Execution of the Blockchain 29 | 30 | The Telos blockchain reaches consensus regarding the values and transactions it records using delegated proof of stake, whereby active Validating Nodes (“Block Producers”) and standby Validating Nodes (“Standby Block Producers”) are elected by the votes of the TLOS token holders to serve as delegates in the processing and validating of transactions and blocks in the blockchain according the technical specifications of the Telos branch of the EOSIO software. 31 | 32 | ## 7. Modifying the Blockchain 33 | 34 | Transactions on the Telos blockchain shall be reversible only until the Block Producers reach final consensus regarding the validity of the block containing them. Once 2/3 of the Block Producers have proposed a block to be valid and an additional Block Producer has accepted the proposed valid block, then it shall be deemed an “Irrevocable Block.” The Telos blockchain shall never amend any Irrevocable Block. Modifications to the blockchain may only be made through rejecting blocks not yet accepted as Irrevocable Blocks and through appending new information into current blocks. 35 | 36 | ## 8. Block Producer Nomination, Qualification, and Election 37 | 38 | Any Telos Member may self-nominate as a candidate to be a Block Producer by executing the “regproducer” contract and accepting its human-language terms. The Telos blockchain maintains a list of minimum requirements for acting as a Block Producer or Standby Block Producers (the “Block Producer Minimum Requirements”). The 21 block producer candidates currently in compliance with the Block Producer Minimum Requirements receiving the highest weight of Member votes shall serve as Block Producers. The 30 block producer candidates currently in compliance with the Block Producer Minimum Requirements and not serving as Block Producers receiving the highest weight of Member votes shall serve as Standby Block Producers. Enforcement of compliance with the Block Producer Minimum Requirements shall be by the “enforcebpmins” contract. 39 | 40 | ## 9. Functions of Block Producers 41 | 42 | Block Producers shall operate infrastructure in accordance with the Telos Block Producer Minimum Requirements. Block Producers are to produce blocks at their scheduled time in accordance with the human-language terms of the “regproducer’” contract. As the executive authority of the Telos blockchain, the Block Producers, in aggregate, have broad executive powers over the Telos blockchain. They may pause the Telos blockchain, implement new software updates, print new tokens, implement additional operational rules for the blockchain that do not violate the Agreement, and enforce duly processed arbitration orders by voting for any such action with a majority vote of 2/3+1 Block Producers. 43 | 44 | ## 10. Block Producer Pay 45 | 46 | Block Producer and Standby Block Producers shall be paid each day from a daily fund consisting of the daily share of 1% annual inflation (the “BP Inflation Rate”) of the entire value of the Telos blockchain as measured in TLOS tokens. Every day, this total amount shall be allocated such that each Block Producer receives the same pay for the time spent as a Block Producer as every other Block Producer and each Standby receives pay that is half of the rate of each Block Producer for its time spent as a Standby, with the provision that Block Producers and Standby Block Producers may have their daily pay allotment deducted in proportion with the percentage of blocks they were expected to produce in their most recent production period of 180,000 blocks (approximately 24 hours) or fewer, but failed to produce. Loss of pay from failing to regularly execute the “claimrewards” action, shall be borne by the Block Producer or Standby Block Producer, not the network. For blocks 1,000,001 (activation) through block 22,000,000 (approximately 122 days), the BP Inflation Rate shall be equivalent of 4% annually instead of 1%. For blocks 22,000,001 through block 43,000,000 (approximately 122 days), the BP Inflation Rate shall be equivalent of 3% annually instead of 1%. For blocks 43,000,001 through block 64,000,000 (approximately 122 days), the BP Inflation Rate shall be equivalent of 2% annually instead of 1%. 47 | 48 | ## 11. Binding Arbitrations 49 | 50 | All Members of the Telos blockchain agree to be bound to binding arbitration by Members elected by the votes of the TLOS token holders to serve this function (“Elected Arbitrators”), or by other arbitration forums that Members freely agree upon except where both parties of a transaction explicitly choose to waive such arbitration. Members expressly waive all rights to have matters pertaining to value or information stored on the Telos blockchain decided in a court of any terrestrial jurisdiction. Any dispute arising out of or in connection with this Agreement, including any question regarding its existence, validity or termination, shall be referred to and finally resolved by arbitration by one or more Telos Elected Arbitrators in accordance with the Arbitration Rules of the Telos Blockchain Network Arbitration Rules and Procedures for the time being in force, which rules are deemed to be incorporated by reference in this clause. Other arbitration forums may be used under that forum’s rules when freely selected by both parties at the time of contract execution, and when the dispute does not question the existence, validity, or termination of this Agreement. Any dispute questioning the existence, validity, or termination of this Agreement must be resolved by arbitration by one or more Telos Elected Arbitrators in accordance with the Arbitration Rules of the Telos Blockchain Network Arbitration Rules and Procedures for the time being in force, which rules are deemed to be incorporated by reference in this clause. 51 | 52 | ## 12. Arbitration Exclusions 53 | 54 | Waiving of arbitration waives all forms of dispute resolution; it does not invite terrestrial jurisdictions to arbitrate transactions on the Telos blockchain. Neither Elected Arbitrators nor Block Producers are required by this Agreement to fulfill the orders of any terrestrial jurisdictions in the operations of the Telos blockchain. 55 | 56 | ## 13. Selection of Arbitration Forum 57 | 58 | The parties to each transaction on the Telos blockchain may select an arbitration forum when each party freely elects to use the same arbitration forum. If no election for a common alternative forum is so recorded in the transaction, then the arbitration forum shall be the Elected Arbitrators. 59 | 60 | ## 14. Elected Arbitrator Nomination, Qualification, and Election 61 | 62 | Any Telos Member may self-nominate as a candidate to be an Elected Arbitrator by executing the “regarb” contract and accepting its human-language terms. The Telos Blockchain maintains a list of minimum requirements for acting as an Elected Arbitrator (the “Arbitrator Minimum Requirements”). The number of Elected Arbitrators at any time and the method for deciding the terms under which some number of Elected Arbitrators will be assigned to each arbitration case shall be decided by the most recent 2/3+1 vote of all Block Producers to accept the current Telos Arbitration Parameters Schedule. Arbitrator candidates shall be elected over a voting period of 5,000,000 blocks (approximately 29 days), except that the first election of arbitrator candidates shall be over a voting period of 5,000,000 blocks (approximately 29 days) immediately after chain activation but also including any votes cast in the period prior to activation. Any Member who registers his or her accounts as voters may cast their vote of either “Yes”, “No”, or “Abstain” for each individual arbitrator candidate. At the completion of the voting period, votes shall be tallied based on the current amount of staked TLOS tokens in each users’ account and the total number of “No” votes shall be subtracted from the total number of “Yes” votes that each arbitrator candidate received to yield “Net Yes Votes” as measured in voted TLOS tokens. Any arbitrator candidate who has received at least 20,000 TLOS worth of Net Yes Votes is eligible for election. The arbitrator candidates eligible for election who have received the highest numbers of Net Yes Votes, up to the maximum number of Elected Arbitrators set by the Block Producers in the current Telos Arbitration Parameters Schedule minus the number of Elected Arbitrators who will be serving at the completion of the current voting period, shall become Telos Elected Arbitrators. Elected Arbitrators shall serve a term of 180,000,000 blocks (approximately three years) and may be re-elected for up to ten terms in total. Enforcement of compliance with the Elected Arbitrator Minimum Requirements shall be by the “enforcearb” contract or one otherwise named but with this function, or by the signature of three Elected Arbitrators. 63 | 64 | ## 15. Arbitration Rules and Procedures 65 | 66 | The Telos Blockchain Network Arbitration Rules and Procedures document describes the rules and procedures for arbitration. 67 | 68 | ## 16. Freezing Accounts Under Arbitration 69 | 70 | Upon assignment of an Elected Arbitrator(s) to an arbitration case, any Assigned Arbitrator may issue an emergency order to freeze all transactions from the Respondent account or accounts as an interim measure which preserves the status quo and preserves assets. The Assigned Arbitrator may add the account to a list of frozen accounts (the “Telos Blacklist”) maintained on the Telos blockchain, which all Block Producers shall reference and exclude from validating transactions, or by instructing the Block Producers to nullify the keys of the Respondent account or accounts. 71 | 72 | ## 17. Execution of Arbitration Decision 73 | 74 | An Assigned Arbitrator(s) in a case shall render their arbitration Decision in the form of a transaction or set of transactions to be appended to the Telos blockchain by the duly elected Block Producers at the time the Decision is rendered. The transactions shall be in the form of a standard value transfer transaction from Respondent to Plaintiff, a “revisecontract” action which forcibly adjusts the code of a faulty or misleading contract, or a “changekeys” action which assigns new private keys to an account that has been adjudicated to have been improperly acquired by Respondent from Plaintiff. The Assigned Arbitrator(s) shall also provide a public explanation of the rationale for the Decision. The arbitration Decision may include transactions to pay the arbitration Fee associated with the case. 75 | 76 | ## 18. Enforcement of Arbitration Decisions 77 | 78 | Block Producers, having been duly provided with a valid arbitration Decision as defined in the Telos Blockchain Network Arbitration Rules and Procedures document, shall fully enforce the Decision within 180,000 blocks (approximately 24 hours) of receipt. Every Block Producer shall be required to enforce the action and any Block Producer that has not enforced the action within 180,000 blocks (approximately 24 hours) shall be liable for penalty under the “enforcebpmins” action until the adjudication action is fully enforced. 79 | 80 | ## 19. Restrictions on the Use of Sudo Powers 81 | 82 | The Block Producers have the authority to use the “sudo” command to execute commands on an account as if by the owner, or a similarly-powered “super user” command if under a different name, only as an element of the “revisecontract” action which forcibly adjusts the code of a faulty or misleading contract, or a “changekeys” action which assigns new private keys to an account that has been adjudicated to have been improperly acquired, and only in cases of an adjudication Decision entered by an Assigned Arbitrator(s) in due process of a bona fide arbitration case. In the event that a Block Producer becomes aware of an apparent theft in action, that Block Producer may use sudo powers to freeze an account for up to 180,000 blocks (approximately 24 hours). After this time, the sudo freezing action shall expire or be removed by the Block Producer unless an Elected Arbitrator issues an order extending the freeze action. 83 | 84 | ## 20. Voting 85 | 86 | Telos Members may vote to elect block producer and arbitrator candidates as described in this Agreement. Each Member may vote the entire number of staked TLOS tokens in any account they control via private keys. Members may vote for up to 30 block producer candidates at any time and each vote for any candidate will share the same weight as that of all the other candidates. All votes, whether cast directly or by Proxy shall have their voting weight reduced according to a non-linear equation known as inverse-weighted voting, as expressed in the Telos code, whereby the value of a vote is reduced when fewer than the maximum amount of allowed candidates are cast. 87 | 88 | ## 21. Proxies 89 | 90 | Members may delegate their votes to another Member as a voting proxy (“Proxy”) using the “proxy” contract included in the EOSIO software. Only a token’s true beneficial owner or a voting Proxy recorded on the blockchain may vote tokens. Any Member holding tokens in trust for another beneficial owner, such as a centralized exchange, may not cast votes for or assign to a Proxy such tokens. 91 | 92 | ## 22. Initial Token Allocation 93 | 94 | The initial distribution of TLOS tokens on the Telos network (“Telos Initial Distribution”) will follow the EOS ERC-20 token snapshot as recorded June 2, 2018 from records of the EOS token sale as recorded on the Ethereum blockchain (the “EOS Snapshot”) on a 1:1 basis. The Telos Initial Distribution will create all accounts that were included on the EOS Snapshot with the same account names and public keys that match except that the prefix “TLOS” may be used instead of “EOS”. These accounts will each be recorded as having the same number of TLOS tokens as the number of EOS on the corresponding account in the EOS Snapshot, except that each account that has a balance of over 40,000 tokens will receive exactly 40,000 TLOS tokens. EOS token holders who provide cryptographically signed messages requesting new keys for their accounts in the publicly documented process shall have their keys changed up until the time of network launch. New Telos accounts will be created to fund the Telos Foundation which will receive 6,000,000 TLOS tokens, the Telos Founders’ Rewards Pool which will receive 18,000,000 TLOS tokens, the Telos Community Rewards Pool which will receive 1,000,000 TLOS tokens, and the Telos Exchange Token Reserve Fund which will receive 140,279,973 TLOS tokens, and 25,000 TLOS tokens to provide the initial account creation distribution. No value was accepted in exchange for tokens in the Telos Initial Distribution. 95 | 96 | ## 23. Requirement to Opt-in as a Member 97 | 98 | The Telos Initial Distribution will include all accounts from the EOS Snapshot. However, it is unknown which EOS Snapshot account owners may wish to opt in and become Members of the Telos network. Because all token holders must agree to become Members by accepting the mutual representations of this Agreement, accounts that have no transactions 63,000,000 blocks (approximately 365 days) after the activation of the Telos network are subject to deletion by the Block Producers at that time or in the future, provided no transactions have yet been made. Tokens in any deleted accounts will be deleted from the blockchain. 99 | 100 | ## 24. Worker Proposal Fund 101 | 102 | A value equal to the daily share of 1.5% annual inflation of the entire value of the Telos blockchain as measured in TLOS tokens shall be deposited to an account on the Telos Network with the account name of “eosio.savings” (the “Worker Proposal Fund”) each day. 103 | 104 | ## 25. Worker Proposal Submission 105 | 106 | After the total amount of TLOS tokens registered to vote exceeds 1% of the total TLOS supply, any Telos Member or group of Members may submit proposals for the usage of these accumulated funds by executing the “submission” action of the “workerproposal” contract (the “Proposer”) and providing the required information including, at least, a full description of the proposal, a link to a fixed source of information, and the exact deposit transaction, including deposit account or accounts, that will occur should the proposal be accepted by the Telos Members. 107 | 108 | ## 26. Worker Proposal Voting Period 109 | 110 | Once a proposal is submitted, there will be a period of 5,000,000 blocks (approximately 29 days) in which a proposal may be voted (the “Voting Period”). 111 | 112 | ## 27. Worker Proposal Submission Fee 113 | 114 | A submission fee of 3% of the requested amount with a minimum of 50 TLOS will be required as part of the submission. The fee shall be refunded to the Proposer if the worker proposal reaches a minimum threshold of 20% YES vote amongst all votes and a minimum voting total (YES or NO) of at least 0.1% of all TLOS tokens at the end of the Voting Period. 115 | 116 | ## 28. Passage of a Worker Proposal 117 | 118 | Any Worker Proposal that receives a simple majority of YES votes and a minimum threshold of 5.0% of votes from all votable TLOS tokens at the conclusion of the Voting Period shall be an “Accepted Proposal.” 119 | 120 | ## 29. Execution of a Worker Proposal 121 | 122 | Each Accepted Proposal shall have the transaction described in the proposal execute immediately, provided sufficient funds exist in the Worker Proposal Fund account. If sufficient funds do not exist, transactions from Accepted Proposals will be queued to execute as soon as the Worker Proposal Fund account accumulates sufficient funds, in the order accepted. Accepted Proposals that include multiple cycles will recalculate the total votes and percentage tally at the beginning of each new cycle of 5,000,000 blocks (approximately 29 days). Proposals that continue to qualify will again be funded at the beginning of the new cycle. Proposals that no longer qualify will not be paid for that cycle, but may be paid in a future cycle, up to the number of cycles listed in the initial proposal. Voters may change or withdraw their vote from any proposal at any time. 123 | 124 | ## 30. Failure to Provide Worker Proposal Deliverables 125 | 126 | The Block Producers may, by 2/3+1 majority vote, elect to file an arbitration case against the Proposer on behalf of the Worker Proposal Fund account to reclaim some or all of the disbursed funds from an Accepted Proposal that has been executed, but where the proposed work appears not to have been performed as described in the Proposal. The arbitration will proceed with Telos Elected Arbitrators and any Decision will be transmitted to the Worker Proposal Fund account. 127 | 128 | ## 31. No Fiduciary 129 | 130 | No Member shall have fiduciary responsibility to support the value of the TLOS token. The Members do not authorize anyone to hold assets, borrow, nor contract on behalf of the Members collectively. The Telos Blockchain Network has no owners, managers nor fiduciaries. 131 | 132 | ## 32. Publication to the Telos Blockchain 133 | 134 | Each Member grants all other Members an irrevocable license to view transactions as recorded and published to the blockchain. 135 | 136 | ## 33. Responsibility for Information 137 | 138 | The Telos Network shall bear no responsibility or enforcement role for any information, data, or content improperly recorded on the blockchain. Any penalties or Decisions for improperly recorded information, data, or content shall be the sole responsibility of the Member that posted it. 139 | 140 | ## 34. Restitution 141 | 142 | Each Member agrees that penalties for breach of this contract may include, but are not limited to, fines, loss of account, and any other measures decided by Elected Arbitrators as defined in this Agreement. 143 | 144 | ## 35. Developers 145 | 146 | Each Member who makes available a smart contract on the Telos blockchain (a “Developer”) may designate original elements of their contracts as either open source or proprietary code. Each smart contract shall be documented with human-language terms stating the intent of all parties and naming the arbitration forum that will resolve disputes arising from that contract. Developers who designate contracts as proprietary code may claim that code as intellectual property and may initiate arbitration actions against those who violate their control of their intellectual property for restraint and/or restitution. 147 | 148 | ## 36. Prevailing Language 149 | 150 | The Developer of a contract may offer its human-language terms in multiple language translations. When human-language terms are available in more than one language, the Member executing the contract may select the translation that they wish to execute. The human language of the terms that was provided by the Developer and selected by the Member executing the contract will prevail where there are ambiguities between this version of the terms and other versions. In scenarios where the contract language or contract selection by the Member is ambiguous, the Elected Arbitrator will have the authority to select the contract used in the dispute. 151 | 152 | ## 37. Recording of Agreement 153 | 154 | The text of this Agreement or the most currently ratified or amended version of the Agreement shall be recorded on the Telos blockchain and after at least every 200,000 blocks a pointer to the block containing the text of this Agreement shall be included in the block. Validating any block shall be deemed a further acceptance of all terms of this contract. 155 | 156 | ## 38. Amending 157 | 158 | The Telos Governance Documents may be amended by a vote of the TLOS token holders using the “ratifyamend” contract. To ratify or amend any Telos Governance Document, any user may execute the “ratifyamend” contract, paying its contract fee of 700 TLOS (the “Ratify/Amend Contract Fee”), which may be returned if the contract receives a minimum of 1% of votes from all TLOS voters. This fee may be paid by one Member or collected from many Members over time to execute when the full cost has been collected. Once the fee has been fully paid, the full text of the proposed new document, or the existing document in the case of ratification, shall be recorded to the Telos blockchain. No Telos Governance Documents shall be ratified or amended except by a vote of the TLOS token holders, as recorded by the “ratifyamend” contract with no less than 15% vote participation among votable TLOS tokens and no fewer than 10% more Yes than No votes, at the end of a 5,000,000 block voting period (approximately 29 days). 159 | 160 | ## 39. Severability 161 | 162 | If any part of this Agreement is declared unenforceable or invalid, the remainder will continue to be valid and enforceable. No part of this Agreement is to be given higher importance than any other due to its ordinal position within the document. 163 | 164 | ## 40. Termination 165 | 166 | A Member is automatically released from all revocable obligations under this Agreement three years after the Member has sold or otherwise relinquished all TLOS tokens. Any arbitration cases already filed against the Member shall proceed and the Decision shall be enforced. Valid arbitration Decisions entered against a Member shall persist indefinitely in case the Member once again interacts with the network. 167 | 168 | ## 41. Developer Liability 169 | 170 | The Telos Blockchain Network uses “Free and Open Source Software” defined as software which has been authored by single or separate authors who do not retain proprietary ownership to said software and make its source code freely available on a public repository. Members agree to hold Developers of all open source software exempt of liability for mistakes, errors, or breach of contract made in the expression of contractual intent, whether or not said mistakes were due to actual or perceived negligence. 171 | 172 | ## 42. Telos Contributors Liability 173 | 174 | The Telos Blockchain Network is a pioneering project in the area of blockchain creation, organization, and governance for which few, if any, precedents exist. Members hereby agree to release, discharge, fully indemnify and forever hold all Members who contributed to the pre-network-activation concept generation and development, code development, network operations, communications, promotion, administration, organization, governance document writing, reviewing, amending, debate and acceptance, or any other task prior to network activation organized in conjunction with the developers modifying the computer code that became the Telos Blockchain Network and/or as evidenced by participation in the Telos Founders Rewards Pool (the “Telos Contributors”), harmless from any and all claims, demand, or suits, known or unknown, fixed or contingent, liquidated or unliquidated, arising from or related to any event or transaction related to the ideation, creation, launch, activation, or ongoing operation of the Telos Blockchain Network and expressly including those in which it is asserted or found that a Member was negligent in any way in these actions. All such releases, limitations of liability, limitations on joinder and witness status, and hold harmless provisions in this paragraph shall inure and run to the benefit of any firms, entities, partnerships, corporations, heirs, assigns, limited liability partnerships, agents and legal representatives of the Telos Contributor or with which the Telos Contributor is involved in any business or financial capacity, including, but not limited to, involvement as a member, partner, shareholder, agent or principle; and such releases, limitations of liability, limitations on joinder and witness status, and indemnification and hold harmless provisions in this paragraph are given in consideration of the premises, use of the Telos Blockchain Network, the agreed significant benefits of having created and launched the Telos Blockchain Network through the contributions of the Telos Contributors, all of which the Telos Blockchain Network and its Members agree is good and valuable consideration for the releases and limitations set out herein. The specific and express intent of the Telos Blockchain Network and its Members, as well as the specific and express intent of the language in this paragraph, is to ensure that no Telos Contributors shall ever have any liability whatsoever to any person or entity for their contributions to or operation of the Telos Blockchain Network or for any act, omission or error related in any way to such contributions or operations. The protections granted to Telos Contributors by this paragraph will persist even if this paragraph is amended in the future. 175 | 176 | ## 43. Grammar 177 | 178 | Any noun in this document used in the singular form shall also apply in the plural form and vice versa. Likewise, any masculine or feminine reference shall also apply in the opposite gender or neutral tense. 179 | 180 | ## 43. Resource Exchange 181 | 182 | Upon a 2/3+1 majority vote by the then current Block Producers to do so, computer code and/or contracts enabling a “Resource Exchange” for staking an account’s system resources to a common exchange which leases or rents out said resources to others for a fee (even a zero value fee) and disburses said fees to all resource-staking Members in return for an equal percentage of network income from RAM transaction fees, name bidding fees, or any other fee for commonly owned or managed Telos resources shall be implemented in the Telos Blockchain Network computer code and/or contracts. The form of this Resource Exchange may be modified or removed in the future upon a 2/3+1 majority vote by the then current Block Producers. 183 | 184 | ## 44. Consideration 185 | 186 | All rights and obligations under this Agreement are mutual and reciprocal and of equally significant value and cost to all parties. 187 | 188 | ## 45. Acceptance 189 | 190 | A contract is deemed accepted when a Member signs a transaction which incorporates a Transaction as Proof of Stake (TAPOS) proof of a block whose implied state incorporates an Application Binary Interface (ABI) of said contract and said transaction is incorporated into the blockchain. 191 | 192 | ## 46. Counterparts 193 | 194 | This Agreement may be executed in any number of counterparts, each of which when executed and delivered shall constitute a duplicate original, but all counterparts together shall constitute a single agreement. 195 | 196 | ## 47. Complete Agreement 197 | 198 | This Agreement is accepted as complete and needs no further ratification to be valid and enforceable. A method for ratifying this Agreement has been included in the Agreement and Telos network code in the form of the “ratifyamend” contract, however, such ratification is not required for this Agreement to be enforceable and in the event the “ratifyamend” contract is executed, a failure to successfully ratify the Agreement does not nullify the acceptance, validity, or enforceability of this Agreement. 199 | 200 | 201 | # Copyright: 202 | This document is in the public domain. 203 | 204 | 205 | --------------------------------------------------------------------------------