Home Bounties Rules Blog Trello
Crypto Castle on GitHub Chat on the Crypto Castle Discord Find rewards on Trello

View RULES HISTORY

Crypto Castle DAO Rules V1.0 #

Contents #

  1. Crypto Castle

  2. Bounties

  3. Contributing

  4. Admins

  5. Funds

  6. Resources

1 Crytpo Castle #

Crypto Castle is fully open-source DAO governed and funded by the JMES Blockchain.

The Castle is (a candidate for) the Core-Engineering DAO slot in the JMES Protocol, which develops and maintains the Official JMES World Core Software, such as the Validator and Official Mobile wallet app.

The DAO is a non-profit, non-commercial DAO, that raises its funding from the JMES blockchain’s Governance System and redistributes JMES issued from block rewards to users who produce open-source output that forwards our Strategy in support of our Vision.

The DAO uses its own micro-incentive based Bounty system to fund and manage the end-to-end delivery of a wide variety of projects proposed by the community, ranging from small jobs such as bug bounties, to ongoing services such as promotions or infrastructure provision, to mid-size development projects such as protocol and end-user software development.

Fund allocation and management is decentralized across Admin users who are incentivized with a percentage of the JMES they award on Bounties and a PO role responsible for fund management.

The DAO is classified as an open-source DAO, meaning that all finances and internal operations of the DAO are conducted in the public domain at all times. This includes how work is proposed, selected, specified, developed, tested, approved, which users are completing or managing work, what rewards they are allocating or receiving and all internal decision making and governance.

All work produced by the DAO, known as Output, including the DAO’s software itself, is open-source and licensed under MIT License.

All handling and allocation of DAO funds can be publicly verified down to user-task level via the auditing using the blockchain in realtime.

1.1 Mission #

The Crypto Castle’s mission is to support the JMES Network by producing the most innovative, secure and reliable software for the JMES Blockchain and its users.

1.2 Vision #

Our vision is for JMES to become the number one cryptocurrency for tokenizing real-world physical and digital art in all its forms, supported by a community of incentivized and empowered Artists creating art for our users to own and enjoy within a rich ecosystem of digital and physical experiences.

1.3 Strategy #

The DAO’s strategy is defined as a set of criteria that defines the types of Bounties that Admins can fund, coupled to a Roadmap that defines priorities that Admins use to allocate and prioritize resources across Bounties, to ensure that resources are focused effectively in support of our Mission and Vision.

1.3.1 Funding Criteria #

Admins may fund Bounties that meet the following criteria:

  1. Funding Protocol design and development of the JMES blockchain to support and implement the DAO’s Strategy, such as Validator software and Smart Contracts on JMES’s Business Layer.

  2. Funding end-user software, such as the Official JMES Wallet app, the Official JMES Governance App, or any kind of monetization or tokenization usecases that increases the economic usage of JMES as a currency for art.

  3. Funding the development and provision of tools and resources that aid developers, users and providers within the JMES Ecosystem.

  4. Funding development that improves onboarding for JMES users.

  5. Funding development that improves and sustains the DAO itself.

  6. Funding Infrastructure development, maintenance and provision to support and implement the DAO’s Strategy as needed.

  7. Funding promotion of JMES related software to developers and end-users.

  8. Funding activities in other DAOs with synergistic Strategies where doing so will expedite, support or unblock resources or products upon which our Mission depends.

  9. Kickstarting initiatives that help to support and retain developers who are key to the JMES project in general.

  10. Kickstarting DAO forks with synergistic Strategies to increase competition and decentralization within the JMES ecosystem.

Bounties that don’t meet any of these criteria won’t be funded by the DAO.

The term Kickstarting is used in the DAO to mean the funding of Bounties that initiate projects but include a plan to hand them off to 3rd parties to fund and monetize their longer-term development, including potentially raising individual Proposals to accomplish that.

1.3.2 Roadmap #

Our Roadmap is the list of priorities by which we allocate resources between Bounties and is stated in the most recent Proposal.

1.4 Full-Transparency #

