gamedaoco / gamedao-protocol Goto Github PK

Every extrinsic with string type params currently has BoundedVec<u8, T::StringLimit> type, which doesn't check the minimum length.

BoundedVec from std library has a lower bound, but BoundedVec from frame_support doesn't.
So, we should either find a BoundedVec with the lower bound or create our implementation.

Already raised a question: https://substrate.stackexchange.com/questions/4263/extrinsics-string-parameter-lower-bound-validation

User Story

As GameDAO Council I want to be able to control availability of protocol features:

• enable / disable protocol features via council vote
• emergency stop and restart
• immediate or blocktime based

Acceptance Criteria

Each major milestone contains different features, but the public availability may be phased in or out at different points in time or even may or may not be available on network a,b,c.

As launch support, we want to create a smooth transition from initial deployment to fully functional protocol suite. To achieve this, we want to enable features after periods, e.g.:

1. Tokensale
2. Token Generation
3. Protocol Core Launch
4. DID, DAO
5. Staking
6. Voting
7. Grants
8. Fundraising

Additional Information

Discussion:

• https://www.figma.com/file/sCvZGzghEHSKKNeXtMdi3W/Protocol-Config-Pallet?node-id=0%3A1

How to test

1. create a voting to enable feature x on block y
2. see x enabled on chain at destination block y

to be specified:

• expose state via graphql

• unwrap() issue. Avoid panics at almost any cost in the runtime and add "proofs" for expect() calls on why they cannot fail. The only reason to panic should be in case a block should not be built when that code path is triggered or when it indicates a bug. It is only ok for tests and benchmarks. E.g. https://github.com/gamedaoco/gamedao-protocol/blob/main/signal/src/lib.rs#L903

• In most cases you should handle the Error. More use of ok_or , unwrap_or , ? , or returning Err in a matching pattern.
  E.g not properly handled:

  • https://github.com/gamedaoco/gamedao-protocol/blob/main/control/src/lib.rs#L667-L674
  • https://github.com/gamedaoco/gamedao-protocol/blob/main/control/src/lib.rs#L794-L802

• Unnecessary checking of errors already handled by the pallet methods:

  • E.g: https://github.com/gamedaoco/gamedao-protocol/blob/main/control/src/lib.rs#L785-L788
  • Instead, handle the error, for example making use of map_err: https://github.com/paritytech/polkadot/blob/master/xcm/xcm-builder/src/fungibles_adapter.rs#L246-L247

User Story

As user i want to create campaigns which start in the future, so that I can get my audience ready for funding.

Acceptance Criteria

Statement of Value

As a Creator
I want to create an "Upcoming" campaign
So that Contributors will be aware of it before it's activation

Acceptance Criteria

1. Add “Start date” parameter createCampaign extrinsic.
2. The “Start date” is the blocktime when a campaign will become active and a contributor will be able to contribute to it.
3. In status "0" (Init - not started) it is not possible to fund into a campaign
4. The “Start date” cannot be <= the expiry Daten
5. The minimum duration of a campaign is 24h
6. The maximum duration of a campaign is 60d.

Additional Information:

Campaign Statuses: https://docs.google.com/spreadsheets/d/1H6ZQMjveL5weN146BbKlXXdDAUxvDiVa9mSHruerq0s/edit?usp=sharing

related to frontend task: gamedaoco/gamedao-haiku#270

How to test

1. create a campaign with startdate bigger than expiry date --> not possible
2. create a campaign with blocktimes less than ~24h --> not possible
3. create a campaign with blocktimes bigger than ~60d --> not possible
4. create a campaign with startdate in the future and try to contribute into it --> not possible

