Participating Projects

iov42

Project Description

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

iov42 is a combination of various networks.

iov42 is building the Internet Of Value, a next-generation internet, by developing a hybrid blockchain operating platform that is identity-centric and can handle virtually any type of certified, digital asset. It combines the advantages of permissioned blockchains, including scalability, governance, regulatory frameworks, usability, interoperability and energy efficiency, with the advantages of a public blockchain in terms of trust and security.

iov42 engineers core operating technology for blockchain networks. Success is defined as the adoption of this technology, i.e. seeing many instances of iov42 based blockchains coming into operation, globally. That is intertwined with acceptance of iov42’s solutions to model ownership and governance for each network individually, and is based on the concept of ‘network of networks’, so that all networks are interoperable at the protocol level. Adoption and scaling has many dimensions in our proposition - we have not yet defined metrics to cover all of them holistically.

What, if any, are the coordinating entities, and what are their functions? (For example, a foundation, software development corporation, DAO, etc.)

Network Node Operator

  • Need to have the capability and be able to satisfy any requirements for the network they wish to join (e.g. compliance, security, resources etc).
  • Node operators provide the resources to become a participant node within the network. They need agreement from all the other nodes and requisite cryptographic keys need to be exchanged.

Network Owner (separate)

Governing Body (separate)

User

  • Users capability for joining a network will be determined by the purpose of that individual network and any requirements that the particular network put on them.

 

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?

Identity modelling is a core feature of the network where identity information and cryptographic information (private keys) are associated with an identity but remain in full control of the owner (SSI). The network doesn’t stipulate any identity requirements other than a moniker and associated private key(s); the network facilitates the enrichment of identity to support a range of requirements including associating government (and other) ids. Associated with identity is an asset model (of which accounts are part).

Each network can set their own rules and bylaws. iov42 does not put or suggest any limits on participation.

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

No it doesn’t, the goal is for the software to be the operating system that allows the running groups to make their own decisions but for the underlying dry code to be consistent. At the moment this code is centralistic as we are in pre-launch, the goal for the future is to be “community” governed.

Are there other important groups either constituted informally, specified through contractual arrangements, or based on geography/choice of law?

Designed to be a network of networks where people can deliberately delineate their part of the network along social, legal and geographic structures. iov42 are building in the flexibility rather than enforcing a particular structure. What iov42 are doing is building for interoperability between the different structures at the protocol level, leading to a network of networks that grows organically, peer to peer, and without any central coordinating element, network, or interop-protocol.

The only excluded groups are those where complete anonymity is a requirement, or groups where everyone wants to be able to run a node, or networks where the total number of nodes is unknown by design at any point in time. Their requirements are incompatible with iov42’s models.

Goals and Implementation

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

iov42’s incentive model builds on a variant of Proof of Authority. Node operators are incentivised for correct votes, availability and operational stability, rather than putting a stake at risk. Votes tally one per node, independent of resources or stake. Voting is distributed evenly and randomly amongst all participating nodes (iov42’s patent-pending consensus mechanism is named DRME - distributed random master election). Users benefit from a regulatory compliant network that allows them to reduce their regulatory related costs and risks and therefore incentivizes them to behave in a regulatory compliant and standard way.

Such behaviors are incentivized through:

  • Financial benefits.
  • Creating of new markets
(For operational projects): How well are the incentives and governance mechanisms functioning in practice? Are there metrics to measure the effectiveness of governance?

N/A

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?

This is to be decided by each network individually. iov42 has not yet elaborated any templates or recommendations.

Governance Powers

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

iov42 follows a new approach called ‘network of networks’, a model of many blockchains interconnected at the protocol level. Each network can have its own constitution and ownership structure. iov42 will come up with templates for such constitutions, and it is at each network’s discretion how to adopt these.

There are overarching governance topics related to the design and engineering of the full iov42 blockchain software stack. iov42 will define general governance rules that deliver stability with regard to the avoidance of forks and the forward and backward compatibility of code. The following answers relate to the governance of this full software stack.

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

See answer to next question, about legislative power.

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

iov42 management: interim definition of the governance, until handed over to the community of blockchain network owners.

Core developers at iov42: interim engineering decisions until handover to the development community.

Community of blockchain network owners (entities): interim open feedback to the iov42 management, to be replaced by a voting system.

Community of node operators: votes in the network(s) they operate their nodes.

Users: interim open feedback to the iov42 core engineers, then feedback and proposals to the developer community.

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

iov42 management: interim executive power, until handed over to the community of blockchain network owners.

Core developers at iov42: interim free decision making on all technical implementations, later appreciating (or bound to) votes from the community of blockchain network owners; Community of blockchain network owners (entities): these are each network’s local execution power.

Community of node operators: votes in the network(s) they operate their nodes, on executive roles in the network.

Users: no executive power.

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?

iov42 management: interim judicial power, until handed over to the community of blockchain network owners.

Core developers at iov42: interim judicial power on all technical implementations, later moved across to the community of blockchain network owners.

Community of blockchain network owners (entities): these are meant to exercise each network’s local judicial powers.

Community of node operators: none.

Users: none.

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

Checks and balances are left at each network’s discretion.

Not ultimately defined yet, but on-chain transparency (documentation, traceability) is envisaged per network, and on inter-network governance this can be copied to each local network (interoperability).

Governance Procedure

Governance Procedure

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

iov42 does not give any recommendations about voting mechanisms. The ultimate legislative power to define and structure that these is the community of node operators together with the blockchain network owner for each network; and the community of blockchain network owners for overarching inter-network topics.

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.

iov42 does not give any recommendations about voting mechanisms.

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?

iov42 does not give any recommendations about voting mechanisms.

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

iov42 does not give any recommendations about voting mechanisms.

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

N/A

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

N/A

Other Information