To ensure that the DAO’s processes and information remain fully open-source and encourage the same standard for other DAOs on the JMES Blockchain, we introduce the following criteria for an Open-Source DAO classification that the DAO implements:

  1. All funding receipts and expenditure are tracked

  2. All work systems and their data are public

  3. All work preparation and pricing is public

  4. All work output is public

  5. All people’s work and rewards are public and verifiable

  6. All rules governing the DAO and decisions on how to maintain those rules are public

The only exception would be user credentials, i.e. their login passwords.

1.5 Users #

There are several levels to classification of DAO users as follows:

Currently all Members can be found as the members of our Trello board

1.6 Network Contract #

This document contains the Rules that define the terms between DAO and the Network for how any funding awarded to the DAO by the Network will be used.

When coupled with DAO’s full transparency policy, anyone can trustlessly audit how well the DAO is meeting the commitments of these terms in realtime, including verifying the use of all funding via the JMES blockchain itself down to a user/task level.

We refer to the transparent implementation of the terms defined in this document in return for the funding provided from JMES Network as the Network Contract.

The DAO is required to abide by the Network Contract at all times.

The authoritative source for the Rules are contained in a single document hosted on Github, with updates to the Rules (enacted as merged commits to the master branch) taking effect immediately.

The DAO is an open-source DAO and not a legal entity and as such doesn’t own any assets, including any rights to any output, nor does the DAO apply any restrictions on contributor’s usage of their own Task output, apart from the requirement that all output must be licenses as open-sourc under a license such as MIT or Apache.

The only funding the DAO receives is in the form of JMES tokens issued directly from the JMES blockchain, which it redistributes to users who provide verifiable open-source output for predefined tasks approved by Admins, who agree to operate in accordance with the Rules defined in this document.

The DAO does not handle, hold or pay fiat currency and all rewards are issued in JMES tokens as incentives for creating some open-source output, at the sole discretion of DAO Admins, and without any agreement or action to purchase or procure any assets, intellectual property or labor.

2 Bounties #

A Bounty in the DAO means a collection of work that can be completed by contributors for a reward, such as development or promotion of the Network or of the DAO itself.

Bounties are first proposed as Concepts by the community, and there are four types of Bounty that can be funded, each containing a series of Tasks that are managed by the Bounty’s Admin, who earn a % commission of all rewards that the Bounty generates.

2.1 Concepts #

All Bounties start as a Concept that is proposed to the DAO by a community member.

Concepts are proposals for some work that the DAO should fund as a Bounty, that provide enough detail about the value proposition and requirements of the work to enable Contributors to complete it.

Admins create a Bounty for each Concept they Accept that they then Own, meaning they have the rights to manage and earn commission from its delivery.

Admins can Accept any Concept that meets our Concept Acceptance Criteria on a first-come first-serve basis.

Once accepted, the user who created the Concept is automatically assigned as a Stakeholder to the corresponding bounty and awarded a task for the submitted Concept.

2.2 Bounty Types #

When a Bounty is created from a Concept by an Admins, they assign one of four types for the new Bounty that determine how work will be structured:

All Bounties in the DAO are represented by a Card on our Trello board. The Bounty’s type is represented by the column the Card is in on the Board. Meta Bounties are shown with the pink label on the Card’s front cover.

2.3 Bounty Status #

Each Bounty can be set to have one of the following Statuses at any time:

2.4 Bounty Stakeholders #

For some bounties, Admins may wish to regularly solicit the views of subject area experts or other key stakeholders as part of the decision making process when defining bounty tasks.

Whilst bounty administration remains under the control of the Admins of the bounty, a record of these Stakeholders, the nature of their interest, and the circumstances under which they should be consulted, may be added to the Bounty data.

Concept creators are automatically added as Stakeholders of any Bounty that derives from the Concept.

On Trello, the stakeholder usernames are added to the Card’s description in a Stakeholders section by the primary or secondary Admin, including any additional information on the context for their involvement.

2.5 Tasks #

A Task is the basic unit-of-work in the DAO and represents a unit of open-source output that a user can produce for a specified reward.

All work in the DAO, and consequently any use of funds, is performed via completion of a Task by a user, or the management of that Task by an Admin, within a specific Bounty.

Tasks are defined by Admins and can be completed by any user after reserving the tasks with the Admin, or in the case of Job tasks, completed without reservation.

