Participating Projects

VeChain

Project Description

What are the purposes, goals, or scope of the project? If there are metrics to measure success, what are they?

VeChain is a public blockchain platform that aims at mainstream adoption and real world (non financial) applications. Not doing DeFi or crypto. Focus is on other use cases. Goal is to empower enterprises to create value for their businesses.

Metrics:

  • Number of transactions (“Tx”) generated by real world businesses (not crypto transfers among bots)
  • Market value of the businesses that are operating on the chain
What, if any, are the coordinating entities, and what are their functions? (For example, a foundation, software development corporation, DAO, etc.)

The VeChain Foundation is a non-profit. Its function is to oversee software development, and to govern according to the rules and expectations laid out in the white paper.

How are participants and users of the project identified? (For example, by public/private cryptographic keypair, wallet number, government ID, etc.) Are there restrictions on who can participate? If so, how are they implemented?

The users can be identified by keys, and also by the “VeVID” that is allocated by the Foundation to the user after the user passes KYC administered by the Foundation — the ID can be given to an individual or to a company.

Chain validators are known as “miners” or “authority masternodes” — both terms are used.

There are business partners who develop Dapps and there are individuals who contribute to the ecosystem.

KYC is one restriction, in that you cannot become a validator/miner until you submit an application and get accepted. Once accepted, the miner is authorized on the chain as a validator.

No restriction for ACCESSING the blockchain. This includes reading and submitting transactions. There are Tx fees. You can submit (some) Tx without a VeVID. As a developer I can white list (some) VeVIDs.

Stakeholder Groups

Does the project’s software code delineate groups with particular functions? (For example, those who can propose changes, arbitrate disputes, or vote tokens on behalf of others.)
  • Miners
  • Dapp developers
  • Regular users
  • Governing Body called the “Board of Steering Committee” inside the VeChain Foundation, and the members of the Governing Body are issued special private keys that control specific governance functions. These can be revoked. Details are tracked on chain.
Are there other important groups either constituted informally, specified through contractual arrangements, or based on geography/choice of law?

None

Goals and Implementation

What behaviors does the project seek to encourage, or discourage? How are such behaviors incentivized?

Validators (authority master nodes) are expected to behave in a trustworthy way to keep the chain running and stable. A validator must post a bond (deposit) of VeChain Tokens (VET). Each validator is KYCed and therefore, puts their reputation as a stake. And each action on chain is traceable; a validator could potentially be sued by someone (i.e. for violating the terms of the legal contracts that the parties enter into when joining VeChain).

Many validators are also running businesses on the chain, and misbehavior by the validator can harm their business interests. This is also the way miners with business running on VeChain are incentivized.

VeChain encourages via the Foundation the creation of connections and business relationships (via introductions); the Foundation sometimes also supports new business efforts financially.

Validators when they create a block will receive block rewards. Misbehavior can cause them to be struck from the list of validators, costing them future revenue.

Misbehavior [by a validator] will likely decrease VeChain’s token value and therefore, reduce the value of [the validator’s] deposit.

Misbehavior will also harm their reputation since the Foundation is likely to publish all the evidence and directly identify the miner [validator] who misbehaves. There could possibly be legal consequence.

(For operational projects): How well are the incentives and governance mechanisms functioning in practice? Are there metrics to measure the effectiveness of governance?

Peter sees the mechanisms as functioning well. Validators are operating as expected; they have upgraded. Chain has run well for about 1.5 years. Governance is proceeding as described in the white paper. The forum, online voting platform, etc. are working — more than 17% of “long term” token holders and 50% of validators participated in the most recent vote.

Voting for the steering committee members is every 2 years, so a new election is coming up as of this interview. Voting is by long-term token holders and block validators.

There are soft metrics. Chain is running smoothly; upgrades have occurred; the promises in the white paper have largely been kept. Voting is democratic.

Are there systems to pay for infrastructure, protocol upgrades, development work, network enhancements and/or other work deemed to be in the interest of the network? If so, how do they operate?

The Foundation pays for some of these things. Some developers have submitted / can submit proposals for improvements to the Foundation. This has happened at least once that Peter knows of. These are volunteers offering their ideas. There is a VeChain Important Proposal system (here) on GitHub. DApp developers submit ideas there. The technical team evaluates ideas and proposals for possible development.