• What is the purpose of ProposalsArray and ProposalCount and ProposalIndex? It seems it is never read and it just using storage. (maybe related with #53 )

• What is the purpose of CampaignsArray and CampaignsCount and CampaignsIndex? It seems it is never read and it just using storage. (maybe related with #53 )

Statement of Value

As a Creator
I want to add a reward to a campaign
So that a Contributor will be able to earn it by investing in my campaign

———

Acceptance Criteria

1. A Creator must be able to add a reward to a campaign with a "Draft" status.

2. Multiple rewards can be added to a campaign.

3. Adding a reward to a campaign is optional (a campaign can be created without a reward).

———

Additional Information

High-level process

User flows
User flows that outline the detailed process can be found here.

Describe the bug
After submitting a preimage in polkadot.js an error shows on the democracy.

To Reproduce
Steps to reproduce the behavior:

1. Go to polkadot.js
2. Click on democracy tab
3. Click the preimage button
4. Select control pallet and addMember Extrinsic and fill reasonable data (or use another one of our pallets)
5. Submit preimage and copy hash
6. Create proposal and enter preimage
7. see error message like in screenshot
8. try the same with another extrinsic (none of our pallets) and see there is no error

Expected behavior
democracy tab should work in any case, also when proposing a preimage from our pallets.

Screenshots

Additional context
Add any other context about the problem here (eg. device/browser)

Statement of Value

As a Contributor
I want to claim a reward
So that I will be able to sell or collect it

———

Acceptance Criteria

Given:
A campaign is successfully completed (campaign status is "Success")
and
A collectible has been assigned to a Contributor

When:
A Contributor claims a collectible

Then:
A collectible must be sent to a Contributor's wallet
and
A fee amount must be deducted from a Contributor's balance

———

Additional Information

High-level process

User flows
User flows that outline the detailed process can be found here.

As talisman wallet user I see my ZERO token in an odd shape compared to the other token:

Somehow it shows my 412.9 ZERO Token as a huge number.
It should rather show with 3 decimals.

========================================

Stage 1

• open branch migration/tangram

• update cargo.toml dependencies

• migrate structs to new macro syntax

• migrate storage to new macro syntax

• migrate events, errors to new macro syntax

• migrate pallet to new macro syntax

• add/fix commission calculation (fixed point arithmetic)

• write tests

• benchmarking

• add PR to main

Stage 2

Refactor assets to ORML:

• Network Transaction fees use local network native currency

• Deposits use GAME

• Payments use (depending on network) aUSD/PLAY/DAI/USDT

• suggest migration in architecture round

• extend this issue with new decisions

========================================

how to test:

• pull secondary repository from https://github.com/playzero/zero-network
• update submodule for gamedao-protocol based on your commit hash
• build

your build should result in no warnings by your added functionality.

User Story

As GameDAO we want to integrate aUSD into our parachain so our users can fund with a widely accepted stablecoin into campaigns and perform spendings.

Acceptance Criteria

1. https://acala.notion.site/Acala-Karura-Token-Listing-Playbook-GameDAO-c920045eaec24004b8874dbdcf25edf2

Step 1: Token registration form

The token registration form gives us the details that we use to add your token into the Karura network.

• [Generate & copy](https://docs.acalaswap.app/developer-guides/create-a-new-token#b.-governance-and-submission) the token’s preimage hash and DO NOT sign and submit
• Fill out the token registration form [here](https://forms.gle/kTmAeA2HmvY96kfx7)
• Notify Greg in Telegram once you have submitted

Step 2: HRMP Testing

• Schedule testing date with Greg in Telegram
• Designate a technical lead to conduct HRMP channel testing with Joey from Karura
• Conduct testing on scheduled date
• Joey to confirm once HRMP testing has been successfully completed

Step 3: HRMP off-chain governance post

To announce the intention to open HRMP channels between networks

• Draft and post HRMP off-chain governance proposal to the Karura Discourse

[Here](https://acala.discourse.group/t/open-hrmp-channel-between-parallel-heiko-and-karura/784) a good example of an HRMP off-chain governance post

Step 4: On-chain execution

Motion to open the HRMP channels and register Karura tokens

• Karura council to submit motion to open the HRMP channel and your team would need to accept
• Reciprocate the HRMP channel request to open the channel between your network and Karura
• Karura accepted the HRMP channel request
• Register KAR, aUSD, LKSM on your network using [this](https://wiki.acala.network/integrate/integration-1/protocol-info#multilocation) token registration info

Test token transfers

• Conduct token transfers with registered tokens

Marketing

• Share an announcement on your social channels that HRMP channels have been opened between networks. [Here](https://twitter.com/KaruraNetwork/status/1499859297232211968) is an example of one we shared with our community.
  Karura social will retweet your announcement. Please indicate in Telegram when this has been posted.

Step 5: Determine bootstrap and liquidity mining details

• Review bootstrap and liquidity mining presentation [here](https://docs.google.com/presentation/d/1wykDLHid07ekbxUUuSSMfHEicNl3q8Vq1gkwxPzEXSs/edit#slide=id.g10839bb3cf6_1_234)
• Schedule a meeting with Yuzhu to discuss bootstrap and liquidity mining details (if needed)
• Confirm bootstrap and liquidity mining rewards

Once bootstrap and liquidity mining rewards have been confirmed, we will then coordinate a listing date.

• Growth to coordinate listing date, time. When you submit your off-chain proposal you can submit it with the block number as TBD. When we are a week out from the start of bootstrap, we will select the block number and you can update the proposal and marketing information.

Step 6: Submit off-chain governance post, & on-chain proposal

• Draft and post off-chain governance post for bootstrap and listing. Block number for the starting and ending of bootstrap and liquidity mining incentives can be left as TBD and updated once we are closer to the start date.

[Here](https://acala.discourse.group/t/list-kint-kusd-pair-on-karura-swap-and-incentive-program-for-kint-kusd-liquidity-providers/802) is a good example for reference

Motion to create bootstrap and the listing

• Karura council to submit motion to schedule the bootstrap, listing, and mining rewards

Step 7: Start Marketing

Once the bootstrap and incentive parameters have been finalized, the next step is to prepare the co-marketing campaign. The objectives of the co-marketing campaign are as follows:

• Share the news of the bootstrap & listing in both your community and ours
• Increase awareness of your project & token in our community
• Share how your project integrates aUSD and share use cases

Please note, the Acala/Karura Growth team will provide you with block numbers for the start of bootstrap and liquidity mining programs when we are starting to put together the marketing pieces.

Below is a list of the recommended marketing materials and when we need them completed by to best support the listing:

Led by your team:

• SOCIAL: Tweet announcing the HRMP channels have been opened (completed)

• BLOG: Prepare the blog that outlines:

  • An overview of your project
  • Potential aUSD use cases
  • Bootstrap start date/block number & parameters
  • Liquidity mining incentives.

  [Here](https://docs.google.com/document/d/1ZKT5VClrGJGhVJ6pNWK7rDD-iziOnkQrTMRNBDHmpbg/edit?usp=sharing) is a document that outlines what should be included in the blog along with some suggested copy.

  [Here](https://medium.com/acalanetwork/bifrost-launches-on-karura-swap-with-over-200k-bnc-in-liquidity-mining-rewards-1ebec8e8ec15) is an example of a final blog that outlined bootstrap and liquidity mining parameters. Please remember to add the additional areas outlined above including a brief project overview and aUSD use cases.

• SOCIAL: Tweet outlining Bootstrap & incentive program linking to the blog (inform Acala so we can share)

  [Here](https://twitter.com/PhalaNetwork/status/1506240002367229958) is an example

• SOCIAL: Tweet announcing the start of bootstrap (on the bootstrap go live date) - please inform us so we can share

• SOCIAL: Tweet announcing trading is live & liquidity mining incentives (on the trading go live date) - please inform us so we can share

  [Here](https://twitter.com/PhalaNetwork/status/1509565027878985732) is an example.

Led by our team:

• Retweet announcing the HRMP channels have been opened (Completed)
• Discord AMA with our community 1-2 weeks before the start of the bootstrap. (Video will be provided for you to use for re-marketing efforts.)
• Retweet announcing the start of bootstrap
• Retweet announcing the pair is live for trading

Step 8: Bootstrap & listing go live and support

The bootstrap will go live at the designated block number. If bootstrap parameters are not met, the Karura team will re-engage in Telegram to coordinate additional support and next steps.

Additional Information

How to test

1. a
2. b
3. c
4. d

User Story

As #creator I want to be able to mint collectables on zero network so I can build new applications.

Acceptance Criteria

1. add RMRK protocol to zero network
2. enable creation of classes
3. enable minting of items
4. also a realm feature is needed to provide a map for classes created in a DAO context

Additional Information

How to test

1. a
2. b
3. c
4. d

========================================

Stage 1

• open branch migration/flow

• update cargo.toml dependencies

• migrate structs to new macro syntax

• migrate storage to new macro syntax

• migrate events, errors to new macro syntax

• migrate pallet to new macro syntax

• add/fix commission calculation (fixed point arithmetic)

• write tests

• benchmarking

• add PR to main

Stage 2

Refactor assets to ORML:

• Network Transaction fees use local network native currency

• Deposits use GAME

• Payments use (depending on network) aUSD/PLAY/DAI/USDT

• suggest migration in architecture round

• extend this issue with new decisions

========================================

how to test:

• pull secondary repository from https://github.com/playzero/zero-network
• update submodule for gamedao-protocol based on your commit hash
• build

your build should result in no warnings by your added functionality.

User Story

As organisation prime (controller of organisation) I want to create an organisation which has its own treasury so that the organisation can govern the treasury.

Acceptance Criteria

1. When creating an Organisation a treasury is created which is not owned by a single wallet address but from the organisation itself
2. Only accepted spending proposals can transfer funds from this treasury to another wallet
3. If an organisation has only one member (prime) the treasury does not need a spending proposal but the prime can just withdraw funds without accepted spending proposal
4. The Organisation Type defines if only spending proposals can withdraw funds from the treasury or also other roles (like PRIME)
5. The treasury must hold a minimum amount of the network currency to be able to pay the transaction fee

Additional Information

• Lets discuss AC4 & AC5

How to test

1. When gameDaoControl:create is done, treasury account is not an input parameter but will be created when creating the DAO
2. b
3. c
4. d

User Story

As a user, I want to change the organization, whether it's an Individual type or Dao type so that I can call the same extrinsic and not two as it works now.
Same applies to add_member, remove_member, disable_org, enable_org, make_spending.
It means moving proposal creation to the Control pallet scope.

Acceptance Criteria

1. a
2. b
3. c

Additional Information

How to test

1. a
2. b
3. c
4. d

User Story

1. As organisation council I want to propose the execution of extrinsics which belong to gamedao protocol:

• settings of the organisation
• membership action
• withdrawal and spending of funds in the treasury
• later on more will be added to the list

2. Furthermore:

• a PRIME controlled organisation is an organisation with a council size of one
• a COUNCIL controlled organisation is an organisation with an arbitrary council size greater than one
• as the outcome of any proposal is calculated based on quorum and majorities

3. Special Cases:

• If an organisation raises funds through a campaign, the campaign contributors are part of the eligible voters for withdrawal proposals

4. Origins

• origins need to be created to reflect the participating and approving majority VotingResult, composed of:

  • root
  • raw_origin -> member||members

• there are also member groups

  • Prime
  • Council
  • Contributors
  • Members
  • GameDAOCouncil

example:

extrinsic( origin, params )
-> origin is result of voting, e.g. [
  5 -> accepted,
  7 -> eligible,
  Option<Voting.Majority> -> how to determine, e.g. `Voting.TokenWeighted`
  ]

Acceptance Criteria

1. Extrinsics related to the organisation cannot be executed by any individual
2. origins as described above and derived from proposal type and eligible voters execute an extrinsic
3. necessary deposits are respected
4. transaction fee is paid through treasury

Additional Information

List of extrinsics to be access restricted

• updateOrg(orgId, primeId, accessModel, memberLimit, feeModel, membershipFee)
• addMember(orgId, who) (need addMember for open orgs not access restricted, probably need other extrinsic which allows users into the the org )
• removeMember(orgId, who) (need removeMember for open orgs not access restricted, probably need other extrinsic which suspends/blacklists users from the the org)
• spendFunds(orgId, currencyId, beneficiary, amount)

How to test

1. In a DAO type organisation create a proposal, accept the vote and see extrinsic getting executed.
2. In a DAO type organisation create a proposal, decline the vote and see extrinsic not getting executed
3. In a INDIVIDUAL type organisation run the extrinsic as PRIME and see getting executed
4. In a INDIVIDUAL type organisation run the extrinsic as another org member and see extrinsic not getting executed

User Story

As a user, I want to create a campaign using different currencies so I can spend those tokens later using governance mechanisms.

Acceptance Criteria

1. Create a campaign with multiple currencies.
2. Contribute to a campaign with multiple currencies.
3. only stablecoins can be used to fund into campaigns

Additional Information

• probably a list of tokens should be defined which contains lists allowed for payments. (today aUSD & PLAY)

How to test

TBD

1. a
2. b
3. c
4. d

• What is the purpose of Nonce and OrgByNonce? They seem are not really necessary.
  Why not include OrgConfiguration as attribute of Orgs ? (probably related to #53 )

• check_membership is unnecessary. No need to create an extrinsic to read from the chain state. Extrinsics are meant to modify the chain state, not for querying.

User Story

accounts want to use various gamedao protocols. to enable access, accounts need to stake GAME token and assign the amount of token to the protocol function. the functionality gets automatically enabled until the assigned stake is not assigned to the functionality anymore.

example:

• account A stakes amount S to the the staking function and assigns amount Q to a protocol P
• by assigning enough to overcome a threshold T the bitflag for the protocol is set
• by unassigning and getting below threshold T the bitflag is unset
• depending on the protocol function, a staking reward can be earned
• staking rewards are paid continuously, e.g. 10% p.a. result in a to be determined amount of return per block, directly paid back into the staking channel or any other account designated by initiatin account id

Acceptance Criteria

• hash to bitmask in storage where hash is org id and bitmask can be something like u16:
  • 0000 0000 0000 0000 - all disabled
  • 0000 0000 0000 0001 - dao enabled
• write bitmask
• read bitmask

• BoundedVec

  • Please review all your extrinsic arguments that could have an arbitrary size. For example: https://github.com/gamedaoco/gamedao-protocol/blob/main/control/src/lib.rs#L360-L361

    Replace Vec by BoundedVec for that kind of cases

User Story

As Organisation Creator I want to decide if I want to take all the decisions with impact on Treasury and Organisation Rules or if the community should be able to decide on major decisions so that the right form of governance is chosen for the organisation.

Acceptance Criteria

1. When creating an organisation the creator of the organisation becomes PRIME
2. When selecting "One Entity" in the frontend during organisation creation the org type "Individual" will be set
   2.1 only the PRIME user can do spendings and org setting updates without creating a proposal for it
3. When selecting "Community" in the frontend during organisation creation the org type "DAO" will be set.
   3.1 the prime cannot decide on spendings on his own but has to create a proposal for it as any other user, also organisation settings changes result in proposals, except for updating content (about section, logo banner)
4. it is not possible to create a "Company" or "Hybrid" by executing createOrg extrinsic
   5.1 only if a KYB is provided for "individual" this org type transforms to "Company"
   5.2 or if a KYB is provided for "DAO" this org type transforms to "Hybrid"

Additional Information

Figjam: https://www.figma.com/file/wwxuOXF1eqDLMfa9caj9Kv/Organisation?node-id=35%3A1030

ℹ️ possibly we first need a roles construct to do this ticket?

• 1 extrinsic for spending by prime & sudo only
• getting #74 done as precondition for 2.1
• multiple change org setting proposal types
• validate to not allow Company & Hybrid without having KYB (AC5)

How to test

1. Create an organisation as PRIME (PROFESSIONAL) owned and trigger an extrinsic only PRIMEs are allowed --> success
2. Create an organisation as COMMUNITY owned and trigger an extrinsic only PRIMEs are allowed (eg. updateOrganisation) --> fails
3. Create an organisation as COMMUNITY owned and trigger an extrinsic as a regular MEMBER which results in a proposal to execute updateOrganisation

User Story

As user I want to externalise configurable values consumed by pallets so I can do changes on them.

Acceptance Criteria

1. store global configs
2. configs are used in other pallets
3. configs should be votable in a later step
4. configs are detached from runtime

Additional Information

• example for a config: GameDAO treasury fee (currently 0.3% --> should be 2.5%)

How to test

1. a
2. b
3. c
4. d

Statement of Value

As a Contributor
I want to earn a reward
So that I will be able to sell or collect it

———

Acceptance Criteria

Given:
A campaign is published
and
A campaign is not completed (campaign status is "Finalizing" / "Reverting" / "Success" / "Failed")
and
A campaign contains a reward with the "Active" status

When:
A Contributor invests to a campaign
and
The invested amount is greater than a collectible's minimum funding amount
or
The invested amount equals a collectible's minimum funding amount
and
A Contributor hasn't earned the same collectible before

Then:
Assign a collectible to a Contributor (a collectible (one instance) becomes unavailable for other contributors and will be provided to a Contributor who earned it after a campaign is successfully completed)
and
Collectible's "Q-ty" parameter must be updated:
• if the "Q-ty" is Limited, then subtract earned collectible (one instance) from the current amount

———

Additional Information

High-level process

User flows
User flows that outline the detailed process can be found here.

Proposals changes:

• Remove redundant storage: ProposalsArray and ProposalCount and ProposalIndex #57
• Add #22
• Add #62 (except for the slashing tribunal implementation)
• Proposal finalization (decouple current on_finalize impl., introduce automated slashing).

Voting changes:

• Majority types (Relative, Simple, Absolute)
• Voting power.
• Quorum.
• Voting early finalization.

All related issues:

• gamedaoco/gamedao-haiku#108
• #22
• #62
• #57

For debugging reasons.
Extrinsic Error -> possible reasons.

Context

As GameDAO we want to have a pallet architecture which uses as much as possible already hardened and audited functions so that we are enabled to launch fast and not loose time on developing, testing and auditing own code.

1. become experts on existing libraries and pallets on substrate and other sources
2. identify and replace our functions from
   2.1 existing substrate pallets (staking, treasury voting etc)
   2.2 Open Runtime Module Library (ORML) pallet library (multicurrency, stablecoins, generic NFT and many other features)
   2.3 Acala, Composable Finance (finance specific features)
3. write only gamedao specific pallets if we cannot find suitable logic in other libraries / pallets
4. built repo with only external links consisting of external libs & pallets (use acala repo for this)
5. own pallets shall also be included in this repo.

Tasks

[]
[]

Additional Information

========================================

Stage 1

• open branch migration/control

• update cargo.toml dependencies

• migrate structs to new macro syntax

• migrate storage to new macro syntax

• migrate events, errors to new macro syntax

• migrate pallet to new macro syntax

• add/fix commission calculation (fixed point arithmetic)

• write tests

• benchmarking

• add PR to main

Stage 2

Refactor assets to ORML:

• Network Transaction fees use local network native currency

• Deposits use GAME

• Payments use (depending on network) aUSD/PLAY/DAI/USDT

• suggest migration in architecture round

• extend this issue with new decisions

========================================

how to test:

• pull secondary repository from https://github.com/playzero/zero-network
• update submodule for gamedao-protocol based on your commit hash
• build

your build should result in no warnings by your added functionality.

Upgrade to latest version of Substrate and Polkadot. v0.9.13 is very old

User Story

As organisation/DAO member I want to create a spending proposal to transfer some money to another wallet so the DAO can make use of the collected funds.

Acceptance Criteria

1. A new proposal type "spending proposal" is introduced
2. input parameters are:
   2.1 organisation (and/or organisation treasury?)
   2.2 currency (all supported currencies)
   2.3 amount
   2.4 target wallet address
   2.5 title
   2.6 content
   2.7 start (blocktime start at least 1h in the future)
   2.8 expiry (blocktime end at least 1d in the future)
   2.9 majority type (relative, simple, absolute)
3. Voting can be approved through simple and relative majority (but also other voting algorithms which will be added later)
4. After proposal is accepted the money in the respective currency is automatically transferred to the listed wallet address
5. A transaction hash as response will be delivered as a voting result
6. If the proposal is not accepted. The money stays in the treasury.

Additional Information

• https://www.figma.com/file/8xFCnDl6SlUOonFm1V20ne/GameDAO-Haiku-UI?node-id=1069%3A64236

How to test

1. Use polkadot.js wallet extrinsics to create a proposal, vote for / against it and see funds transferred after expiry

User Story

As blockchain developer I want to make sure that when a campaign is finalised the chain is not blocked with too many settlement processings of users.

Acceptance Criteria

1....

Process

https://www.figma.com/file/Jqy2XnQh9ZgvU518Zhp48u/Scheduling-%2B-Campaign-Settlement?node-id=0%3A1

Additional Information

How to test

1. a
2. b
3. c
4. d

User Story

As user I want to keep my GAME & PLAY tokens which I accumulated over time also on the new chain version so I can spend my tokens on the features provided.

Acceptance Criteria

1. Get all addresses which hold ZERO coin including the amount of ZERO coin
2. drop each user the same amount of GAME & PLAY token as they have in ZERO coins

Additional Information

• Since the GAME & PLAY tokens were kept as "assets" and not as "tokens" (from pallet perspective) and during the chain upgrade no migration was considered we have to drop the ZERO holders some GAME & PLAY tokens.
• Users are currently not able to spend any currencies on the network - therefore it is a good time to drop the token now.

How to test

1. test on beeblebrox first
2. after the drop check addresses for their coin and token balances. All wallets should have the same amount for all the currencies

User Story

As GameDAO user interacting on GameDAO I want to use the GAME token so that I can access protocols like creating Organisations, Campaigns and Proposals.

Acceptance Criteria

1. Following protocols should be reflected in GAME token:
   1.1 Create Organisation createOrg(...) --> lock minimum amount of GAME token in subDAO treasury
   1.2 Join organisation fees (gameDaoControl:create, gameDaoControl:addMember) --> reserve in wallet or transfer GAME token into subDAO treasury (transferrable)
   1.3 campaign deposit (gameDaoCrowdfunding:create) --> reserve GAME in subDAO treasury
   1.4 gameDaoGovernance (to be checked where proposal deposits happen) --> reserve GAME in user wallet

Additional Information

How to test

1. Creating an organisation should transfer GAME token to the created DAO treasury and lock it there
2. Joining an Organisation should transfer/reserve GAME amounts from users wallet
3. creating campaign should deduct the corresponding GAME deposits from Organisation Treasury
4. creating proposal should reserve GAME amounts from users wallet

Now Polkadot JS app provides links to the extrinsics. Instead of only providing screenshots, you could copy/paste the extrinsics links into the tutorials to make it easier and a better experience for the user.

User Story

As GameDAO user investing in a campaign I want to invest in the "network stable coin" so that my funds are not exposed to volatility.

Acceptance Criteria

1. Funding into a campaign should be possible with stable coins only
   1.1 on ACALA network use aUSD as contribution
   1.2 on ZERO network use PLAY as contribution
   1.3 keep architecture open to add more stable coins (eg. USDT, DAI etc) for each network

Additional Information

How to test

1. contributing a currency amount into a campaign should result in deducting PLAY token instead of ZERO

User Story

As gamedao protocol I want to reward an organisation membership with an achievement token so that the user feels appreciated.

Acceptance Criteria

1. When becoming a member of an organisation a NFT will be available to the user
   1.1 immutable part: unique, non-transferable, burnable
   1.2 content part: IPFS hash within NFT (CID)
   1.3 user has to claim the NFT
2. When the user leaves the organisation the NFT will be burned

Additional Information

How to test

1. create or join an organisation to become a member
2. find the Claim link
3. receive the token after signing the transaction

Statement of Value

As a Creator
I want to create a reward
So that I will be able to add a collectible to a reward and a Contributor will be able to earn it

———

Acceptance Criteria

1. A Creator must be able to create a reward with the following parameters:
   1.1. Name. A user will indicate a value of this parameter on UI.
   1.2. Reward type (this parameter must be predefined with the same value in BE):
   • Collectible ("Collectible" is the only available type for now, but the list of types will be expanded in future)

2. Reward is an entity that will be created during the campaign creation (a campaign can be published with a reward, or without a reward, or with multiple rewards).

3. Reward statuses:

• 3.1. Draft
  the reward is created and added to a "Draft" campaign

• 3.2. Active
  the reward is created and added to a campaign, which status is not "Draft"

• 3.3. Completed
  the reward is created and added to a campaign and a campaign has been completed (campaign status is "Finalizing" / "Reverting" / "Success" / "Failed")
  or
  all collectibles added to a reward have been earned

———

Additional Information

High-level process

User flows
User flows that outline the detailed process can be found here.

The pallets storage schema and usage is not correct. Some tips and guidance:

• You are duplicating values without any need when they should be if possible gathered in a single struct.

  • E.g. flow.campaings and flow.campaignOwner. The campaign owner is already in the GamedaoFlowCampaign struct. In addition, I don’t see the need of adding the campaign id in the struct as it is defined as the StorageMap key. It seems that you are unnecessarily duplicating data that is already stored in the main struct object in other StorageMap with the same key. It applies to all your pallets (control, flow, etc..)
  • Saving big structs instead of creating many new storage keys to save data of the same item. It is in general better to keep a big struct because you reduce the number of read & writes and reduce the size and complexity of the trie.
  • Be also aware that although wrapping related items in a shared structs is an excellent way to reduce the number of storage reads, at some point the size of the object will begin to incur costs that may outweigh the optimisation in storage reads.

• As a consequence of the previous issue, there are too many unnecessary storage read/writes, which affects to the extrinsic weight.

  • E.g. https://github.com/gamedaoco/gamedao-protocol/blob/main/control/src/weights.rs#L74-L75
  • It applies to all pallets where data is unnecessary duplicated
    • https://github.com/gamedaoco/gamedao-protocol/blob/main/flow/src/lib.rs#L750-L784
    • https://github.com/gamedaoco/gamedao-protocol/blob/main/signal/src/lib.rs#L826-L850
    • Some of the fields could be also added directly to the main struct Item (Org, Campaign, etc)

• Consider using StorageDoubleMap instead of a simple StorageMap + Vec. There is not right answer here, it will really depend on each particular case. E.g: OrgMembers could be a StorageDoubleMap where the secondary key is the member AccountId.

  • If the numbers of members can be very large, making use of Vec with contains and binary_search migh be less optimal for read/write than using contains_key for the StorageDoubleMap.
  • Vec might be only make sense if you need to list the vector items in runtime. In that case, StorageDoubleMap would mean a lot of DB reads.
  • For the OrgMembers example, since there is not a value to save in the double map, it might cause some storage penalty as you'll need to save at least a bool value. Maybe in the future your members have more attributes, so it make sense to create a Member struct.
  • Create benchmarks to empirically measure what is the optimal design for each case.

• More information about storage best practices: https://docs.substrate.io/main-docs/build/runtime-storage/#best-practices

If the reason of your storage design is to make it easier to retrieve data, there are better alternatives such as:

• Building custom RPC calls to return filtered, gathered or specific info from storage.
• Indexing services: it can collect information listening to the extrinsics & events and build a enriched relational DB with your storage data

User Story

As organisation PRIME I want to be able to change the organisation settings so I can adapt the organisation rules to new situations.

Acceptance Criteria

1. a new extrinsic to change an organisation (updateOrganisation) is in place
2. access restrictions are applied to this extrinsic.
   2.1 if organisation control type is "PRIME" the prime role (controllerID of org) can trigger the updateOrganisation extrinsic
   2.2 also sudo can trigger the extrinsic
   2.3 other than that nobody can perform this extrinsic
3. changes can happen on:
   3.1 controllerID
   3.2 fee model
   3.3 fee (mandatory if fee model = reserve or transfer)
   3.4 access type
   3.5 member limit
   3.6 organisation control type
   3.7 every field is optional but if all fields are empty the update is not triggered.

Additional Information

• 3.8 All types of proposal type settings (min deposits, durations, majority types, voting power mode) --> seperate ticket

How to test

1. perform extrinsics call to change each of the values of an organisation
2. try to perform extrinsic with a user not allowed to
3. c
4. d

User Story

As protocol I want to protect market participants from protocol abuse, e.g. bad actors proposing destructive activity for GameDAO or any other DAO running on the protocol.

To achieve this we require creators of a Proposal to deposit a sound amount of collateral to their proposal. This disincentivizes bad actors from abuse and creates more transparency for the voters.

Acceptance Criteria

1. add deposit to extrinsic
2. lock deposited amount over lifetime of Proposal
3. on Proposal settlement decide based on Proposal type, required quorum and outcome if

• accepted --> deposit will be fully returned
• rejected --> decide if to be slashed or not:
  • majority of rejection >= 2/3 of eligible voters --> slash deposit
  • else --> return deposit

4. slashed amounts go to a configurable treasury, either

• e.g. GameDAO Treasury for global proposals
• respective DAO where proposal was created gets 75%, GameDAO Treasury 25%

5. the initial slashing rules are (add enum) :

• automated: rejection criteria met --> slash
• tribunal: rejection criteria met --> create slashing vote (not scope of this ticket)

6. if the user does not have enough GAME token to deposit, an error message is displayed ("insufficient funds")

Additional Information

• think about configurable slashing requirements, e.g. based on member count, TVL, etc.

• think about configurable quorum per proposal (@vovacha)

• please slice on estimate

• do we need to extend the states free, locked, reserved by another state, which is collateral, which cannot be spent under any circumstances without approval of the respective protocol (@vovacha)?

• minDeposit = 100 GAME

How to test

1. Create a proposal without deposit --> get error (e.g. "not enough mana").
2. Create a proposal for a future Blocktime --> see deposit reserved as collateral in wallet.
3. Create a proposal, check reserved amount and wait for expiry--> see amount unlocked and transferable again.

Pallet level storage versioning: save version in the storage instead of hardcoding it. Make use of GetStorageVersion trait.

Example:
let on_chain_storage_version = <P as GetStorageVersion>::on_chain_storage_version();

Bad: https://github.com/paritytech/substrate/blob/master/frame/collective/src/lib.rs#L173
Good: https://github.com/paritytech/substrate/blob/master/frame/uniques/src/migration.rs#L25

Statement of Value

As a Creator
I want to add a collectible to a reward
So that a Contributor will be able to earn it by investing in my campaign

———

Acceptance Criteria

1. A Creator must be able to create a collectible within a reward with the following attributes:
   1.1. sn
   1.2. id
   1.3. collection (A collectible must be minted from a collection which must be created automatically for each DAO in BE)
   1.4. symbol
   1.5. Name (A user will indicate a value of this parameter on UI)
   1.6. Description (A user will indicate a value of this parameter on UI)
   1.7. Metadata. Collectible file. (A user will upload this file on UI).
   • File types supported: AAC, AVI, BMP, FLAC, GIF, GLB, HEIC, ICO, JPG, JSON, M4V, MOV, MP3, MP4, MPEG, OGG, PDF, PNG, SVG, TIFF, WAV, WEBM, WEBP.
   • Max file size: 30 MB
   1.8. Royalty percent float (A user will indicate a value of this parameter on UI)
   1.9. Royalty receiver (This must be a user who creates a reward)
   1.10. Quantity:
   • Unlimited(A user won't indicate q-ty on UI) (unlimited number of Contributors will be able to earn a collectible)
   • Limited (A user will indicate a number which is greater than 0 on UI) (limited number of Contributors will be able to earn a collectible)
   1.11. Minimum funding amount (if the amount of contribution is less than a min. funding amount, then this contribution is not eligible for a reward)
   1.12. Thumbnail. (A user will upload this file on UI).
   • File types supported: JPG, PNG, SVG.
   • Max file size: 30 MB
   1.13. Custom attribute. 100 custom attributes max can be created for one collectible. (A user will indicate a name and a value of this parameter on UI).

2. Collection must be created for each DAO with the following attributes:
   2.1. id
   2.2. Name (The name of the DAO must be used here)
   2.3. Description (The description of the DAO must be used here)
   2.4. Collection max (How many NFTs will ever belong to this collection). 0 must be set by default.
   2.5. Issuer (Issuer's address (can be different than minter)
   2.6. Symbol (Ticker symbol by which to represent the token in wallets and UIs (e.g. "ZOMB"))
   2.7. Metadata (The image of the DAO must be used here)
   • File types supported: JPG, PNG.
   • Max file size: 30 MB

3. Multiple collectibles can be minted from one collection.

4. Multiple collectibles can be added to one reward.

———

Additional Information

High-level process

Specification
Domain model, data dictionary can be found here.

User flows
User flows that outline the detailed process can be found here.

========================================

Stage 1

• open branch migration/signal

• update cargo.toml dependencies

• migrate structs to new macro syntax

• migrate storage to new macro syntax

• migrate events, errors to new macro syntax

• migrate pallet to new macro syntax

• add/fix commission calculation (fixed point arithmetic)

• write tests

• benchmarking

• add PR to main

Stage 2

Refactor assets to ORML:

• Network Transaction fees use local network native currency

• Deposits use GAME

• Payments use (depending on network) aUSD/PLAY/DAI/USDT

• suggest migration in architecture round

• extend this issue with new decisions

========================================

how to test:

• pull secondary repository from https://github.com/playzero/zero-network
• update submodule for gamedao-protocol based on your commit hash
• build

your build should result in no warnings by your added functionality.