Each Task must define some quantifiable Output (a document, commit, etc) that a user can produce to be eligible to Claim the specified reward.

There are four types of Task available:

Each Task Type is represented as a named Checklist on the Bounty’s Trello Card, except for Concept Tasks, which are implicitly completed when a Concept is Accepted by an Admin.

2.5.1 Concept Tasks #

A Concept Task is defined as the submission of new Concept by a user.

The Claim for a Concept Reward is considered to be implicit and approved as soon as an Admin Accepts the Concept.

Note that several Bounties can be forked from a single Concept, however, the Concept reward is only paid the first time the Concept is accepted.

2.5.2 Specification Tasks #

Specification Tasks define how Production Tasks should be completed and QA’d.

The output is usually a document such as a Design Requirements doc, Functional Specification, or any resource that enables output relating to achieving the Value Proposition of the Bounty to be produced effectively.

Admins measure the quality of the Specification in terms of its fitness for purpose and adequate detail level to define the Production Tasks a Contributor needs to implement it.

2.5.3 Production Tasks #

Production Tasks are the actual output of a Bounty that deliver the value proposition.

Usually Production Tasks output some code or a working product, but if the Bounty is for example a research project, the Production Tasks could output documents or analysis, or any format that satisfies the goals of the Bounty.

2.5.4 QA Tasks #

Quality Assurance tasks validate and test that Production Tasks meet their Specification.

Most Production Tasks should require related QA tasks, and Specifications should include a QA plan to provide a clear and easy way to measure how well a Production Task meets its spec when the QA is performed.

QA Tasks must reference the relevant Specification or Production Task and produce some QA report output.

It is recommended to use the QA Report Template unless the admin requests an alternative format.

2.6 Claims #

A Claim is the process of a user signalling that they have completed a Task and wish to receive the Task’s stated reward.

Users can create Claims for Tasks they believe to be complete from the Admin who owns the Task using the Claims process.

Once a Task Claim is approved by an Admin, the Task Reward will be awarded to the JMES address the claimant specified in the Claim within 7 days.

2.7 Rewards #

The DAO is a pure-coin fund meaning all rewards are awarded in JMES. It’s not permitted to create bounties with non-JMES denominated rewards, although individual users can be incentivized to exchange amounts out-of-band via tasks.

Each type of Task offered by the DAO has limits on the min/max rewards an Admin may price as defined below.

The Admin % is an added commission reward that an Admin earns for Approving a Claim on a Task they own, plus a commission bonus based on the Admin’s level of activity.

2.7.1 Price List #

Task Type Approval Criteria Amount Admin %
Concept Task Accepted Concept 0.5 JMES 10% - 15%
Specification Task Valid Specification 0.1-5 JMES 10% - 15%
Production Task (Project, Service, Programme) QA Complete 0.1-20 JMES 10% - 15%
Production Task (Job) Valid Job (to Spec or QA) 0.1-10 JMES 10% - 15%
QA Task Valid QA Report 0.1-5 JMES 10% - 15%

3 Contributing #

Contributing to the DAO involves completing Tasks on Bounties to earn Rewards.

A reward can also be earned by proposing a Concept for new Bounties that get accepted by an Admin.

All work produced at the DAO must be open-sourced under MIT license before any rewards can be paid, to satisfy the DAO’s full-transparency requirements.

3.1 Proposing Concepts #

Anyone can create a Concept by submitting a New Concept.

Any Admin can Accept a Concept that meets our Concept Acceptance Criteria, meaning they create a new Bounty for it that they become the owner of.

The Concept Reward is paid to the JMES address listed in the Concept if and when it is accepted by any of the Admins.

  • To chat with Admins about a Concept or its acceptance, join the Discord.

3.2 Completing Job Tasks #

Job Tasks on Bounties are open to be claimed by anyone without needing to reserve the task.

To claim a reward on a Job task, use the Claims process

3.3 Reserving Tasks #

Any tasks other than Jobs can be reserved. This means that you can agree with the Task’s Admin to have exclusive rights to claim the Task until the due date.

To reserve a task, leave a comment for the Admin of the Bounty that the Task is a part of, so that they can assign the task to you, and/or discuss the Task details and negotiate the reward.

