Introduction

Eris is a platform which allows developers and users to deploy consensus driven applications which rely on decentralized architecture and a consensus driven blockchain database backend. Eris is meant to be an adaptable software package which is designed to be modular, easily copied, and easily modified – and therefore used in many different applications. The Douglas Project intend to use Eris as the relevant platform when we incorporate the Association at a later date, but we will not be limiting future development of the platform to that single application.

Eris is a completely serverless product built on a backbone of other products which have designed and built over the course of the last five months. It is our intention that Decentralised Autonomous Organisations, ÐAOs, implemented using the Eris framework will serve as technology demonstrators for a new kind of decentralised and consensus-based organisational governance, on a fully transparent and trustless basis, which to our knowledge has never before been attempted. Our primary goal is not only to design demonstrators which work on the blockchain but have no ability to be used in the real world by real users. Indeed, one of our overarching design goals is to continue to design and build ÐAOs in such a way that they abide in full compliance with legal and regulatory obligations.

We set out below the types of functions we have incorporated in Eris version 0.1; we have built it to be coupled with a real-world legal entity, ideally a non-profit, so that such organisations can benefit from the significant efficiencies which blockchain and cryptographic technologies enable while still complying with the legal formalities and necessities of the jurisdictions in which they operate and any related enforcement mechanisms such as court orders.

A ÐAO is an algorithmically-governed programme that, in using trustless decentralised computing, can serve as a way to formalise multilateral relationships or transactions outside of traditional legal architecture (see the essay Formalising and Securing Relationships on Public Networks by Nick Szabo to learn more on the subject).

In legal terms, a ÐAO is therefore a medium for two or more people to conclude agreements or otherwise associate with others in a predictable way. The fact that a ÐAO built on a blockchain operates itself in accordance with pre-defined rules and cryptographically secure architecture means that its users can reliably expect instructions which they broadcast to be consistently and securely executed.

When viewed through such a lens, Bitcoin itself is a ÐAO, albeit a very early one capable of executing only the simplest one-way transactions. Until recently, ÐAOs capable of a higher degree of sophistication existed only in theory. More recent iterations require a high degree of technical aptitude to use — or to find relevant for use — and therefore have failed to capture the public imagination.

We hope to change that.

At Project Ðouglas, it is our belief that the proliferation of ÐAOs in user-friendly applications has the potential to allow the public to claim back control over their data and over their privacy on the internet. Current free-to-use internet services, from search to e-mail to social networking, are dependent on advertising revenue to fund their operations. As a result, companies offering these services must – to paraphrase Satoshi Nakamoto – ‘hassle their users for considerably more information than they would otherwise need.’ This necessity has skewed the internet toward a more centralized infrastructure and usability system than it was intended.

Where Bitcoin was designed to solve this problem in relation to point-of-sale and banking transactions, Project Ðouglas is working on solving this issue for internet-based communications, social networking and community governance — bearing in mind that for free internet services such as e-mail, social networking, search and “open data,” intrusion into users’ private lives and the accumulation and centralisation of vast quantities of personal information in centralised silos is not some minor and ancillary nuisance — this is a design imperative for everything that Project Ðouglas is engaged in. As such, Eris is not another web service; Eris is significantly different because it has been designed and implemented specifically to not use servers.

Eris will initially be run on the Ethereum testnet, in relation to which the underlying units of testnet Ether presently are (and will likely forever be) completely valueless in exchange. However, the experience of Bitcoin has demonstrated powerfully that the enterprise value of decentralised networks operating on this basis can and does capitalise into the value of tokens they issue. We do not, therefore, think it unreasonable to expect that “2.0” platforms such as Ethereum or ones similar to it have the potential to thrive in a similar fashion, allowing the creation of free-of-charge services which incentivise privacy through their very design.

A Very Brief Overview of Functionality

Our ÐAO is completely serverless and offers a wide range of functionality. Specifically:

1. decentralised forums;
2. decentralised crowdfunding;
3. decentralised voting (Active Permissions);
4. decentralised Reputation Scoring on three “Branches”:a. Citizenship (representation and lobbying, polling Community sentiment and opinion);

   b. Development (maintaining and upgrading the AÐAO); and

   c. Moderation (flagging content and assessing and resolving disputes)

5. decentralised voting (user communication to the Association on issues of significant importance or policy positions).

