Skip to content

Latest commit

 

History

History
339 lines (218 loc) · 37.4 KB

constitution.md

File metadata and controls

339 lines (218 loc) · 37.4 KB

We, the Contributors to Pocket Network, are united together in the mission to build censorship-resistant technology that will lay the foundation for reorganizing the world’s institutions towards a more equitable, hyper-connected, interplanetary future.

Principles

  1. Credible Neutrality: No one User should be favored over any other within their demographic. For example, Protocol Upgrades which favor Nodes over Apps are neutral, but Protocol Upgrades which favor specific App types (e.g. exchanges) or specific Apps (e.g. Binance) are not neutral.
  2. Sustainable Decentralization: Pocket Network should optimize for as many sovereign Nodes as possible, because this reinforces the resilience and censorship-resistance of the service, but this should not be rushed at the cost of the sustainable growth of Pocket Network.
  3. User-Centrism: Pocket Network is specialized to provide reliable decentralized infrastructure to Users. We must therefore continue to optimize for 1) User adoption and 2) the qualities that contribute to reliable infrastructure: network redundancy, robust data integrity, data sovereignty, minimal latency, minimal downtime, and minimalist engineering.
  4. Freedom of Movement: Entry to Pocket Network should be accessible to both Apps and Nodes. Equally, all Pocket Network stakeholders should enjoy the right to exit.
  5. Optionality: Operating a Node should incur no more costs than the cost of operation. All other responsibilities, e.g. participation in the Council, should be optional.
  6. Agnosticism: Pocket Network should maintain neutrality as a middleware protocol. While the governance of Pocket Network may be reliant from time to time on other networks or tools, the system itself should retain a level of modularity that facilitates switching out components with minimal friction.
  7. Cross-Chain Diplomacy: Pocket Network is a middleware protocol, which means our community will come from a wide range of blockchain communities. DAO participants must leave tribalism at the door; they should refrain from engaging in political debates that are not directly relevant to improving the service that Pocket Network provides.
  8. Consensual Collaboration: While the Pocket Network Council is relatively permissionless, this does not mean anyone is entitled to work. Proposals will be assessed on their merits alone, including Contributors’ fitness to fulfill the proposal. Likewise, Contributors are not required to let any other Contributor work with them, unless the Council has approved a proposal to that effect.
  • The Principles are ranked in order of priority.
  • Decisions must be made according to their furtherance of the Principles.
  • When deciding between alternatives, these alternatives shall be prioritized according to the ordering of the Principles listed above, with higher-ranking Principles to always take priority over lower-ranking Principles.
  • Lower-ranking Principles should only be sacrificed in favor of higher-ranking Principles if a Pareto optimal state has been achieved, i.e. it is not possible to improve one Principle without making another Principle worse off. Until then, the Council shall seek to make only Pareto improvements, where Principles are improved without making any other Principles worse off.
  • Once it is no longer possible to optimize any Principle without sacrificing another, this Constitution should be amended to introduce minimum satisfaction thresholds on each Principle.
  • Stakeholder rights at any given moment, as defined by the values of On-Chain parameters, may justifiably be sacrificed in the furtherance of the Principles, because it is intended that the Principles, if achieved, will ensure maximum utility to maximum stakeholders.
  • The Principles should be designed, in all future iterations of this Constitution, to optimally achieve the mission of Pocket Network, which is defined in the first line of this Constitution.

Statutes

1. Interpretation

1.1. This Constitution does not take precedence over the consensus rules defined by Pocket Core. If there is any conflict or inconsistency between this Constitution and the consensus rules, the consensus rules shall prevail.

1.2. This constitution shall be enforced according to de jure interpretations of the Statutes (the letter of the constitution), except in the case of amendments to the Constitution or Pocket Core’s consensus rules, in which case they shall be enforced according to de facto interpretations of the Principles (the spirit of the constitution).

