Participating Projects

There's really no way to say. The project encompasses so many people and organizations who are each pursuing their own goals. They each measure success of the project based on how it meets their goals.

Initial development of the software was not aimed at any particular goal other than finding a superior alternative to proof of work. Technical excellence was the criterion used when making design decisions, not fitness for any particular application.

Various organizations make recommendations for software changes. Code changes have to be approved by stakeholders (in the form of them electing to run the changed code on their systems).

Network participants are identified by signing with private keys that correspond to known public keys.

On-ledger accounts can be identified by the hash of their master key. Network participants can elect to provide additional identifying information if they wish to, for example, associating a domain name with an on-ledger account.

There are no special account restrictions or privileged accounts. An account can be created by sending XRP to it and then that account has all account privileges. This includes the ability to hold and transfer XRP, issue other tokens, and participate in the native decentralized exchange.

There are three ways in which there are what could be considered special groups, all of which center around a purely local construct called a “UNL”.

One is in the decision to accept a ledger as final, analogous to deciding that a bitcoin transaction has sufficient confirmations. This is a purely local decision that each participant who needs to make such decisions makes that has no effect on anyone else. This decision is made based on choosing a set of announcing nodes to listen to and accepting a valid ledger as final when you see a super-majority of those nodes vouching for it.

Another is in the decision of which valid transactions were seen on time to include in the next built ledger (versus which should be deferred to the next ledger because they were seen slightly too late). This is how the XRP Ledger solves the double-spend problem – each participant chooses a set of other participants.

for which they are willing to defer a valid transaction for one ledger if those participants did not see the transaction on time.

Lastly is in the coordinated activation of rule changes. Of course, your node can never activate or accept a code change if you have not personally chosen to run that code. But once you have, you need to coordinate the activation of that change to avoid accidental forks. Each participant chooses who they wish to coordinate with.

In sum, the only extent to which there are special groups with special powers is in counting confirmations, solving the double-spend problem and in avoiding accidental forks.

It's not really possible to judge which groups are important. There are developers, companies that use the XRP Ledger, exchanges, gateways, and so on. There are no formal groups with formal roles with respect to the XRP Ledger. The ledger is governed by people choosing to run code that is sufficiently compatible for them to interoperate.

The project seeks to incentivize correctness, agreement, and performance, in that order. Such behavior is incentivized by providing no artificial incentives. Since there are no artificial incentives, there is no reason to participate in the network other than to make it objectively better.

This is extremely important to understand and a key differentiator between the XRP Ledger and other projects. For example, with proof of work, every miner raises the difficulty for every other miner, misaligning their incentives. Worse, miners want high fees while stakeholders want low fees, again misaligning incentives.

Instead, those who run XRP Ledger nodes do so only because they want access to the XRP Ledger. Those who run nodes that participate in solving the double spend problem and coordinating rules changes do so only because they benefit from the double spend problem being solved and rules changes being coordinated. There is no other reason to run them.

The design focused on making the network very cheap to run and with inherent defenses against things like roll-backs. It does not need artificial incentives that actually misalign participants.

This is just one person's opinion, but I think they are working nearly flawlessly. The network has never had a rollback, never experienced censorship, never had an unintentional fork, has kept fees and confirmation times low and currently accounts for nearly half the transactions on all public blockchains.

Yes. Anyone who believes they benefit from such work funds such work. This can take the form of employing developers, creating bounties, or participating in public discussions.

There really is no such thing in this, or any, decentralized project.

Anyone who wants to can make any suggestions they want to whoever they want.

Every node operator chooses what code to run on their node. Changes in transaction processing rules are adopted by a coordination mechanism. Once a super-majority of economically important nodes have.

adopted a code change, everyone who has opted to participate in the coordination process indicates that they recognize such a super-majority. The network's consensus mechanism then manages a two-week timer to activate the change.

There is no particular process for changes that don't affect transaction execution. They don't require coordination, so anyone can adopt them however they want without affecting others.

Every node decides whether or not to execute a proposal. Those who choose to make their decisions public can broadcast them and each participant decides who they wish to listen to for coordination purposes. If people are not satisfied with those they've chosen, they would be expected to choose others.

For example, if you want to propose a change that might be controversial, at the same time you can also propose a set of coordinators who you know will coordinate the activation of your change as soon as it has reached sufficient adoption. Those who prefer your change would also prefer your coordinators. So control over coordinators does not translate into control over rules changes.

There is not a meaningful concept. Since there is nobody who is empowered to do anything special, there is no context in which a dispute would occur or need to be resolved. Judicial power, in the absence of any kind of enforcement power, would be a nullity. Decentralized systems do not provide enforcement power to any entities, so judicial power would be meaningless.

The only thing that needs to be agreed on is transaction execution rules. Everything else is a local decision. Those who do not agree on transaction execution rules cannot interoperate. Those who do agree on transaction execution rules can interoperate. These facts have proven to be sufficient.

There are signals for coordinating rules changes that have achieved super-majority support. Anyone who wants to can provide such a signal and each participant can elect whose signals they wish to listen to.

This on-ledger governance exists strictly to avoid accidental forks. (Those who intend to change the rules can also change whose signals they listen to.)

The network's consensus process fundamentally works by majority vote. However, there is a norm not to vote for network rules changes until you see 80% support from the nodes you've chosen to coordinate with. This is because activating a rule change forks off any nodes that have not added the code for that rule change. Again, the only on-ledger “governance” is to avoid double spends and accidental forks. All other governance takes place by individual participant decisions.

The concept of a hard versus soft fork doesn't apply to the XRP Ledger because it has a coordinated mechanism to change transaction rules and does not have a block producer who chooses which block to build on and what transactions to include. So I think the answer to this question is “no”, but that might be misleading. Arguably, every transaction execution rule change the XRP Ledger has ever made is a hard fork.

The choice not to use proof of work makes changing the project much, much easier by many orders of magnitude. To make a change in a project that uses proof of work, you must get a supermajority of miners to agree to your change or your chain will not be secure. If your rules do not have sufficient economic value, the chain will become unusable, even for operations with low economic value. There is no such impediment to rule changes on the XRP Ledger. If stakeholders want a rule change, they get it. They do not need to incentivize miners or worry about a loss of security.

The ability of participants to choose who they wish to coordinate with makes changing the project as simple as agreeing with others to make those changes and then making appropriate settings changes. Of course, if a minority did this, they would wind up producing an intentional fork. For any disagreement over transaction processing rules, two groups simply have to decide whether one group is willing to live by the rules the other group prefers or, if not, they split the network. It really is that simple.

There really is no way to revise governance mechanisms. There is no group that has any particular power over the network and there doesn't seem to be any way for anyone to acquire any.

The XRP Ledger has no incentives, other than that people benefit from the network working well and thus contribute to making sure it does. The XRP Ledger has no governance, other than to avoid accidental forks and double spends, beyond that people choose what code to run on their nodes. There are no artificial incentives, the only incentive to participate is because you benefit from a smoothly-running network.

Yet with this, the network has run smoothly for seven years. Transaction fees have remained way below a penny because there is no need to incentivize block production, there has never been censorship or a double-spend because the consensus mechanism inherently prevents these issues, and technical progress has continued to be made in the form of a large number of innovations including a higher transaction per second rating than any other major blockchain, the first decentralized exchange (in 2012), off-ledger scaling through payment channels, invariant checking to improve security, multisign with key rotation without changing receiving addresses, new nodes able to join the network in less than 10 minutes, and so on.