Once you have completed the Task, use the Claims process to claim the reward.

If a claim isn’t made by the due date, the Admin can extend the date, or has the option to cancel the reservation.

To be able to Reserve a Task please join as a Member of our Trello Board by leaving a comment on our Member Signup Card.

3.4 Claiming Tasks #

Once you have completed the work for a Task you can make a Claim for the reward on the Task, by providing the following information:

  1. Link to the source for the tasks output (specific PR or commit for Github code)

  2. Link to any deploy links relevant to the output (e.g. a URL for a website)

  3. Specify a valid JMES address to receive the reward, or set to NULL to decline the reward.

Once your Claim has been created it will processed by an admin.

To create a Claim on Trello, leave a comment on the Bounty’s Trello Card specifying the number and type of the Task you are claiming, along with the source links and your JMES address

3.4.1 Null Claims #

In some cases, users wish to decline rewards for some reason.

This is strongly discouraged as incentives are how DAO maintains a high level of creativity, productivity, and quality of output, and Claims themselves are how we track and account for work completion in the Bounty System.

However, to support the requirement, we introduced the option to create a Null Claim.

Therefore users who wish to decline rewards still need to make a Claim to signify and enable tracking of a Task’s completion, but they can set the claim’s JMES address to ‘NULL’ to signify that the actual reward is declined and therefore won’t be awarded.

To create a Null Claim in Trello, simply enter the term ‘NULL’ in place of a JMES address on the relevant Claim comment.

4 Admins #

Admins are a second-tier of users in the DAO who are incentivized to manage Bounties by earning a commission on all Tasks completed within the Bounty.

As all work (and spending) is structured as a Bounty within the DAO, and Bounties can relate to working on the DAO itself and be both managed and produced by Admins, they represent a decentralized layer of users who manage every aspect of the DAO.

Admins are peers, each with control of a share of the DAO’s funds that they can use to create and manage bounties that incentivize Contributors to produce output for the DAO.

Admins can simultaneously act as Contributors, by completing Tasks set by other Admins, but they cannot price or reserve Tasks for themselves.

Admins have additional rights to appoint other Admins and to maintain the Rules defined in this document, which define all aspects of how the DAO should operate, which they are each responsible for implementing correctly.

On Trello, the board is configured to only allow Admins to create and edit cards, including defining and assigning tasks to Board members. Any user can comment on cards to interact with Admins about the bounties they’re managing.

4.1 Accepting Concepts #

Bounties are created via the Acceptance of a user-submitted Concept by an Admin.

  • The Admin should also add an entry to the Payments Sheet, using the user’s details and JMES address from the Concept they submitted

4.1.1 Concept Acceptance Criteria #

Admins must judge that Concepts they wish to Accept meet all of the following criteria:

  1. Provide a clear Value Proposition that can return value to JMES that’s inline with our Strategy and Vision

  2. Provide enough detail on requirements to enable a Bounty to achieve the stated goals

  3. Be technically feasible using the current JMES Protocol or some unreleased but known iteration of it

  4. Be unique within the existing set of Concepts & Bounties already added to the DAO, i.e. not a duplicate or very similar scope to an existing active Bounty

  5. Be achievable in terms of costs compared to the DAO’s current funding levels

4.2 Bounty Management #

  1. The Description text reflects the Value Proposition of the related Concept.

  2. The Concept creator is listed as a Stakeholder

  3. Optionally appoint a Secondary Admin for the Bounty

In Trello, Bounty ownership is designated by assigning the Admin user as the Member of the card on the top left below the card title. When two Admins are assigned to the card, the secondary Admin is designated by putting their Trello username into the Secondary Admin field on the card.

4.2.2 Bounty Ownership #

The Admin who created a Bounty is given the rights as the Owner of that Bounty, also known as the Primary Admin of the Bounty.

The Bounty Owner has exclusive rights to edit the Bounty’s fields, define Tasks and process resulting Claims, and change the Bounty’s Status.

The Bounty Owner may transfer ownership to another Admin at any time.

In Trello, Ownership is determined by the Admin who is a Member of the Card and who’s username isn’t specified in the Secondary Admin field.