1.3. Where it concerns de jure interpretations of the Statutes, any rule of construction to the effect that ambiguities are to be resolved shall not be applied in the construction or interpretation of this Constitution. This Constitution constitutes the entire agreement between the Parties with respect to the subject matter hereof and supersedes all prior agreements and understandings, both written and oral, between the Parties with respect to the subject matter hereof.

2. Enforceability

Informed Consent

2.1. Use of Pocket Core shall constitute consent to the terms of its consensus rules, including the mechanisms by which Validator Nodes, on behalf of all Users, accept Governance Transactions made by the Council and/or the Foundation in accordance with the processes outlined in this Constitution.

2.2. Entry into the Council shall constitute consent to the terms of this Constitution.

2.3. In the event that an attempt is made by the Council or the Foundation to modify this Constitution or Pocket Core's consensus rules, consent may be revoked through exiting or forking, but will be immediately reinstated upon continued use of the blockchain, unless such use is required to facilitate exiting or forking.

2.4. All service providers who stake or sign transactions on behalf of Users, or develop tools to facilitate staking or signing by Users, shall make every effort to inform said Users of this Constitution's terms. Service providers shall be liable for losses resulting from failure to do this.

Severability

2.5. In the event any one or more of the provisions of this Constitution is for any reason held to be invalid, illegal or unenforceable, in whole or in part or in any respect, or in the event that any one or more of the provisions of this Constitution operate or would prospectively operate to invalidate this Constitution, then and in any such event, such provisions only will be deemed null and void and will not affect any other provision of this Constitution and the remaining provisions of this Constitution will remain operative and in full force and effect and will not be affected, prejudiced, or disturbed thereby.

Counterparts

2.6. This Constitution may be executed in one or more counterparts, all of which shall be considered one and the same instrument and shall become effective when one or more counterparts have been signed by each of the Parties hereto and delivered to the other Parties hereto (or as published by the DAO on the Designated Blockchain or through other electronic means reasonably sufficient to notify each and all of the Parties hereto concurrently); it being understood and agreed that all Parties hereto need not sign the same counterpart. A signature may be electronic, provided that it complies with the U.S. federal ESIGN Act of 2000. All of the counterparts will together constitute one and the same instrument and each counterpart will constitute an original of this Constitution.

Notice

2.7. Any notice required or permitted by this Constitution will be deemed sufficient when published on the Designated Blockchain or through other electronic means reasonably sufficient to notify each and all of the Parties hereto concurrently.

3. Arbitration

3.1. Unless otherwise stated in this Constitution, any controversy between members of the Council (Voters) arising out of or in connection with this Constitution shall be submitted to Aragon Court for resolution under its public arbitration rules, as amended from time to time.

3.2. Controversies arising out of or in connection with actions that are bound programmatically to this Constitution, meaning they are made disputable by Aragon Agreements, must be submitted before the action executes On-Chain; if not, the action is irreversible and the controversy shall be deemed resolved in favor of the action.

3.3. In the event that Aragon Court is not accessible, or actions cannot be directly submitted On-Chain by Voters, the Pocket Network Foundation will interpret and rule on any disputes that are raised by any Voter. If the Foundation’s ruling does not satisfy a Voter, they may formally request that the Foundation refer the dispute to the International Chamber of Commerce for arbitration according to their rules.

3.4. By consenting to this Constitution, all Parties waive their right to resolve any controversy in any manner other than defined in this Constitution. EACH PARTY HEREBY IRREVOCABLY WAIVES ALL RIGHT TO TRIAL BY JURY IN ANY ACTION, PROCEEDING OR COUNTERCLAIM WHETHER BASED ON CONTRACT, TORT OR OTHERWISE ARISING OUT OF OR RELATING TO THIS CONSTITUTION, THE DAO, OR THE MATTERS CONTEMPLATED HEREBY OR THE ACTIONS OF SUCH PARTIES IN THE NEGOTIATION, ADMINISTRATION, PERFORMANCE AND ENFORCEMENT HEREOF.

4. Powers

Legislature

Claiming Voting Permissions

