The Rico project has a number of cultural differences from earlier iterations of the system, which have been distilled into a set of principles.
Respect incentives as natural law. In a system that is open for the whole world to interact with, incentives are not just a suggestion. An incentive is more like a physical law such as gravity or entropy. If there is some aspect of the system that is not incentive-compatible, it is only a matter of time until it is exploited. In this sense “gradual decentralization” is a strategic error, it is like “gradually” fixing a crack in the foundation. The longer you wait, the longer the risk of irreperable damage. To bootstrap a system like this, the designers have to believe that the rewards for creating such a system will be greater in the long term than the value of keeping some kind of insider advantage – and this is not a stable equilibrium.
Credible neutrality is a competitive advantage. Even if it takes longer to scale, a sound and credibly neutral system will ultimately win out over a system that uses growth hacks or retains backdoors for the sake of agility. Teams that try fiddling with incentives and see short-term results fail to realize just how much capital is waiting on the sidelines, unwilling to commit to a mechanism where the developers still have so much control.
Integrations and power users are the primary customer. The synthetic assets generated by these systems are relatively abstract financial instruments. While regular users who are not specialists should have access to all the same tools as power users, we are not concerned with hand-holding or making things understandable to people whoare not willing to take the time to establish the proper background knowledge. A description that makes sense without the right background knowledge is necessarily an incomplete and therefore inaccurate description, which is ultimately a disservice to the user.
Show the system as it is. Part of what went wrong with earlier systems is that business developers and user interface designers projected their interpretation of how the should work onto the interfaces and business processes that end users were exposed to. But the underlying smart contracts are what they are, regardless of what those people want them to be. When expectations clash with reality, who is to blame? Especially in systems that cannot be fully modeled because their behavior depends on the behavior of all market participants, it is the responsibility of the developers of the system to provide full visibility into the mechanics of the system, and expose every possible interaction in a neutral manner, without trying to guide user behavior.
Reject “decentraliztion theater”. The point of decentralization, other than credible neutrality, is to secure the system. Every point of centralization is an attack vector. DNS hijacks happen. Github account hacks happen. These are not acceptable infrastructure choices for a system that intends to scale to become a pillar of the financial economy. Just like the mechanics of the system need to be presented clearly so that users can see for themselves how it actually works, so does the security of the system.
Emphasize auditability. The system needs to be easily auditable, not just by expert auditors, but by the average power user, someone who has a lot of tangential expertise and a lot at stake, but not necessarily the time or resources for a deep audit. One key aspect of auditability is minimalism – complexity is the enemy of security.