4.2.3 Secondary Admins #

The Bounty Owner can optionally appoint a Secondary Admin (Secondary) to the Bounty, enabling a maximum of two Admins to manage a bounty at one time.

Secondaries cannot edit the Bounty’s details but can create Tasks that they own within the Bounty independently from the Bounty Owner’s Tasks, and process Claims on those and receive their Admin Reward.

This enables multiple Admins to manage a single Bounty and complete Tasks provided that those Tasks are owned by another Admin on the Bounty.

The Bounty’s Owner Admin can transfer the Secondary slot to a different Admin at any time, or remove the Secondary altogether without their agreement, however, the removed Secondary will still retain control of any Tasks they owned on the Bounty.

Secondaries can leave a Bounty or transfer the secondary position to another Admin who agrees at any time.

In Trello, Bounty Owners can appoint Secondaries on a Card by entering their name in the Secondary Admin field and assigning them as a Member of the Card.

4.2.4 Forking Bounties #

Apart from creating a new Bounty from a Concept, Admins have another option to fork a Bounty, by creating a new Bounty that shares the original Concept but is providing some significant modification, revision or alternative implementation to the Bounty that is being forked.

In Trello, a fork can be created from a Bounty’s Card by just making a new Card and linking the Concept that both Card’s share in the Concept Doc custom field of the card.

4.3 Task Management #

4.3.1 Creating Tasks #

Admins can create Tasks on any Bounty that they’re the current Owner or Secondary Admin of.

When creating a Task, the Admin sets the Description, which must provide enough information to allow a Contributor to complete the work, either in the description itself or by linking a Specification.

The due-date is the date whereby if a Claim is not made for the Task, the Admin has the option to cancel the task or cancel any reservation at the Admin’s discretion.

When defining a Task in Trello, the Admin will chose the correct Checklist for the task type, and specify the following information:

  1. A Task number, which is the sequential number of the Task in the relevant Checklist
  2. A Description, summarising the broad requirements by a short definition is needed, and a link to a Specification to provide further detail if needed.
  3. An amount of JMES for the Reward. This can be negotiated between the Admin and prospective users
  4. The name of the Admin who created the Task (i.e. the Task Owner)
  5. When reserving a Task for a user, specify the due-date and assign the Trello user as the member on the Task

This information should be entered into the Task description in the following format:

[taskNumber][taskDescription](AdminUsername)([amount] JMES)

4.3.2 Task Ownership #

When either the Primary or Secondary Admin defines a Task they become the Owner of that Task.

A Task owner has exclusive rights to:

If an Admin leaves a Bounty, for example via Owner transfer or removal of a secondary, the leaving Admin retains ownership of their own Tasks after they left, until they are completed or they decide to transfer their ownership to another Admin.

If a Task has an unprocessed Claim for more than 5 days with no response to the user from the Admin, the other Admin on the Bounty can take ownership of the Task to process the Claim and receive the commission reward.

On Trello, Admin ownership is designated by the name of the Admin user in the Task description. Secondly, any Task without an Admin username in the description is considered to be ‘open’, meaning the other Admin on the card can process it and receive the reward.

4.3.3 Pricing Tasks #

Pricing Tasks in the DAO takes a different and more flexible approach to traditional methods of sourcing as it factors in externalities such as priority, time constraints, skills availability (or overheads due to sourcing additional resources) and productivity incentives, whilst factoring out notions that ignore these factors such as fixed hourly-rates, market-rates or salary-based arrangements that won’t necessarily achieve our goals at the speed we want or with the level of productivity we want to achieve for the value we want to deliver.

For example, if Tasks are urgent or highly specialized and resources are not available, or Tasks have existed for a long time without uptake, higher rewards can be set to achieve uptake on the Tasks, including the option to offer rewards for promoting those Tasks and/or placing the necessary resources, which can result in reward levels above traditional “market rates” to deliver the output we want in the time needed.

On the other hand, low priority tasks with multiple resources already on-boarded and available who could under-bid each other and without time-constraints can often provide output well below “market rates”.

In other words, Tasks should be priced via a process to discover what is the minimum reward level needed to incentivize a Contributor to deliver something and deciding whether externalities such as needing to find & onboard the necessary resources or meet a certain deadline need to be factored in based on the Bounty’s priority.