4.1. Votes are inalienable rights claimable once by any User who qualifies as a Stakeholder, by reaching the required levels in the POKT Arcade community onboarding game, and also validates their Personhood, by using the Council’s chosen anti-sybil mechanism.

Submitting Actions

4.2. To initiate any Governance Transaction, Users must be Voters and stake the required collateral.

Removing Voters

4.3. Voters can be removed for 5 violations of this Constitution. A Voter’s violation count is inclusive of:

  • settlements = 0.5 violations
  • lost Aragon Court rulings = 1 violation
  • violation of Principles = 2 violations, where an action will qualify as violating the Principles if it is successfully challenged on such grounds by any other member of the Council using Aragon Agreements, and a vote in favor of an action will retroactively qualify as violating the Principles if deemed so by Supermajority Approval in a Signaling Vote.

4.4. Voters who were removed will not be permitted to re-join unless they first successfully achieve Supermajority Approval in a Signaling Vote.

Executive

Pocket Network Foundation (Foundation)

The Role of the Foundation

4.5. The Foundation's objectives are to:

  • Steward Pocket Network
  • Hold legal custodianship of Pocket Core
  • Request funds from the Council for specific projects that have strategic value to the Pocket Network ecosystem, by submitting PEPs.
The Council’s Control of the Foundation

4.6. The Council's control of the Foundation is hard-coded into the Articles of Association of the Foundation, which separates the powers of all Foundation agents and defers those powers to the Council:

  • Directors/Supervisors are appointed/removed by each other on behalf of the Council
  • Directors must resign from other positions of authority in the Council (except Voter)
  • Supervisors ensure that Directors comply with the articles
  • No Supervisor decision is valid without Council approval.

4.7. New Directors/Supervisors will be appointed/removed according to PIPs approved by the Council.

Transparency

4.8. The Foundation's Articles compel the agents of the Foundation to give full notice to the Council concerning:

  • Any appointment/removal of Alternate Directors and/or Secretaries
  • Any resignations of Directors and/or Supervisors
Right to Refuse

4.9. The Directors and Supervisors of the Foundation can refuse the Council's decisions subject to the limitations imposed on them by the law and their duty to steward Pocket Network. If they refuse without cause, the Council may remove them.

Qualified Code Deference and the Foundation's Custodial Rights & Responsibilities

4.10. The Foundation shall serve as a custodial entity for Pocket Network, deferring decision-making to the Council in all cases except Material Adverse Exception Events (MAEEs), i.e. crises resulting from incomplete contracts and unforeseen events.

