Incentive structure

We follow a transparent incentive structure which rewards leadership.

Background:

Before coming to the current incentive model, we studied and experimented with multiple ways to incentivise coordination in an open organisation. Our most popular work is Jediswap, one of the largest dapps on Starknet(80% market share on Starknet pre-airdrop). With Jediswap, we built the whole organisation without any VC money or a piece of legal paper. More than 50+ core contributors and 100s of passive contributors made Jediswap possible. We implemented what we learned from there and other DAOs' work to come to the current incentive model of gmtribe.

Challenges of open organisations

With our experience building Jediswap, studying different DAOs and experimenting with different incentive models, we figured out key problem statements that we needed to solve to ensure we built a sustainable organisation.

An organisation must operate at high speed and be able to iterate the product quickly based on market hypothesis and go-to-market approach. However, as open organisations scale, they become less efficient.

• Responsibility: It becomes hard to know who is responsible for what.

• Endless debates: Because of loose details around the decision hierarchy, people get stuck in debates, and execution suffers.

• Loose KPIs: Without clear incentives based on KPIs, it becomes harder to align people with organisation goals. People start moving in all kinds of directions and suffer in execution.

• Talent void:

  • Removing non-performing people becomes harder because of political issues in the absence of KPIs, which makes it harder to attract talent who can perform.

  • People sometimes suddenly leave, and it cripples the organisation because the organisation doesn't incentivise people to take on more responsibilities voluntarily.

Solution

We figured out that our incentive model needs to take care of these two blocks to avoid getting trapped into the usual DAO/community operating model.

• Roles and responsibilities: We need to clearly define various roles in the organisation and what are the expectations from those roles.

• Reliability: We need to know that a person taking some role and responsibility will keep fulfilling their duties till the foreseeable future.

Ownership distribution based on Roles

To build a systematic incentive structure, we took inspiration from the corporate models that most successful internet companies (Facebook, Google, etc) follow.

We define different role levels and what are the expectations of those roles across various categories (Developers, Sales, Product).

Using self-review and peer review processes every quarter, we finalise what role each person fulfilled.

Base weightage

We have defined a base weightage for each role, aligning with the market salaries for those roles at these companies.

role_base_weightage = {
    "CEO": 1,
    "CTO": 1,
    "L11": 9/10, #SVP
    "L10": 8/10, #VP
    "L9": 7/10, #Senior Director
    "L8": 5/10, #Director
    "L7": 3/10, #Senior Manager
    "L6": 1/10, #Manager 2
    "L5": 1/15, #Manager 1
    "L4": 1/20, #SE 3, 2+ years exp
    # "L3": 1/30, #SE 2, 0-1 years exp
    # "L2": 1/50 #Univ grad, intern
}

Founding Factor

We defined a founding factor curve for each role to incentivise early contributors. The founding factor is designed to benefit people at the mid-level role since, at the start, the org does not need managers but execution-level people.

KExp = -np.log(0.02) / 48  # Assuming 98% decay to the base level at 48 months

# Exponential decay function
def founding_factor_exponential(t, k = KExp, base_level = 1, max_level = 1):
    return base_level + (max_level - base_level) * np.exp(-k * t)
    
role_max_founding_factor = {
    "CEO": 1,
    "CTO": 1,
    "L11": 1,
    "L10": 1,
    "L9": 1,
    "L8": 1,
    "L7": 1.5,
    "L6": 3,
    "L5": 3,
    "L4": 2,
    # "L3": 2,
    # "L2": 1.5
}

Monthly ownership allocation

Every month 2% of token supply is distributed among all team members. This 2% is divided among all individuals based on their total weightage (base weightage * founding factor).

An individal's allocation = (base weightage * founding factor)*Monthly allocation/Sum(everyone's base weightage* founding factor)

Vesting schedule to incentivise commitment

Each monthly allocation of an individual gets into their vesting schedule.

Their monthly allocation gets vested for the next 12 months. All unvested tokens go back to the treasury.

For example, if you got a 12,000 tokens allocation in Jan.

If you continue to operate in your role for February, March, and April, you can claim 1000 tokens in February, March, and April. Since you stopped operating in your role in April, your unvested tokens(9000) go back to the organisation's treasury so that the organisation can use those tokens to incentivise people to fill the gap you created.

Note: In the above example, you still get separate allocations in Feb, March and April with their own vesting schedule, just like for the Jan's allocation.

We have created a simulation environment to see how ownership evolves with different additions/subtractions of people in the organisation.

Check it out here: https://colab.research.google.com/drive/1HqMGvOzPDcA0F8AY9F39gBXSwXPJ-VIm#scrollTo=qJNSI3RPI3zY