Fiat prices should be taken into consideration when a Task is created, but Tasks shouldn’t be repriced if the fiat value changes unless not doing so would prevent completion of the Task.

4.3.4 Reserving Tasks #

Except for Job Bounty types, Admins must reserve Tasks to a specific user for the Task to be considered Active.

Admins can arrange reservations and negotiate the Task’s terms with the user within the comments or via private communication, but once the Task is reserved to the user, the terms are considered agreed and are public information.

On Trello, Tasks are represented by Checklists on the Bounty’s Card, and are reserved by setting the Member setting to the user who reserved the Task and setting a date in the Due Date field.

4.3.5 Processing Task Claims #

When a user completes a Task, they create a Claim that the Task Owner Admin needs to process to decide if the Claim can be Approved, if QA is needed, or if there are issues that need to be resolved.

Approved Claims on Tasks go into the Payments Sheet from which the reward will be sent to the claimant.

If a Contributor wants to dispute a Claim decision, they can ask for a second opinion, in which case the other Admin on the Bounty, or any other Admin if the Bounty only has one Admin, can provide a second assessment.

Ultimately, decisions on whether some output meets the requirements specified in the Task definition are the sole discretion of the Admin who owns the Task.

In Trello, Admins can Approve a Claim by ticking the Task’s Checkbox and leaving a comment on the Bounty card as follows:

Claim Approved: [@username][checklistName]([taskIds])([amount] JMES)

For example:

Claim Approved: @somedev Production Tasks (1,2) (1 JMES)

Admins must then enter the details into the Payments Sheet, filling in all columns and double checking the user’s payment address and reward amount, to enable the claim to be awarded.

4.3.6 Retention of Task Output #

Note that Admins must ensure that the output from Tasks that are approved is retained by the DAO, for example in a Google Sweet, Github org or any other type of data repository owned by the DAO itself.

This is because if contributors have stored the output of their tasks on their own GDocs, Github accounts etc, over time that output can get lost.

So its key that the DAO keeps at least a copy of all output produced, but ideally contributors work directly on DAO owned data repositories and not their own, so that all output is under the control of the DAO from inception, also so that in edge cases where there are disputes, the DAO isn’t left without any of the work it might have partially rewarded.

4.4 Admin Rewards #

Admins are incentivized via a baseline reward as a % commission on all Claims that they award on Bounty Tasks that they own, using the rates defined in the Price List, plus additional commision bonuses for the most active Admins.

Admins can earn additional rewards by completing Bounty Tasks themselves, provided they are defined and approved by another Admin that is Primary or Secondary Admin on the Bounty, in other words, Admin’s can’t set and price their own work, but they can set and manage work for each other if needed.

Admin rewards for commission on tasks don’t require formal claims, they are issued automatically to a Bounty Admin when the associated Tasks are awarded via the Payments Sheet.

Note that Admins can also opt to decline rewards by creating a Null Claim on their commision within a Task Claim.

To set a Null Claim on their Commission Reward, an Admin should enter their JMES address as ‘NULL’ in the Claim in the Payments Sheet

4.4.1 Commission Bonuses #

Each individual Admin’s commission is variable based on the number of Task Claims they Approved in the previous 30 days (including “today”). The commissions that Admins can earn are tiered as follows:

# of Claims Approved Commission Rate
0 - 14 10%
15 - 29 12%
30 + 15%

Each Commission Bonus is based on the Tier that the Admin’s previous 30 days contributions fall into. The “next” tier of commission is effective immediately once an Admin crosses the threshold, and is effective for all claims as long as the Admin stays within the Tier.

For example:

4.5 Governance #

Admins are responsible for Governance of the DAO which is implemented via appointing or removing Admins, or updating these Rules.

An Admin Quorum is required in both cases, which means that > 50% of voting Admins agree to Admin appointments / removals or changes to the Rules etc. Admins reserve the option to recuse themselves from voting by not registering a vote (within an agreed voting period) or selecting/commenting ‘Recuse’ against the vote itself.

5 Funds #

5.1 Proposals #