4.11. MAEEs may include:

  • the DAO having become inoperable, inaccessible or unusable, including as the result of any code library or repository incorporated by reference into the DAO or any other smart contract or oracle program on which the DAO depends for any of the Legislature, Judiciary, or Executive functions, having become inoperable, inaccessible or unusable or having itself suffered a MAEE, mutatis mutandis;
  • a material and adverse effect on the use, functionality or performance of the DAO as the result of any bug, defect or error in the DAO or the triggering, use or exploitation (whether intentional or unintentional) thereof (it being understood that for purposes of this clause, a bug, defect or error will be deemed material only if it results in the unauthorized use of accounts within the Legislature, Judiciary, or Executive functions (which therefore have power over Governance Transactions), or the unauthorized alteration of the permissions/powers (e.g. voting weights) of the aforementioned accounts);
  • any unauthorized use of an administrative function or privilege of the DAO, including: (A) any use of any administrative credential, key, password, account or address by a Person who has misappropriated or gained unauthorized access to such administrative credential, key, password, account or address or (B) any unauthorized use of an administrative function or privilege by the permission holder or representative of the permission holder (including Foundation Directors and their proxies);
  • reasonable suspicion that any smart contract or oracle on which the DAO depends, for any of the Legislature, Judiciary, or Executive functions, e.g. Aragon Court, is incentive-compromised, evidenced by the presence of all of the following factors: the total value of assets securing that smart contract or oracle (e.g. stakes) being surpassed by the value of the DAO's treasury or Pocket Network’s market cap, an abnormal (and unreversed) change in the total value of assets (or ownership distribution of assets) of that smart contract or oracle, and the submission of a proposal that alters the Constitution or Pocket Core’s consensus rules;
  • the DAO or the Foundation (as the DAO's executor) being subject to a Legal Order that prohibits the DAO (or that, if the DAO were a Person, would prohibit the DAO) from executing any function or operation it would otherwise reasonably be expected to execute; or
  • any other unforeseen events resulting in unauthorized or unintended alterations to the checks and balances outlined in '4. Powers'.

4.12. If any User becomes aware that there is a MAEE, such User (the "Sending Party") shall deliver to the Foundation a notice (an "Exception Notice") signed by such User:

  • Certifying that the Sending Party believes in good faith that there is a MAEE;
  • Describing in reasonable detail the events, facts, circumstances and reasons forming the basis of such belief;
  • Containing a representation by the Sending Party, made to and for the benefit of the Foundation with the understanding that the Foundation will rely thereon, that, to the Sending Party’s knowledge, the certification and statements made pursuant to the preceding clauses are accurate as of the date of the Exception Notice, and, considered collectively, do not contain any untrue statement of a material fact or omit to state any material fact necessary in order to make such statements, in light of the circumstances in which they were made, not misleading.

4.13. If the Foundation disputes the existence of a MAEE, then the Foundation shall promptly deliver a written notice of such non-acceptance, an "Exception Response Notice", to the Sending Party. The Exception Response Notice shall include the same categories of information, statements, evidence and representations and warranties as would be required for an Exception Notice, mutatis mutandis. The Sending Party may then lodge a complaint against the Foundation to the Cayman Island Summary Court. The decision resulting from the following court proceedings shall be non-appealable, binding and conclusive upon the Foundation and the Users of Pocket Network.

4.14. If the Foundation agrees with the contents of the Exception Notice, upon receiving an Exception Notice, the Foundation shall deposit the DAO's funds into a multi-signature account owned by all of the Directors of the Foundation, to be treated, to the extent permitted by applicable Legal Requirements, as a custodial trust held for the benefit of the DAO, until the Council enters into an Exception Handling Addendum.

4.15. After depositing the funds into the trust, the Foundation must then within 14 days (unless 4.22 applies) publish a planned response to the MAEE (an "Exception Handling Proposal"):

  • Describing in reasonable detail a proposal by the Foundation of the actions to be taken, the agreements to be entered into, and the remedies to be sought by the Users involved;
  • Including copies of any written evidence or other material written information, and summaries of any other evidence, relevant to, and material for the consideration of, the MAEE and the other matters referred to in the Exception Notice.

4.16. If the Foundation fears that details of the MAEE may be exploited and cause further harm to Users, they may do any of the following:

  • Publish their Exception Handling Proposal to a private channel containing only Voters;
  • Publish an Exception Handling Proposal that excludes exploitable details, to be followed by publication of such details only when the fix is ready to be deployed;
  • Secretly deploy fixes to the MAEE, only if such fixes do not amend Pocket Core’s consensus rules or undermine practical adherence to this Constitution, and under the understanding that such fixes may be replaced by the Council once the MAEE has been resolved.

4.17. The term "Exception Handling Addendum" refers to an addendum to this Constitution setting forth the agreement on the existence or non-existence of a MAEE and the actions to be taken, the agreements to be entered into, and the remedies to be sought in response thereto. An Exception Handling Proposal shall become an Exception Handling Addendum once a majority (50%) of the pre-crisis Council (Voting Tokens claimed prior to the submission of the Exception Notice) has signaled approval of the Proposal. Each Exception Handling Addendum shall automatically and without further action of the Council or Foundation be deemed incorporated into and to form a part of this Constitution.

4.18. Once the Foundation has executed on the Addendum and the MAEE is resolved, the Foundation shall return all funds in the custodial trust to a protocol-owned DAO account. If the Foundation neglects to return the funds within 14 days, any member of the Council may lodge a complaint against the Foundation to the Cayman Island Summary Court. The decision resulting from the following court proceedings shall be non-appealable, binding and conclusive upon the Foundation and the Users of Pocket Network.

4.19. If the Council disputes the existence of a MAEE, or does not wish to accept all or any part of the Foundation's Exception Handling Proposal, then the Council may simply reject the proposal. If after 14 days less than 50% of the Council have signaled support of the Proposal, and the Foundation refuses to return the DAO's funds to the original account, any member of the Council may lodge a complaint against the Foundation to the Cayman Island Summary Court. The decision resulting from the following court proceedings shall be non-appealable, binding and conclusive upon the Foundation and the Users of Pocket Network.

Access Control List (ACL)

Extensibility, Automation & the Signaling Era

4.20. The Foundation multi-sig will hold all ACL permissions at launch, but the Council may work to automate (and thus disintermediate) the Executive function by building a cross-chain integration between Pocket Network and the Council's Aragon Agent (or a similar smart contract representative). The period before automatic cross-chain execution is achieved will be referred to as the Signaling Era.

Executive Veto During & After the Signaling Era

4.21. During the Signaling Era, the Foundation will retain a veto on all Governance Transactions as a failsafe. This veto falls within their Right to Refuse as part of their duty to steward Pocket Network.

4.22. After the Signaling Era, the Foundation will still retain the right to veto (and the responsibility to sign) Governance Transactions that may involve parties who have not consented to this Constitution per ‘Informed Consent’. Before the Signaling Era officially ends, mechanisms must be developed that enable the Foundation to execute their custodial responsibilities in response to MAEEs, per ‘Qualified Code Deference and the Foundation's Custodial Rights & Responsibilities’.

Transaction Batching

4.23. By default, the Foundation will batch Governance Transactions on a weekly basis, unless an alternative schedule is specified in this Constitution.

Judiciary

4.24. Any Voter can challenge Governance Transactions, if they think the transaction violates this Constitution, and offer a settlement up to the amount staked by the submitter of the transaction. The submitter of the transaction can then choose to either accept the settlement, cancelling the transaction, or stake more collateral to raise a dispute. The outcome of disputes under this Judiciary function will be determined per ‘3. Arbitration’.

Citizens

4.25. As the actors responsible for transaction finalization in Pocket Core, Validator Nodes have the power to overthrow the government apparatus of Pocket Network (outlined as the above Legislature, Executive, and Judiciary functions). They are trusted to represent the citizenry (Users) of Pocket Network because their Block Reward is tied directly to the number of relays being processed for developers (i.e. User usage). The Council must never approve Protocol Upgrades that would decouple this incentive alignment.

5. Liability

5.1. The Foundation is a distinct legal entity representing the DAO in all relationships with parties who have not consented to this Constitution. This means the DAO accepts no liability and all disputes, including claims of tort, must be directed to the Foundation.

5.2. Users shall be liable for losses caused by false or misleading attestations, such as fraudulent relay proofs, and shall forfeit any stake thereby according to the consensus rules of Pocket Core.

5.3. Software developers (such as Pocket Network Inc) are contracted by the Foundation on behalf of the DAO to develop Pocket Core. Because the Foundation defer to the Council, the Council is ultimately responsible for reviewing new software and approving Protocol Upgrades. Further, the Validator Nodes are responsible for accepting Protocol Upgrade Governance Transactions approved by the Council, and Users consent to the Validator Nodes decisions through their use of the blockchain per 2.1. Therefore, the Users agree to hold software developers harmless for unintentional mistakes made in the expression of contractual intent, whether or not said mistakes were due to actual or perceived negligence.

6. Proposals

6.1. Moderators may edit proposals only for the purpose of assigning numbers, categorizing, and updating the status of proposals. Anyone can apply to become a Moderator of any of the DAO’s communication channels, or propose the removal of existing Moderators, by submitting a PIP.

PIPs

6.2. PIPs will not be permissible if they contain multiple new specifications that could feasibly be divided into separate proposals without losing their meaning. This is in place to prevent omnibus proposals, whereby unpopular proposals are pushed through by bundling them with popular proposals.

6.3. PIP votes will last 7 days and pass with Majority Approval, unless otherwise specified in this Constitution.

PEPs

6.4. Because the DAO is a non-profit multi-stakeholder organization, the Council shall only approve PEPs in the form of grants.

PUPs

6.5. The following parameters will be governed by the Foundation in order to fulfill the target values for USDRelayTargetRange and ReturnOnInvestmentTarget set by the Council: BaseRelaysPerPOKT & StabilityAdjustment. The Foundation will anchor around the Council’s target according to a 14-day average; if the actual relay price exceeds this target range temporarily, the Foundation can ignore it, but if the range is exceeded on average for 14 days, the Foundation must respond.

6.6. The SupportedBlockchains parameter will be governed by the Foundation in order to facilitate a frictionless onboarding experience for new chains. Before whitelisting, the Foundation will provide node runners with sufficient notice to deploy nodes for the new blockchain prior to whitelisting.

6.7. The MaxApplications parameter will be governed by the Foundation to ensure economic security while bootstrapping new chains, per ‘PIP-6.2: Settlers of New Chains’, until Pocket Core has been upgraded to address targeted servicing.

6.8. All other On-Chain parameters not specified above will be governed using Majority Approval in votes lasting 7 days.

7. Finances

7.1. Contributors agree to pay taxes on all DAO-related income in whichever jurisdiction they reside. The DAO will not be held liable for any neglect in this matter.

7.2. It is forbidden to propose or approve unconditional general distributions of the Pocket Core DAO Treasury to token holders, which may be misconstrued as dividends.

7.3. The Foundation may on the Council's behalf exchange POKT for another cryptocurrency or token for the purpose of using external blockchains.

8. Amendments

Constitutional Amendments

8.1. This Constitution may be amended according to Majority Approval in the PIP process, unless otherwise specified in ‘Immutability’ and ‘Undo’ below.

Immutability

8.2. No Constitution amended to modify clauses or definitions marked with a ‡ will be accepted under any circumstance except per 8.6.

8.3. Constitutions amended to introduce a ‡ will be accepted if they have first received Supermajority Approval in the PIP process.

8.4. No Constitution amended to modify clauses or definitions marked with a †, or to introduce a †, will be accepted unless the proposed amendment has first received Supermajority Approval in the PIP process.

Undo

8.5. At any time, a supermajority vote may reverse the latest constitutional amendment (but no amendment that has been superseded by a new version). This "undo" mechanism shall prevail over the immutability mechanisms.

Executing Constitutional Amendments

8.6. All relevant permission holders must act to execute new versions of the Constitution by updating Pocket Core and/or relevant off-chain tools, platforms, or mechanisms, within 7 days, or else they will be removed from the permissions they hold.

Crediting Constitutional Amendments

8.7. Authors of constitutional amendments will be listed chronologically as authors of the Constitution.

Tracking Constitutional Amendments

8.8. Amendments which modify existing clauses will add a 0.01 increment to the Constitution version for every modification. Amendments which introduce/remove clauses will add a 0.1 increment to the Constitution version for every modification.

Upgrading the Council

8.9. Until an Aragon Agent (or similar smart contract representative) can own root permissions in the Council's existing platforms, the Foundation will hold these permissions and will therefore be responsible for any Council upgrades that have been approved in the PIP process.

8.10. If an upgrade involves introducing a new platform, which may use different addresses, the Foundation will be responsible for configuring the new platform.

Pocket Core Amendments

8.11. Protocol Upgrades (including changes to the ACL) will be approved by the Council according to the PIP process.

8.12. Upgrades are pushed to Nodes in a dormant state then, once the Council has signaled approval, the Foundation will activate the upgrade retroactively by submitting a Governance Transaction.

8.13. Pocket Core's upgrade process is permissive. Node operators can keep pocket-runner on their Pocket Core installation if they consent to automatically updating their Nodes according to the Council's decisions. If they decide they want to refuse the Council's decisions, they can replace pocket-runner with their own versioning software and ignore Governance Transactions. This power is subject to a Tendermint consensus test, whereby 66%+ of the nodes must refuse the Council's decision in order for the blockchain to continue to operate normally without forking.

Foundation Amendments

8.14. Because Supervisor decisions are not valid unless ratified by the Council, no upgrade can be made to the Foundation's Articles without the Council first signaling approval.

9. Initialization

9.1. No decision by the Council shall be legitimate until the founding Voters of the Council have unanimously approved this Constitution.

Definitions

  • Access Control List (ACL): a permission framework used by Pocket Core to control which accounts can submit Governance Transactions, such as transferring funds from the Pocket Core DAO Treasury, burning funds in the Pocket Core DAO Treasury, updating On-Chain parameters, and activating Protocol Upgrades.
  • Aragon Agent: a smart contract representative of an Aragon organization, enabling the organization to interact as one entity with external smart contracts and protocols
  • Aragon Agreements: an app enabling Aragon organizations to bind programmatic actions to human-readable agreements, which will be enforced according to peer challenges and Aragon Court
  • Aragon Court: a decentralized court system that incentivizes internet jurors to rule fairly on subjective disputes and will perform the Judiciary function of the DAO
  • Apps: Pocket Network accounts that stake POKT to submit API requests (relays) to Pocket Network
  • Block Reward: POKT minted every time a block is successfully validated in Pocket Core
  • Bonded: the state of an App or Node that has staked POKT
  • Burning Tokens: the permanent removal of POKT from circulation
  • Constitution: this binding agreement around which the Pocket Network DAO coordinates
  • Contributors: anyone who is doing work in service of the DAO and/or the Pocket Network ecosystem, such as proposal recipients, bounty recipients, and protocol developers
  • Decentralization Day: a legal milestone for the decentralization of Pocket Network, marked by the existence of 100 independently operated Nodes and the passing of the Council’s first vote (9.1)
  • Decentralized Autonomous Organization (DAO): a multi-stakeholder organization of Users, Contributors, and/or Stakeholders of Pocket Network, who collectively govern the public goods that are Pocket Core, the Pocket Core DAO Treasury, and all associated ecosystem resources, according to the structures, rules and procedures outlined in this Constitution
  • Designated Blockchain: Pocket Core
  • Executive: the functions of the DAO that are responsible for executing the decisions made by the Legislature
  • Governance Upgrades: any amendment to the government apparatus of Pocket Network
  • Governance Transactions: transactions executing the results of Council decisions On-Chain
  • Judiciary: the functions of the DAO responsible for enforcing the rules encoded in this Constitution
  • Legal Order: any restraining order, preliminary or permanent injunction, stay or other order, writ, injunction, judgment or decree that either: (i) is issued by a court of competent jurisdiction, or (ii) arises by operation of applicable law as if issued by a court of competent jurisdiction, including, in the case of clause “(ii)” an automatic stay imposed by applicable law upon the filing of a petition for bankruptcy.
  • Legislature: the functions of the DAO responsible for decision-making
  • Majority Approval: 50% yes votes by Voters who voted on the proposal
  • Nodes: Pocket Network accounts that stake to process relays submitted by Apps and validate blocks in Pocket Core
  • On-Chain: any transaction that executes via submission to a blockchain, such as Pocket Core or Ethereum, meaning it is irreversible
  • Pocket Core DAO Treasury: an account which holds the DAO’s common funds on Pocket Core, funded by Pocket Core’s Block Reward, and whose control is determined by the ACL
  • Ownerless Foundation: a foundation which has no members and thus no-one with a legal right to its assets, with the intent of maintaining a lean Executive
  • Parameter Update Proposal (PUP): proposals to change the value of a given parameter, On-Chain or in the Council’s tools or platforms
  • Parties: any Person who consents to the terms of this Constitution, per ‘Informed Consent’
  • Permission Holders: DAO participants who possess permissions as defined by the ACL of Pocket Core or an external Council platform such as Aragon or Discourse
  • Person: any human, robot, bot, artificial intelligence, corporation, partnership, association or other individual or entity recognized as having the status of a person under the law
  • Personhood: the quality or condition of being an individual person
  • Pocket (POKT) Arcade: a series of gamified Pocket Network community quests that serve to onboard community members and qualify their Stakeholder status
  • Pocket Ecosystem Proposal (PEP): proposals to distribute funds to or form agreements with Contributors to the Pocket Network ecosystem. PEP categories include:
    • Imbursements: paying Contributors to fund future work
    • Reimbursements: paying Contributors for previous work
    • Bounties: funding work that has yet to be claimed by Contributors
    • Transfers: transferring funds to addresses that facilitate the above
    • Agreements: formal understandings of Contributor relationships, including non-financial in nature
  • Pocket Improvement Proposal (PIP): proposals to upgrade any facet of Pocket Network, including Protocol Upgrades and Governance Upgrades
  • Pocket Core: the blockchain that coordinates Pocket Network
  • Pocket Network: the suite of technologies and service providers that provide decentralized infrastructure for Users
  • Pocket Network Council (Council): an unincorporated association of Voters who perform the Legislative function of the DAO
  • Pocket Network Foundation (Foundation): the Ownerless Foundation domiciled in the Cayman Islands, controlled by the Council to perform Executive functions
  • Pocket Network Inc (PNI): a Delaware LLC contracted by the Foundation to build Pocket Core and develop the Pocket Network ecosystem
  • Protocol Upgrades: software updates to Pocket Core, approved according to PIPs
  • ReturnOnInvestmentTarget: an off-chain pricing parameter, enabling the Council to signal how many days they believe it should take an App to achieve the USD/Relay Target Range, accounting for the opportunity cost of using Pocket Network versus competing services
  • Settlement: a penalty payment that proposers must make to prevent an Aragon Agreements challenge from escalating to Aragon Court
  • Signaling Era: the period before automatic cross-chain execution of the Council’s decisions is achieved
  • Stakeholder: any Party who has qualified their participation in the Pocket Network community by reaching the required levels of POKT Arcade
  • Supermajority Approval: 80% yes votes by Voters who voted on the proposal
  • SupportedBlockchains: a whitelist parameter defining which blockchains are permitted to generate Block Rewards for Nodes, to limit revenue generation capabilities to blockchains with enough traction that they would not facilitate self-dealing by Nodes (wherein they stake as an App and, due to low traction, are matched with their own Node and can thereby process fake relays)
  • Unbonding Period: the period of time that an App or Node must wait after revoking their Bonded status to receive their staked POKT
  • User: any Person or organization of Person(s) who maintain(s) direct use of Pocket Network’s services through staking or transactions or indirect access to Pocket Network’s services through relationships with third-party Pocket Network account-holders
  • USDRelayTargetRange: an off-chain pricing parameter, enabling the Council to signal what they believe the rough long-term price range (in USD) should be for relays, to ensure Pocket Network’s service is competitive enough to attract new Apps
  • Vote: a signed message by a Voter signaling their approval or rejection of a proposed action
  • Voter: a Stakeholder who has successfully claimed a Voting Token, by qualifying their Stakeholder status and verifying their Personhood
  • Voter Distribution: the demographic of Voting Token holders
  • Voting Token: a blockchain token representing the owner’s right to submit Votes

Acknowledgements

v1.0

Authors: Jack Laing

Acknowledgements:

  • The comments of Michael O’Rourke, Dermot O’Riordan, Nelson Ryan, Stéphane Gosselin, Adam Liposky, Gabriel Shapiro, Lawrence Lundy-Bryan, Philippe Honigman, Louis Giraux, Felix Machart, Xule Lin, and John Light.
  • The legal advice of Ryan Williams and Ashok Ayyar of Ashbury Legal, and Michael Robinson and Bradley Kruger of Ogier, in designing the Pocket Network Foundation (Foundation).
  • Parts of the Statutes have leveraged a Qualified Code Deference template by Gabriel Shapiro, but this does not constitute an attorney-client relationship.