Decentralised crowdfunding/escrow/financial contracts are fairly straightforward to code and can easily be worked into an Eris platform. Project Ðouglas intends to release such a module in an upcoming release of our Eris platform.

In addition, project tracking is also fairly straightforward to code and can also be quickly and efficiently worked into a deployed Eris platform. Project Ðouglas also intends to release such a module in an upcoming release of our Eris platform.

The integration of decentralised bilateral and multilateral messaging has also been set as a medium-term objective for the Project Ðouglas team. We take the view, however, that this is an essential piece of creating a decentralised social network which people will actually want to use. We intend to incorporate it when time and resources permit.

Pairing With a Non-Profit Entity

We also believe that a deployed Eris system will be more effective as a representative and educational tool if it is paired with a real-world incorporated non-profit entity which operates within legally permissible parameters (the exact form of business organisation is somewhat flexible based on the desires of the implementing group or organization). Eris v0.1 has therefore been designed specifically to serve as a consensus and fundraising mechanism for non-profit organisations, although in theory any organisation could adapt it for its own purposes.

Eris does not incorporate any monetisation mechanism of any kind. The only tokens required for its use will be those of the underlying general-purpose blockchain (at the moment Ethereum, but in principle any smart contract-capable blockchain could work). Mining on the underlying blockchain processes the transactions the Eris platform mediates. Apart from that, there is absolutely no reason that an Eris-based platform’s functionality should be anything but free to use.

The legal architecture is non-essential for the testnet AÐAO and therefore incorporation and other legal matters will be dealt with at a later date. However, the Eris platform is designed with an eye to being more than simply a testnet demonstrator.

Although the possibilities for an Eris-derived platform in nonprofit or fully decentralised applications are as varied as technology and humanity itself, by way of example we should explain what we will be seeking to do with the Association. The Association will exist “to advance the state of cryptocurrency protocols and decentralised computing technology, to educate the public as to its utility, to disseminate improvements to it freely and to promote its use for the benefit of all.” We envision that it will be wholly dependent on donations from the public or project-based grants from research institutes to carry out its operations and employ a small staff; members of its board (being volunteers) will not enjoy any personal benefit from or rights to these funds.

It is envisioned that the Association might, at its discretion, restrict access to the AÐAO to individuals and organisations donating more than USD$25 or other cryptocurrency equivalent (Bitcoin, Dogecoin and Litecoin) to become users of the AÐAO. Higher levels of donation will not grant additional rights of access. If Ether is used as the method of payment, the grant of access could be wholly automated. Donation through any other means will be routed through a trusted silo – which we envision would typically be the Board or the staff of the real-world association. Thereafter it is envisioned that the AÐAO will be free to use.

The Association will, furthermore, have a number of discretionary powers to intervene in the ÐAO’s activities, but these will be very limited and a community/user supermajority override will also exist. We will release details of this functionality when we release version 0.1.

Eris = Public Networks + Cryptographic Databases + DOUG + c3D

A. DECENTRALISATION ARCHITECTURE

Using:

1. the Ethereum blockchain (the Blockchain);
2. a constitutional smart contract which will operate on the back-end (the Ethereum layer) to organise and launch blockchain-based contracts (such constitutional contract being known asDOUG (to avoid any confusion, this is DOUG pronounced as in “Ðouglas”)); DOUG acts as the kernel of the AÐAO and provides a core of functionality which can be expanded with submodules built and integrated into its core functionality over time;
3. Factory Contracts (described more particularly below) which provide standard-form contracts for specific purposes (e.g. for consensus-gathering functionality or specific fundraising efforts, or standalone smart loans) which DOUG can (if desired) deploy to the blockchain and track;
4. a DOUG-compatible data storage and recall facility (Contract Controlled Content Dissemination Program, also CCCD or C3D) which utilises the BitTorrent protocol to store, disseminate, and recall contract-specific data (with which DOUG will interact in order to support the execution and settlement of Factory Contracts); and
5. an application-specific user interface framework which is able to synthesise information between DOUG and C3D; the user interface will be delivered using the C3D system which is what allows the Eris system to work on a serverless basis;

we propose to deploy, for the first time, a decentralised smart contract platform which is useable by ordinary people in everyday applications.

The above architecture reimagines how typical applications are designed by fracturing current notions of server delivery technology into numerous pieces while also utilizing the keen advantages which web frameworks and design implementations enable for a user.

