# Tribal Protocol Web3F Milestone 1

By [Jason](https://paragraph.com/@jason-33) · 2022-08-05

---

**Deliverable Details**
=======================

This blog post serves as a summary of Tribal Protocol’s first milestone delivery for our Web3 Foundation Grant, found [**here**](https://github.com/w3f/Grants-Program/pull/979/commits/42febe080eb1fd3b161509756bcf5d39526360fa?short_path=9359c0d#diff-9359c0d30847afdcbfb89ada33b7b46140cb2ad49d610831dee56c3d44b05989) and our repo [**here**](https://github.com/tribal-protocol/tribal_contract/commits/main/founder.rs).

Tribe Contract — public ink! Messages
-------------------------------------

*   `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.
    

Create Tribe — Create new tribe workflow
----------------------------------------

![Create Tribe end-to-end](https://storage.googleapis.com/papyrus_images/a8bc68c08072546c6cdfaf6adf926b5370980758380a81c77fa4e8776a43c181.jpg)

Create Tribe end-to-end

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.

Create Tribe — Founder(s) approval workflow
-------------------------------------------

![](https://storage.googleapis.com/papyrus_images/4fa2d3483d5ca5ed21317e52c358a7a93237aaf03d6fc681c09c25d38576419d.png)

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.

How to use the Orchestrator:
----------------------------

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](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.
    

![](https://storage.googleapis.com/papyrus_images/bf2aed1d5bb140e96ff8b60b988ce07cb5aaa22fdd6f13f83c4ba2a815b7e2df.png)

How to run the ink! tribe contract tests:
-----------------------------------------

Run `cargo +nightly test` to execute unit tests.

![](https://storage.googleapis.com/papyrus_images/ccb6b54523cb4e57eafaa9ae657cd4cb640a416527aea4044bb44c544e6ec6d2.png)

Takeaways of note from Milestone 1:
-----------------------------------

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 about`polkadot/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.
        

To Get in Touch:
----------------

[Jason@tribalprotocol.io](mailto:Jason@tribalprotocol.io) 📥 / [twitter.com/JsonDevlin](http://twitter.com/JsonDevlin)

---

*Originally published on [Jason](https://paragraph.com/@jason-33/tribal-protocol-web3f-milestone-1)*