Participating Projects

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

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.

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.

• 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.

None

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.

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.

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.

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.

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.

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:

There are three tiers of Economic Nodes:

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

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.

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.

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.

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

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.

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

No.

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.

Additional reading is here.