B. FUNCTIONALITY

1. THE DAWN OF ÐAO://

Users will experience the c3D/DOUG architecture through a simple user interface. As the platform evolves user experience will be made paramount, with the general idea (and end goal) being that users should be able to use the platform without being able to tell the difference between it and, for example, Facebook, Reddit, Github, or Kickstarter.

Unlike modern web applications, though, users will benefit from decentralisation and encryption and will be able to mount trustless peer-to-peer interactions. These interactions can vary from formal business interactions (contracts) to simple social interactions (conversations) with many gradations in between. Flexibility has been built-in so the users can vote on issues without having to trust the reliability of any central node within the system and new features may be added to the ÐAO provided that sufficient majority thresholds of active users so decide.

In principle, any agreement which is reducible to code is amenable to expression through a ÐAO; we aim to standardise the process of smart contract generation so they can be replicated in different contexts and for different uses with relatively little effort, technical knowledge or cost. These contracts can be either standalone (and thus settled on a peer-to-peer basis) or by reference to DOUG (in the case of the consensus-gathering and Community-driven functions outlined more particularly below).

It is envisaged that as development of the AÐAO progresses and a greater degree of certainty is achieved, Factory-made contracts will be linked to off-chain legal agreements and identification procedures in order to permit, e.g,. the taking of security, the incorporation of trustless arbitration (as proposed by Vitalik Buterin), or the possibility of real-world enforcement. The extent to which this added functionality is available and useable under the aegis of the AÐAO will be largely dependent on the availability of appropriate code, contributed by the Community, capable of incorporating these legal obligations by reference, as well as market demand.

The Eris framework is based around seven functional components:

1. ByLaws, which are in effect the trustless, cryptographic and automated constitution of the v 0.1 Eris prototype;
2. Standard Permissions, which are structural permissions which govern the ordinary, day-to-day interaction of particular users with DOUG and Eris, as well as the interaction between different contracts to which DOUG points;
3. Active Permissions, which are non-persistent permissions lasting for a limited time and in relation to a limited action which can be activated by the users of the ÐAO;
4. Reputation Score, which serves the dual function of (1) measuring and tracking user participation and allowing users who accumulate certain amounts of reputation to carry out certain non-constitutional functions e.g. moderation and (2) also allows users possessing very high levels of community support to effect changes to bylaws and perform other functions analogous to the exercise of Active Permissions (this latter aspect is currently planned for rollout for v 0.2 or subsequent);
5. Issue-specific Contract Factories through which the community can exercise Advanced Permissions on a democratic vote, and in relation to which (as these are modular) other functionality will be added in the future;
6. Master Keys; and
7. C3D.

2. BYLAWS

The DOUG back-end will run in accordance with pre-set ByLaws which permit users possessing certain permissions thresholds, or the community on the exercise of a quorate vote of the relevant type, to carry out certain actions.

The core of Eris is its system of ByLaws. ByLaws within the Eris system have been built to provide a cryptographic, blockchain friendly-analog to the role which traditional organizational governance ByLaws play. That is, they provide the permissions to take a certain set of actions and they define who among the group is entitled to take which actions. Eris’s ByLaws, however, are not simply a scripted refactoring of traditional ByLaws. Indeed, in order to regulate a ÐAO, one must have a level of precision in sequencing permissions and actions which are not required when an organization passes a traditional form of ByLaws.

Contracts deployed within the Eris system are hardened against attacks by responding only to specific API calls from addresses which are registered within DOUG as ByLaws. All of the databases, and storage systems used by Eris (which are kept on the blockchain in shortened form, with their longer sets of data being referenced out to the c3d system), form an intricate, interconnected, but modular, framework in which the ByLaws perform actions and the other contracts within the system largely act as stationary Objects on which the ByLaws operate. Programmers who have familiarity with how many object-oriented programming languages utilize Classes and Modules will be able to quickly see the Eris design pattern in action.

Transactions which seek to modify the distributed, blockchain held database, which is the DOUG and DOUG-module component of the Eris system, must be sent to the specific ByLaw which provides the action sequence to perform this action. Transactions which are sent to other contracts within the Eris system are rejected by their targeted contracts. This provides uniformity and resilience, while also abiding by standard separation of powers (from the legal world) and separation of functionality (from the programming world). The ByLaws, in combination with DOUG and other modules of the Eris system, have cognizance of the state of affairs within the ÐAO and are able to determine, based on that state of affairs, whether or not the actor requesting that an action be taken will indeed be taken.