The technical team is hired by and paid by the Foundation.

Governance Powers

What makes a governance decision associated with this project legitimate or illegitimate?

The board members of the Foundation use their special keys to make governance changes to the chain. Anything they do is broadly assumed to be legitimate.

Who has power to introduce governance proposals, and how does that process operate?

The Board members can propose. Depending on the nature of the proposal, the board can either approve it by itself or put it to a stakeholder vote. In either case, a supermajority of 2 / 3 of members is required. The White Paper limits what the Board can do, vs what must be put to a stakeholder vote.

Proposals are registered by either a Board member or a voting contract via smart contract. The Board members can vote via the smart contract. In case of a stakeholder vote, then the vote is in a different but connected contract. Once the threshold of stakeholder votes is reached (for a “yes”), a proposal is then submitted to the contract for the Board members to approve (2 / 3 of them required), and once approved can be executed by anyone.

Who has policy-setting (“legislative") power to decide on proposals, and how does that process operate?

Stakeholders for some; the Board for some. The white paper lays out the difference.

There are three categories of voters. Two are “long term token holders” (known as “Economic X Nodes” and “Economic Nodes”)who hold at least X number of tokens for at least Y period of time. (There are sub-categories that are detailed in the white papers.) Each person gets one vote regardless of how many extra tokens they hold above the threshold of X. The third category of voters is “Authority Masternodes” who must meet the requirements mentioned above.

There are four tiers of Economic X Nodes:

details of the four sub-categories of the voting category “Economic X Node”

There are three tiers of Economic Nodes:

details of the three sub-categories of the voting category “EconomicNode”

The following table summarizes different categories of stakeholders and their corresponding voting authority:

Table summarizing the categories and sub-categories of stakeholders, and their corresponding voting authority.

Who has implementation (“executive”) power to execute proposals once decided upon, and how does that process operate?

Smart contracts that the proposals are encoded into.

If the Board decides to introduce a new Validator, someone introduces that proposal as a smart contract action, and the Board must vote YES by 2 / 3. Once 2 / 3 is met, the contract can be executed by anyone.

Who creates the smart contracts to be voted on? The technical team. Most of them exist from Day 1.

Who has interpretive (“judicial”) power to resolve disputes over application of a policy to a specific instance, and how does that process operate? What can the interpretive power be used to mandate?

The Board can handle disputes. It rarely happens. The Board can handle any emergency via temporary measures; anything major would need to be voted via a stakeholder vote to approve the temporary measures.

If you have a business dispute, it’s handled off-chain in the normal fashion such as by arbitration. Many/most will have regular legal contracts with suppliers and customers.

What checks and balances, or systems of accountability, exist among these governance powers?

The Board members are elected, so they are accountable that way. All governance actions are via smart contract and Board private keys, which provide traceability.

Governance Procedure

Governance Procedure

Are there systems for non-binding signals or binding votes on governance decisions? If so, please describe them in detail.

Yes see above, Board and stakeholder votes on-chain.

Are there distinctions between decisions made by ordinary processes (for example, majority votes) and those which require extraordinary processes (for example, supermajority votes)? Or are there non-standard processes you would, or have, used in emergency situations? Explain as appropriate.

There are two classes of decision — those made by the Board and those made by the Stakeholders.

There is a minimum turnout requirement — see the whitepaper.

Are there aspects that can never be changed through governance processes, short of a contentious hard fork of the network? If so, how is that ensured?

The security and immutability of the ledger cannot be broken given that the blockchain system’s security assumptions are met. Nothing else.

Are there mechanisms that make changing the project easier or harder?

No.

What revisions to governance mechanisms have been made, or are under consideration, and why?

Recently the white paper was upgraded from 1.0 to 2.0. Rules about stakeholder voting were revised to make voting more practical. (In white paper v1 there were three categories of voters including dapp owners, but that group was very hard to verify and their powers were gameable, so white paper v2 dropped dapp owners from the voting.)

The Board continues to have seven (7) members. There is an election coming up, but that’s not a change of mechanism.

If there are any significant aspects of the project’s governance that you have not described, please provide details here.

Additional reading is here.

Other Information