The DAO is funded from a series of Proposals submitted to the JMES Network on a quarterly basis, with all spending of those funds commissioned and tracked via Tasks owned by Admins within the Bounty System itself and settled via transactions on the JMES blockchain that anyone can verify.

The amount requested might vary to target the general scale and buffer that Admins and the PO feel the DAO should aim to spend, but not to deliver specific projects or milestones as there is no centralized planning to do so in the DAO.

When certain projects arise that do require specific additional funding, individual proposals should be raised detailing the value proposition and estimated costs of those projects individually.

5.2 Budgets #

All funds will be received to the published DAO Wallet address(s) and will be pooled across proposals as a single rolling-budget available to Admins to allocate to Bounties.

The funds the PO requests from the JMES Network are purely to increase the DAO Wallet and increase the overall budget available to Admins to spend.

DAO is a pure-JMES fund meaning that rewards are denominated only in JMES. Therefore any fluctuations in the fiat price of JMES will only reflect the pricing of new Tasks by Admins and prior agreements made in JMES are not necessarily renegotiated or adjusted.

5.3 Proposal Owner #

The Proposal Owner (PO) is the Admin user who creates Proposals to the JMES Network for and on behalf of the DAO, and handles (but isn’t liable for) custody and transactions of the JMES received on behalf of Admins.

The PO agrees to use funds solely for the purposes of awarding Task Claims that were approved by Admins and are inline with the Rules in this document.

The PO role is intended to be a temporary role, until the DAO can be implemented as a fully decentralized dApp in future, with Proposal JMES awarded to a Smart Contract and distributed autonomously using code.

Before the full dApp implementation, and before fully decentralized mechanisms are innovated to ensure that all users are adhering to these Rules and operations of the Bonuty System are as efficient as possible, the PO is currently granted some additional rights equivalent to a ‘super-user’ as follows:

If the Proposal Owner needs to exercise any of these rights, it is an exceptional circumstance, so they must leave a comment (e.g. on Trello or Github depending on the action) detailing the action and explaining the reasons as to why an action was taken.

The Proposal Owner can be replaced through a vote for a new Admin to be the PO as per the voting criteria defined in Section 4.5 - Governance. If that occurs, the newly elected PO will assume all PO responsibilities and the existing PO will transfer all funds from the Proposal Wallet to a wallet controlled by the new PO.

The Proposal Owner role should be incentivized by a Service Bounty defined within the DAO’s Bounty System itself.

5.4 Auditing #

As an Open-source DAO, anyone can perform a full public audit of the DAO at any time, to check that all work is being conducted as per these Rules, and verify the rewards issued to individual DAO users for that work via the JMES blockchain.

Below we provide guidelines on how to audit the DAO from a financial, operational and output perspective, but people can devise their own audit strategies as they wish.

5.4.1 Auditing Accounts #

Every JMES of funding spent by the DAO must be accounted for via a Task Claim approved by an Admin with an associated transaction on the JMES blockchain.

Therefore we can verify that the total funds spent listed on the JMES Blockchain tally to total task claims awarded in the Payments Sheet to ensure that funds aren’t being spent from the wallet arbitrarily by validating that:

Note that each Task lists the transaction id, which can also be parsed individually to verify the total amount.

5.4.2 Auditing Work #

All work must be conducted inline with the Rules in this document and in the public domain. Therefore anyone can audit how well the work being conducted in the DAO is adhering to these rules at any time.

As a guideline, the following aspects of work are key areas to ensure the Rules are being implemented effectively.

6 Resources #

Below are links to all resources needed to access, fork or audit every aspect of the DAO, to satisfy our full transparency requirements.

6.1 Network #

Resource Link
Website CryptoCastle.tech
Block Explorer github.com/crypto-castle

6.2 DAO #

Resource Link
Website CryptoCastle.tech
Github github.com/crypto-castle
Rules DAO Rules
Chat Crypto Castle Discord

6.3 Bounty System #

Resource Link
Bounties Trello
Member Signup Signup
Request a bounty New Concept
Resources Tools & Resources

6.4 Accounts #

Resource Link
DAO Wallet TBC
Payments Sheet Payments Sheet

6.5 Proposals #

Resource Link
Initial Proposal TBC
-->