The ByLaws rely heavily upon the Eris reputation module which, as previously noted, is separated into three reputational branches. Each user of the ÐAO will have two reputation scores upon the v0.1 release (an additional two reputation scores are on the work plan for v0.2). The reputation of any individual user increases or decreases based on a formula contained within the ByLaws. Different types of actions require different thresholds of reputation within different branches. Typically reputation is awarded for taking actions which the designers think are beneficial to the community and have reputation subtracted for taking actions (or not taking actions) which the designers think will cost the community in some way or another. A fuller discussion of how reputation levels and actions which those levels entitle users to follows below.

The ByLaws have been matched closely with the c3D and ui system to provide an integrated experience for users which will largely automate (and for the most part conceal) the complexity of working with the ByLaws directly.

As the first iteration of Eris will be limited in functionality (decentralised forums, reputation scoring and voting on platform issues, primarily) the list of permissions is limited. Furthermore, amendment of bylaws through Reputation Score has not yet been coded but is planned. The modularity of the platform means subsequent upgrades will be, as mentioned above, fairly straightforward to incorporate. ByLaws incorporated in version 0.1 include:

1. add active permissions – adds a Factory Contract for producing a vote to obtain a specific active permissions level;
2. add bylaw – adds a bylaw;
3. add permission – adds a new permission;
4. add to doug – adds a contract to DOUG registered under a name (removing a contract from DOUG is adding 0000 as the contract for that name);
5. flag post – what it says on the tin;
6. remove flag – as above;
7. promote post – promotes a flagged post for deletion;
8. remove promote – dismisses the promotion mentioned above;
9. blacklist post – adds post to blacklist, both obscuring it and deleting the original link;
10. move thread – moves a thread between topics;
11. perms – sets a permission for a target;
12. up/downvote – upvotes and downvotes a post;
13. remove permissions – sets that permission to 0;
14. create topic – creates new thread and adds to the decentralised forum;
15. create thread – creates new thread and adds initial post;
16. post to thread – adds a post to an existing thread;
17. Decentralised Banhammer – allows for arbitrary punishment (based on community supermajority vote) to be rendered on a target user (requires XORDCON to activate);
18. Membership Registration – registers users;
19. Create Issue – generates Factory Contract for broadcast to all users

Depending on the type of bylaw being activated, various thresholds will need to be passed. For example, the up/downvote bylaw requires only Standard Permissions and can be activated by any user of the ÐAO with sufficient Reputation Score.

Active Permissions require user-generated votes and the satisfaction of certain thresholds – an Ordinary Resolution, being a 50% quorum with a 50% majority (ORDCON), an Extraordinary Resolution, being a 75% quorum with a 50% majority (XORDCON) and a Basic Terms Modification (BTMCON) which requires a 90% quorum with a 75% majority of votes. In each case, quorum is floating over the life of the resolution (but is only able to adjust upwards); most bylaw amendments require a Basic Terms Modification to pass. However, adding a new contract to DOUG that does not remove an existing contract (ORDCON) and the Decentralised Banhammer (XORDCON) require lesser thresholds in order to pass. This will provide a balance between the efficiencies of lower consensus for less important actions with the resilience of higher consensus for more important actions.

The hard deadline of 17 June 2014 means the Project Ðouglas Dev Team has not had time to test all of the functions we would like for Eris v 0.1. Note, however, that the modular structure we propose means that the platform is designed to grow to match the needs and desires of the community that uses it. Ultimately we expect Eris’ development will primarily be driven independently from our efforts; our objective with Eris v 0.1 is simply to provide the overall framework in which that development can take place.

Eris v 0.2 will also include bylaw functionality for the Development and Judicial Branches described below.

3. REPUTATION

The system which the proposed ÐAO will embody is heavily influenced by the model developed to operate Stack Exchange. (For more information on the reputational levelling system used by the stack exchange group of sites, see Stack Exchange’s Privileges.)

