7.0 Principles
===

*[This section states the principles by which all members of the Treasury trust agree to abide.]*

The following Principles are agreed to be upheld by all stakeholder roles defined in the Scope of this Framework:
### **7.1 Open Standards**
The infrastructure of the Treasury stack shall use Open Standards and avoid mechanisms that would prevent information or documentation from being accessible, portable, or interoperable.
### **7.2 Accountability**
The Treasury Community shall be accountable to each other for conformance to the purpose, principles and policies of the Treasury Governance Framework. As often as is reasonable, community members should let data drive decision-making, prototyping and testing within the community, and iterating in response. Analysis of the data that underlies conformance should be “always-on”, and a priority in governance decisions.
### **7.3 Transparency**
The Treasury shall practice Open Governance and the Board of Trustees and Governed Bodies shall operate with full openness and transparency to the greatest extent feasible consistent with the principles herein. This includes the proceedings of the BoT and all Governing Bodies, the development and distribution of all documentation and repositories, the qualification and operations of Trustees, and any revisions to the Governance Framework.

### **7.4 Decentralized by Design**
- **7.4.1 General thoughts**
Treasury Governance shall be decentralized to the greatest extent possible consistent with the other principles herein. As the organizational, legal, and technical limitations of decentralization may change over time, the Board of Trustees shall continuously examine all points of integrity, decision, and governance to seek ongoing conformance with this principle.
- **7.4.2 Diffuse Trust**
Treasury Governance shall not concentrate power in any single Individual, Organization, Jurisdiction, Industry Sector, or other special interest to the detriment of the Project Catalyst Network as a whole. Diffuse Trust shall take into account all forms of diversity among community members.
- **7.4.3 Web of Trust**
Treasury Governance shall be designed to not favor any single root of trust, but empower any member to serve as a root of trust and enable all members to participate in any number of interwoven Trust Communities.
- **7.4.4 Censorship Resistant**
Treasury Governance shall be designed to resist censorship of any member or governed body while remaining compliant with all applicable laws.
- **7.4.5 Regenerative**
Treasury Governance shall be designed so that failures and errors can be quickly and easily found and replaced or revised as necessary. The concept of “liveness” falls under this principle.
- **7.4.6 Distributive**
Treasury Governance shall be designed and implemented such that authority is vested, functions performed, and resources used by the smallest or most local part of the Treasury Community that includes all relevant and affected parties. Deliberations should be conducted and decisions made by bodies and methods that reasonably represent all relevant and affected parties and are dominated by none. The basic formula is that individuals do more, and governance does less. Governance should always be focused on the irreducible core of our collaboration.
- **7.4.7 Edge Innovation**
The continued development of the Treasury Governance shall encourage innovation to take place at the edges of the network among the members of the Treasury Community most directly involved or impacted.

### **7.5 Inclusive by Design**
- **7.5.1 General thoughts**
The design, governance, and operation of Treasury Governance shall follow the principles of Inclusive Design to serve the widest possible community of treasury participants.
- **7.5.2 People Centered**
Treasury Governance design, standards and revision shall put people at the heart of the design process and enable them to control their own member experience.
:::info
Service design for Treasury operation starts with identifying member needs. If you don’t know what the member needs, you won’t build the right thing. Do research, analyze data, and communicate with members. Don’t make assumptions. Have empathy for members, and remember that what they ask for isn’t always what they need.

Also, simplicity in user experience should stand out. Making something simple to use is hard - especially when the underlying systems are complex - but that’s what we should be striving for.
:::
- 7.5 (cont)
- **7.5.3 Understanding Differences**
Treasury Governance designers shall strive to understand differences in capabilities and preferences across all potential members of the Treasury Community and provide adaptable solutions to meet the needs of all potential members.
- **7.5.4 Check Across Contexts**
Treasury Governance designers shall test Treasury protocols and policies for use in different member environments and contexts. We are not designing for machines, blockchain or projects, we are designing for people.
- **7.5.5 Offer Choices**
Treasury Governance designers including those implementing revisions or standards (TIPs) shall design flexibility by accepting that there are choices of ways to achieve the same outcome. Where possible, designers should offer such choices.
- **7.5.6 Maintain Consistent Experience**
Treasury Governance designers shall design comparable experiences for all of their member communities that use consistent design elements and language. We should use the same language and the same design patterns wherever possible. This helps people get familiar with our Treasury services, but when this isn’t possible we should make sure our approach is consistent.
:::info
This isn’t a straitjacket or a rule book. Every circumstance is different. When we find patterns that work we should share them, and talk about why we use them. But that shouldn’t stop us from improving or changing them in the future when we find better ways of doing things or the needs of members change
:::

<style>

html, body, .ui-content {
background-color: #333;
color: #ddd;
}

.markdown-body h1,
.markdown-body h2,
.markdown-body h3,
.markdown-body h4,
.markdown-body h5,
.markdown-body h6 {
color: #ddd;
}

.markdown-body h1,
.markdown-body h2 {
border-bottom-color: #ffffff69;
}

.markdown-body h1 .octicon-link,
.markdown-body h2 .octicon-link,
.markdown-body h3 .octicon-link,
.markdown-body h4 .octicon-link,
.markdown-body h5 .octicon-link,
.markdown-body h6 .octicon-link {
color: #fff;
}

.markdown-body img {
background-color: transparent;
}

.ui-toc-dropdown .nav>.active:focus>a, .ui-toc-dropdown .nav>.active:hover>a, .ui-toc-dropdown .nav>.active>a {
color: white;
border-left: 2px solid white;
}

.expand-toggle:hover,
.expand-toggle:focus,
.back-to-top:hover,
.back-to-top:focus,
.go-to-bottom:hover,
.go-to-bottom:focus {
color: white;
}

.ui-toc-dropdown {
background-color: #333;
}

.ui-toc-label.btn {
background-color: #191919;
color: white;
}

.ui-toc-dropdown .nav>li>a:focus,
.ui-toc-dropdown .nav>li>a:hover {
color: white;
border-left: 1px solid white;
}

.markdown-body blockquote {
color: #bcbcbc;
}

.markdown-body table tr {
background-color: #5f5f5f;
}

.markdown-body table tr:nth-child(2n) {
background-color: #4f4f4f;
}

.markdown-body code,
.markdown-body tt {
color: #eee;
background-color: rgba(230, 230, 230, 0.36);
}

a,
.open-files-container li.selected a {
color: #5EB7E0;
}

</style>