This blog post serves as a summary of Tribal Protocol’s first milestone delivery for our Web3 Foundation Grant, found here and our repo here.

• accept_tribe: Attempts to mark the verified founder with a vote action of FOUNDER_ACCEPTED.

• fund_tribe: Can record multiple funding actions for the verified founder. Only available to founders who have already accept_tribe.

• get_founder_status: Returns current state of the founder as json.

• get_tribe: Returns current state of tribe as json.

• invite_founder: Attempts to include the provided AccountId in the tribe contract’s founders collection. The initial founder must also provide the amount promised to tribe (in picos as u128) and a flag to determine if this is a ‘required’ founder.

• reject_tribe: Attempts to mark the verified founder with a vote action of FOUNDER_REJECTED.

To create a tribe, the initial founder submits a create_tribe request, proxied via the Orchestrator. The Orchestrator first creates a new instance of the Tribe_Contract via rpc, and — upon isFinalized, or isInBlock — returns the specified tribe’s public_key to the founder.

Once the above operation is complete, the newly created tribe is left in a disabled state, until all the required founders approve the creation of the tribe.

To activate an instantiated tribe, all the required founders must accept the terms, and conditions of said tribe, as defined in the initial create_tribe event.

In the above diagram, after all the required founders accept the creation of the tribe, the tribe is set to an active state. Once the tribe is active, it can participate in content leasing events.

Alternatively, as depicted in the diagram above, if any required founder rejects the create_tribe event, the tribe will not be activated, and is marked as defunct. There is no moving forward from this state. In order to continue, a new tribe must be created from scratch, and the process starts anew.

We’ve developed an Orchestrator test utility that allows a user to test orchestrator functionality. At this time, the test utility allows users to connect to a local dev substrate chain, and create tribes.

To use this utility:

• clone this repo: https://github.com/tribal-protocol/substrate-poc-client

• npm i

• npm run dev

• start your local dev cluster.

• Click “Connect to Local Devnet”, and select a Dev user to work against

• Click “Create Tribe as …” and fill out the form that appears, and click “Submit” DO NOT CLICK THIS TWICE

  • A status message should show at the top of the page

• once complete, a tribe will appear in the list of tribes found in localStorage.

Run cargo +nightly test to execute unit tests.

1. After our initial R&D we realized that we could just leverage the ink! contract storage itself. For the purposes of this milestone there was no need to leverage a custom Tribal Pallet for storage at this stage.

2. Things aboutpolkadot/js

   1. polkadot/js has next to no documentation surrounding contract-related event emission from signAndSend — specifically around contractTrapped errors, and their corresponding bits of data.

   2. ApiPromise returns the Promise result before the resultCb fires the isFinalized event!! This means I have to wrap your promises in my own promises.

Jason@tribalprotocol.io 📥 / twitter.com/JsonDevlin