We have developed this system for three primary reasons. First, it allows for a reasonable matching of the benefits and responsibilities of different types, modes, and levels of participation within the community. Second, levelling reputation is easier to mathematically define and utilize by both the ÐAO itself and the users of the ÐAO. In the future what specific privileges match to specific levels and the numerical values required to reach such value are more or less objective votes based on a numerical base rather than a subjective vote based on non-quantifiable words. Third, the system is built to incentivize users at all levels to contribute positively to the community in different ways depending on their skills, abilities, and interests. This system is relatively flexible and can be utilized in a variety of ways.

We envision at least three branches to the overall reputation levelling system. We envision that the ÐAO will develop reputation metrics for at least three different areas such as the reputation for development prowess, the reputation for wisdom, the reputation for building the community. The first phase of the ÐAO development will focus on developing the leveled reputation scheme based on content production in order to test the theories underlying our assumptions. Once those theories have been proven then the ÐAO could open up other branches of the reputation system. The minimum three branches of reputation we envision are discussed below. All branches should be accessible and attainable by a normal unprivileged user through sufficient contribution. Each branch represents a unique set of reputation which is unaffected by a user’s reputation in other branches of the system.

Initial entry into a branch rep system should be attainable by performing some entry action in another branch (most often the citizen branch). Furthermore mechanisms for loss of branch rep should be accessible through other branches (checks and Balances).

I. CITIZENSHIP BRANCH

The Citizenship program architecture will delineate the process for accumulating and exercising rights for every user of an Eris platform. The following functions have been envisioned:

a. up/down voting; b. proposals for (non-code related) changes to the ÐAO; c. proposals to remove someone from a position; d. content creation rights; e. General Votes (non-development) (for general votes, users will have their influence weighted through the reputational scoring matrix below; f. community content enforcement (decentralised moderation); and g. decentralised subcommittee and committee decisionmaking (Eris v0.2).

II. MODERATION BRANCH

The Moderation branch will serve as the primary vehicle for overseeing citizenship content. The following functions have been envisioned:

a. flagging content; b. recommending content for blacklisting; and c. voting on blacklisted content.

III. EXECUTIVE BRANCH (ERIS V.0.2)

The Executive branch will serve as skilled guardians of the source both of Bitcoin and of the ÐAO itself so as to ensure vulnerabilities do not get added. The following functions have been envisioned:

a. In charge of proposals to change the ÐAO and BTC on a code level. b. High level reputation users will be allowed to develop proposals to changes to the ÐAO and BTC code bases so long as one other developer at the same level joins the motion to submit changes to the ÐAO and BTC code bases. c. Mid levels can endorse changes once the high level reputation users have developed and submitted a proposal and can also join with four other developers to formulate a proposed change to the ÐAO and BTC code bases.

IV. JUDICIAL BRANCH (ERIS V.0.3)

The Judicial Branch will have the roll of deciding on users’ continued participation in the system in the event of serious violations.

a. Act as a first port of call in the event of a dispute over the content or validity of a particular action or broadcast. Responsible for determining the factual matrix surrounding a smart contract transaction. b. Any issue which cannot be resolve by a consensus would be sent to the Judicial/Disputes Branch.

REPUTATION LEVELLING – MATRIX AND ACTIONS

At Project Ðouglas we think that maximum flexibility is vital in order to demonstrate the use-value of decentralised computing technology. Given the fact that Eris’ architecture is modular and upgradeable, there is no reason that organisations should not be able to adapt Eris for their own purposes to change both the types of activity (and the permission thresholds such activities require) based on their own application-specific needs.

The ÐAO has been designed in such a way which reputation will be granular. Each project which the ÐAO engages in will be able to deploy a reputation system simply by deriving the benefits which match to levels of reputation and the formula for calculating reputation outcomes to DOUG who will be able in the future to automatically deploy the reputation metrics on a per project basis.

The tables below are indicative of the intended reputation thresholds we intend to deploy in subsequent versions of Eris, but have not had sufficient time to code up separately for version 0.1 (note most of the bylaw functionality is incorporated already). It will not be technically difficult to finalise these thresholds and Reputation Score permissions within the next few weeks.

These numbers may be subject to change depending on the outcome of early tests and the evolution of the DOUG platform (currently in version 7).

CITIZENSHIP REPUTATION THRESHOLDS AND POWERS

Goal: filter issues and content relevant to the community; self-police content according to Community consensus.

DEVELOPMENT REPUTATION THRESHOLDS AND POWERS

Goal: To maintain the ÐAO code and structure, and edit the code when necessary. Reputation on this branch will be determined by an electoral process.

JUDICIARY REPUTATION THRESHOLDS AND POWERS

MODERATION BRANCH THRESHOLDS AND POWERS

(-) if it is not promoted

4. FACTORIES

DOUG will permit and encourage the creation and use of standardised smart contracts in blockchain-mediated peer-to-peer applications. These discrete contracts will be generated by “smart contract factories” (Factories).

In principle, any agreement which is reducible to code is amenable to expression as a Factory Contract (a standardised form of contract which can be replicated on repeated occasions, with each particular iteration being written to conform with transaction-specific parameters). These contracts can be either standalone (and thus settled on a peer-to-peer basis) or by reference to DOUG (in the case of the consensus-gathering and Community-driven functions outlined more particularly below).

Kickstarter-type contracts will be able to be generated by the AÐAO’s Contract Factories, but they will be standalone in their operation and operated outside of the Association’s ambit.

It is envisaged that as development of the AÐAO progresses and a greater degree of certainty is achieved, Factory-made contracts will be linked to off-chain legal agreements and identification procedures in order to permit, e.g,. the taking of security, the incorporation of trustless arbitration (as proposed by Vitalik Buterin), or the possibility of real-world enforcement. The extent to which this added functionality is available and useable under the aegis of the AÐAO will be largely dependent on the availability of appropriate code, contributed by the Community, capable of incorporating these legal obligations by reference, as well as market demand.

5. TRUSTLESS REPRESENTATION

In the legal structure we will implement in conjunction with the AÐAO, the Board of the Association will be required to consider and respond in writing any Issue which passes by an ORDCON majority within a reasonable time.

Functionality for polling will be similar to functionality for voting and will be included in subsequent versions of Eris.

6. TRUSTLESS DEVELOPMENT FUNDING

Later versions of Eris will include a module for proposing, voting for, and funding the development of other applications or cryptoprotocols (Trustless Development/Trustless Development Function) which will expand the functionality of the cryptocurrency ecosystem as a whole.

Because we have left AÐAO development very open-ended, we do not expect much difficulty in adding this functionality into the DOUG bylaw structure.

The role of the AÐAO in this area will be to provide two integral functions to the development of blockchain technology. The first role the AÐAO will play, as explained above, is in the area of deriving the consensus position as to the direction that any individual platform or the platform as a whole should go – via community voting, or alternatively through support of bounties which will effectively support the development of the platform(s). The second role the AÐAO will play is to act as the pointer to a Factory Contract which can serve as a trustless escrow agent for community funding of bounties and delivery of the resources upon satisfaction of the bounty requirements according to the terms of the bounties. Escrow of funds will not depend upon trusting human participants of the AÐAO; this functionality will be fully automatic, and will be controlled and isolated within the AÐAO’s smart contract system once the bounty has been endorsed and funded at a sufficient level.

The Trustless Development Funding Function will be conducted in roughly the same way as the Factory Contracts we have made available in v 0.1. However, given the added legal sensitivities associated with crowdfunding and money transfer, we have designed “master keys” which are capable of removing DOUG pointers to projects which are illegal or reasonably apprehended to be contrary to legal rules or public policy objectives.

7. MASTER KEYS

We have also included two “Master Key” functions which are hard-coded in DOUG itself and cannot be changed.

The first of these is Firestorm, a backdoor key which is generated on the creation of an Eris-based ÐAO. Executing Firestorm effectively destroys the AÐAO forever. Factory Contracts generated prior to the execution of Firestorm will continue to self-execute.

Waterbucket or the Community Override is a community-useable key which, upon activation, deactivates Firestorm permanently.

8. C3D: STANDARDISING THE SMART CONTRACT

c3D contracts have a standardized structure which is used by the c3D system to push and pull information to the contracts. By standardizing the interfaces, we are able to provide users and the ÐAO itself with unparalleled extensibility.

Using the following legend…

• (A) indicates this field points to a Storage address
• (B) indicates this field should be filled with a blob_id value
• (C) indicates this field should be filled with a contract address
• (B||C) indicate either (B) or (C) is accepted
• (K) indicates this field should be a (public) Address
• (I) indicates this field is an indicator and can take one of the values in []
• (V) indicates a value

…we outline the types of contract c3D can accommodate below:

DOUG AND C3D CONTRACT TYPES

c3D contracts come in four flavors, each of which is connoted in the 0x10 storage slot:

1. 0x10 : (I) : 0x88554646AA — Action Contract Only (no c3D data is attached to this contract)
2. 0x10 : (I) : 0x88554646AB — c3D Content (data) Contract
3. 0x10 : (I) : 0x88554646BA — c3D Structural (meta) Contract
4. 0x10 : (I) : 0x88554646BB — Action Contract + (c3D Structural Contract)

For the purposes of this documentation, AA contracts are simply indicators for the c3D system. c3D will take no action when a ÐAO link points to an AA contract.

BA CONTRACTS — C3D STRUCTURAL CONTRACTS

TOP LEVEL CONTRACT STORAGE SLOTS

• 0x10 : (I) : [0x88554646BA]
• 0x11 : (B||C) : pointer to an applicable datamodel.json
• 0x12 : (B||C) : pointer to an applicable set (or single) of UI file(s) structure
• 0x13 : (B||C) : content
• 0x14 : (C) : Parent of this c3D contract
• 0x15 : (K) : Owner of this c3D contract
• 0x16 : (C) : Creator of this c3D contract
• 0x17 : (V) : TimeStamp this c3D contract was created
• 0x18 : (A) : Linked list start

HELPFUL COMPATIBILITY DEFINITIONS FOR TOP LEVEL STORAGE (PRIMARILY USED BY DOUGS BYLAWS)

(def 'indicator 0x10)
(def 'dmpointer 0x11)
(def 'UIpointer 0x12)
(def 'blob)
(def 'parent 0x14)
(def 'owner 0x15)
(def 'creator 0x16)
(def 'time 0x17)
(def 'LLstart 0x13)

INDIVIDUAL ENTITY ENTRIES

• (linkID)+0 : (A) : ContractTarget (for DOUG NameReg)
• (linkID)+1 : (A) : Previous link
• (linkID)+2 : (A) : Next link
• (linkID)+3 : (I) : Type [ 0 => Contract || 1 => Blob || 2 => Datamodel Only ]
• (linkID)+4 : (V) : Behaviour [0 => Ignore || 1 => Treat Normally || 2 => UI structure || 3 => Flash Notice || 4 => Datamodel list || 5 => Blacklist]
• (linkID)+5 : (B||C) : Content
• (linkID)+6 : (B||C) : Datamodel.json (note: if the content is a pointer to an AB contract this would typically be blank)
• (linkID)+7 : (B||C) : UI structure (note: if the content is a pointer to an AB contract this would typically be blank)
• (linkID)+8 : (V) : Timestamp

HELPFUL COMPATIBILITY DEFINITIONS FOR LINKED LIST ENTRIES (PRIMARILY USED BY DOUGS BYLAWS)

(def 'nextslot (addr) (+ addr 2))
(def 'nextlink (addr) @@(+ addr 2))
(def 'prevslot (addr) (+ addr 1))
(def 'prevlink (addr) @@(+ addr 1))
(def 'typeslot (addr) (+ addr 3))
(def 'behaviourslot (addr) (+ addr 4))
(def 'dataslot (addr) (+ addr 5))
(def 'modelslot (addr) (+ addr 6))
(def 'UIlot (addr) (+ addr 7))
(def 'timeslot (addr) (+ addr 8))

AB CONTRACTS — C3D CONTENT CONTRACT

TOP LEVEL CONTRACT STORAGE SLOTS

• 0x10 : (I) : [0x88554646AB]
• 0x11 : (B||C) : Datamodel.json
• 0x12 : (B||C) : UI structure
• 0x13 : (B) : content
• 0x14 : (C) : Parent
• 0x15 : (K) : Owner
• 0x16 : (C) : Creator
• 0x17 : (V) : TimeStamp

HELPFUL COMPATIBILITY DEFINITIONS FOR TOP LEVEL STORAGE (PRIMARILY USED BY DOUGS BYLAWS)

(def 'indicator 0x10)
(def 'dmpointer 0x11)
(def 'UIpointer 0x12)
(def 'content 0x13)
(def 'parent 0x14)
(def 'owner 0x15)
(def 'creator 0x16)
(def 'time 0x17)

• Bitcoin Could Change Voting the Way It’s Changed Money
• Can Ethereum kill Bitcoin with self-executing contracts?
• Web 3.0 – A Chat With Ethereum’s Gavin Wood