# Proposal for the ai16z token design 

_By Vasily Sumanov and the team, Valueverse.ai_

# Introduction: the current state of the ai16z ecosystem

The ai16z ecosystem consists of several products:

- ElizaOS - the open-source framework for developing, deploying, and operating AI agents
- AI agent marketplace
- Launchpad for funding new AI agents built on top of the ElizaOS

Today, this ecosystem isn’t economically sustainable, lacks an approach for open-source software monetization, and has several other problems.

This proposal outlines ideas for **(1)** the new economic design for the ai16z ecosystem **(2)** the update for ai16z token utility, functions, and value-capturing structure. It will provide the foundations to scale the ecosystem robustly and sustainably, focusing on achieving and maintaining the #1 place in the pace of the emerging market of AI agent ecosystems.

Today, agents are freely deployed with no built-in mechanisms for maintaining trust, and the Launchpad mechanism [recommends](https://hackmd.io/KYKr2Cv8SAu1BFzoc5Ypfg) that 10% of agent tokens be donated to the DAO as a tribute without any guarantee that an agent deployer will make this tribute.

We identified the following problems in the ai16z existing economic design that need to be solved for sustainable future development and ecosystem expansion:

- The agents’ trust problem
- the problem of ElizaOS monetization and long-term developers’ motivation
- the problem of creation and facilitation of the economic flywheel effect in the ecosystem

## The agents’ trust problem

Community members easily create AI agents, and their honest operation is not controlled. 

Theoretically, any agent (or the team behind it) can take any kind of action, including any kind of malicious one (for example, stealing users’ funds or providing incorrect data, affecting the decision-making of the end user). The low cost of agent creation and absence of penalty for maliciousness means the low cost of attack, which introduces a vulnerability for the ai16z ecosystem and its users. 

Thus, promoting agent non-maliciousness is one of the cornerstone problems that must be solved to build an ecosystem for launching and operating autonomous AI agents.

## The problem of ElizaOS monetization and long-term developers' motivation

The ElizaOS framework is open-source and free for public use. Agent deployment is not tied to any registry, whitelist, or authority, and the allocation of compensation to framework developers remains an open question.

Simply put, there is no mechanism for guaranteed payment when using the framework. At the same time, it is clear that the software itself should be free and open source, with a sustainable revenue stream for future development, maintenance, and technical support.

To monetize ElizaOS, a voluntary 10% tribute was previously introduced. However, this approach lacks the desirable income stability. Some projects can simply withhold the tribute at will with no necessary repercussions; any manual admonitions that could compel a change of policy by the agent deployers are necessarily made impossible at a large enough scale. 

This jeopardizes the sustainability of the ecosystem operation and new economic mechanisms should be introduced for the monetization purpose taking into consideration the open-source vision.

## The problem of economic flywheel effect creation

The primary creators of value for the end-users in the ai16z ecosystem are AI agents, built on top of ElizaOS as well as all developers involved in core framework developments and agents creation. 

According to that, the core ecosystem health metric to be maximised is the number of successfully-operating agents providing valuable services to users. Note, that it is critically conditioned on:

1. Solving the trust problem, mentioned above
2. Sustainable funding of ElizaOS future development and maintenance
_It is important to highlight that we don’t see an opportunity to grow the agents’ ecosystem without solving these problems._

In order to achieve organic growth of ecosystem metrics, it is necessary to create an economic flywheel mechanism. Such a mechanism should support the operation and growth of agents on top of the solved trust problem and ElizaOS monetization problem.

This flywheel mechanism should operate on top of the positive feedback loop of value, created, distributed, and reinvested in the ecosystem, supporting the future growth and adoption.

# The ai16z new token design as a proposed solution for the outlined problems

In this section we will describe solutions for identified ai16z ecosystem problems featuring our proposal for the ai16z new token design.

## The solution for the trust problem

This problem may be solved in three ways:

1. Reliance on due diligence by the general community. 
2. Creation of a central control entity
3. Introduction of cryptoeconomic security mechanisms

The first option is based on an unfoundedly optimistic assumption, and the second is not scalable and introduces a single point of failure, violating the core decentralization ideas. As a result, we propose to consider a crypto-economic security mechanism aimed at protecting agent users from any kind of such actions.\
\
The simplest way to solve the trust problem in a decentralized way is to increase the cost of attack, which can be observed as an expected loss for a fraudulent actor. One of the historically proven approaches is a cryptoeconomic security mechanism based on the token stake that acts as a skin-in-the-game, creating a barrier for creating new agents while reflecting the possible value loss of the attacker.

_Thus, we propose to create a trusted AI Agents whitelist protected by cryptoeconomic security mechanisms based on the ai16z token stakes or Agent Bonds._

According to this vision, in the future all agents launched in the ai16z ecosystem will be divided into two categories:

- Whitelisted (trusted) agents, secured by the ai16z token stakes
- Other agents that can freely be deployed and operate under the ‘sandbox’ or ‘testnet’ category. 

Sandbox placement means that a production agent can be permissionlessly launched and operated, however it doesn't meet any ecosystem-wide trust requirements. Thus, we expect such agents to be used primarily for testing and recreation.

As a result, such trusted whitelisting wouldn't prevent developers from building and innovating with ElizaOS. It would preserve innovation in the ecosystem while maintaining the necessary level of trust.

In addition, registered agents should be prohibited from using unregistered ones as endpoints, in order to give the posting of a bond additional network effect value.

So, the proposed solution is to create a permissionless agent registry (trusted whitelist). The agents are added to the registry by a sufficient ai16z stake, self-owned or delegated by any token holder.

Some additional thoughts and ideas for the solution of the agents’ trust problem:

1. Agents creators may not have enough ai16z to cover the trusted bond requirement, and a general tokenholder does not necessarily want to deploy an agent himself, there is a demand for facilitating vouching for others. A well-known way to satisfy this demand is to introduce stake delegation, whereby the bond posted by one entity is attributed to another. This creates a trust delegation (stake delegation) market where agent creators can ask the DAO or individual token holders for assistance in fulfilling the stake requirement in exchange for tokens, acting as a payment for the slashing risk taken
2. This delegation need not coincide with the delegation of voting rights, which can be done through a separate accounting arrangement. In fact, the author believes that it would be best to keep the two delegations separate so that the investment does not imply a cessation of voting rights to the investee. 
3. In addition, ai16z locking may be promoted by introducing an unconditional cashflow to all holders of the locked form of the token. 

## The ElizaOS monetization problem and long-term core developers' motivation

In our vision, the solution for the ElizaOS monetization problem can be derived in the general open-source monetization approach: the non-commercial usage is unconditional and free, while the commercial one requires some payment to developers.

In the case of ai16z, we can consider the addition of a particular agent to the trusted whitelist as the transition from the early development, testing, and fun phase to the commercial deployment phase for that agent.

Therefore, we propose that provision of a portion of the agent's token supply for the benefit of the DAO's treasury, token stakers, and core developers be mandatory as a requirement to be added to the whitelist of trusted agents. If the agent was launched prior to the implementation of the new token design and provided the aforementioned tribute to the DAO, such an agent doesn't need to provide additional tokens.

The particular percentage and distribution logic for agents’ tokens charged as a whitelisting fee should be a governable parameter and widely discussed within the ai16z community prior to implementation.

## The problem of economic flywheel effect creation

We propose to establish the economic flywheel in the ai16z ecosystem on top of economic mechanisms initially proposed for solving the trust problem and ElizaOS monetization.

Earlier, we discussed that a properly functioning flywheel mechanism should organically facilitate maximizing the number of trusted agents that provide useful services to end users.

The process of maximization of this metric by ecosystem participants (such as token stakers, agents developers, investors into agents, and agents’ end-users) is built on top of two main ideas:\
1\. Establishing of  trusted whitelisting
2\. Charging fees for commercial usage and distributing them to core ElizaOS developers, DAO treasury, and token stakers

We propose to add an additional economic process on top of these two: token buyback, burn, and mint.

The mint-and-burn mechanism should be deflationary in nature, meaning that if X tokens are burned, Y is minted, and Y\<X. For example, 1000 ai16z tokens were burned and only 500 were minted. The newly minted tokens should be distributed to token stakers, thus incentivising the token holders to stake tokens and participate in all related actions, such as governance.

The flywheel is created by encouraging token ownership through its appreciation over time, encouraging token locking through a cashflow allotted to holders of locked positions, and facilitating an investment market for potential (trusted) agents. It follows that the token is strongly incentivized to be used in a utility role that requires staking.

# The additional details of the proposed token design

## Diagrammatic representation

We supplement our proposal with several diagrams, outlining the logic of token operation in the ecosystem and covering three main blocks of functions:

1. The Agent Bonds (token stakes) creation
2. The governance and the yield-generation for the staked tokens
3. The burn-and-mint functionality

The token lock (Agents Bond) creation, delegation (for Agents Bond), slashing, and withdrawal:


Vote delegation, yield on locked ai16z, and voting (the yield distribution is only shown to indicate that token delegation does not cede the associated cashflow):


Mint/burn functionality:


## Commentary on the diagrammatic representation

It can be seen that all utility functions of the token are conditioned on its locking for a period of time. It includes the already existing DAO participation and partnership status (it isn’t presented on the diagrams). 

Since the voting power and bond are delegated separately via separate accounting procedures, it becomes possible to fully treat bond delegation as an act of vouching for the delegatee; this affords the option to create trust scoring that take into account the trust level of the delegator (cf. [proposal 1](https://hackmd.io/@XR/ai16z-tokenomics/%2F88HuGFKbRJePFkuTTfpZiA)). 

Note also the sequence of agent shutdowns in the first diagram: it implies that only the DAO can manipulate (specifically, alienate) tokens posted as bonds for a given agent; token holders must shut down the agent to obtain this ability. The author believes this is necessary to prevent developers, should they prove malicious, from defeating the purpose of the bonding system by prematurely withdrawing the bond so that it can no longer be alienated.

# The summary for ai16z functions

1. The token is endowed with lockup functionality with a delayed unlocking mechanism. 

- The extant functionality of partnership status granting and governance participation are conditioned on the amount of tokens and duration of lock

2. An agent registry (the agents' whitelist) is created; though permissionless, it necessitates the agent to possess a bond of locked tokens to its name in order to be included in it

- An agent entering the registry must mandatory provide 10% of token supply as a DAO fee
- An agent may not leave the registry voluntarily until its associated locked position is unbonded
- The DAO may alienate the associated bond of the agent should it be shown to be fraudulent 
- No interaction between registered (whitelisted) and unregistered (not whitelisted) agents is permitted in the interest of preserving integrity of the registered agents

3. The locked tokens can be delegated

- This delegation mechanism is separated between voting and agent bonding (whitelisting), with the latter being usable as a statement of vouching for an entity (not necessarily an agent), and the former being possibly weighted by the elapsed lockup time
- This, in general, creates a bond delegation market functioning much like the trust market.

4. The token is made deflationary by introducing a mint/burn program, whereby a given quantity of tokens is removed from the circulation and a smaller quantity is reintroduced by disbursement to locked position holders
5. The aforementioned disbursement, supplemented by a portion of the DAO treasury revenue, is distributed to holders of locked positions, possibly with scaling dependent on the elapsed lockup time

# Breakdown of value introduced by the proposed functionality

## Value for token holders

1. The previously conferred benefits of a partnership status and DAO participation are retained
2. Holding the token begets a deflationary appreciation of the position
3. Locking the token additionally begets a revenue stream derived from the ai16z monetization fees, charged from whitelisted agents, and additionally from the deflationary burn-and-mint process
4. Admission of bond delegation allows to create a market for delegated trust; this unlocks the opportunity to make deals with developers of novel agents, possibly getting tokens in return
5. Long-time lockups may be additionally promoted by increasing the voting power per unit of token locked

## Value for the agent developers

1. The need to provide the token stake for agent whitelisting allows the creation of a prior trust assumption due to the raised lower bound of loss if the agent proves to be malicious, which helps in attracting users.
2. The existing option to use ElizaOS for building, testing, and innovating with new agents remains. We remind that whitelisting is required only for agents that aim to attract investors from launchpad or deliver a product aimed at wide adoption.
3. It also simplifies the due diligence required to select collaboration partners from among other agents, creating the network to exchange value and information when needed.
4. The creation and development of the launchpad system due to the introduction of the bonding system is beneficial by simplifying the search for investors and early users.

## Value for the DAO and ElizaOS future

1. A consistent revenue stream is established from the fees, charged from whitelisted agents. Using a share of these fees to pay ElizaOS developers enables opportunity for open-source software monetization without violating its general free and accessible status.
2. The the problem of verifying honesty new agents is simplified, which allows to scale ElizaOS adoption

## Value for the ecosystem in general

1. The introduction of voting and delegation provides an opportunity to build data sources that can be used to create additional (semi-)automatic trust scoring systems (e.g. delegation can be treated as endorsement). 
2. High token volatility is discouraged by the deflationary nature and gating of utility behind activation through lockup; at the same time, token acquisition in general is encouraged by the same utility.
3. The introduction of an economically based trust prior promotes the democratization of agent deployment (see the argument in the section on solving the trust problem). In addition, it allows for the creation of a launchpad-based investment market that allows developers to raise the necessary investment, both in the form of bonds and traditional cash flow, locally (i.e., within the ecosystem).

# The value capturing structure of the proposed ai16z token design

_Annotation to the value-capturing description_\
This section is based on the original research - the value-capturing classification framework for digital assets created by the authors of this proposal. It focuses on identifying elementary economic patterns that allow tokens to capture value from the ecosystem (Origins of Value), forming complex economic mechanisms (Value-Capturing Mechanisms).This work was recognized by the annual Token Engineering [award](https://x.com/tokengineering/status/1810944102474690743) in 2024, provided by the [TE Community](https://x.com/tokengineering).\
\
Learn more about it here to have more context: the original article pre-print[\[1\]](http://bit.ly/vcm-paper), and brief introduction to it[\[2\]](https://app.valueverse.ai/blog/posts/intro-to-the-vcm-framework-and-our-reports-methodology).

## Origins of Value

The following OoVs can be recognised. Also, they are listed on the value-capturing diagramm below:

1. Future Cashflow (2₁), representing the appreciation of held tokens due to deflation
2. Risk Exposure (7), representing creation of the token stake when locking it
3. Access (4), representing the granting of a partnership status
4. Future Cashflow (2₂), representing the disbursement of reminted ai16z tokens and a portion of the tribute-generated yield
5. Conditional Action (8₁), representing voting power delegation
6. Conditional Action (8₂), representing the act of governance participation
7. Governance (3), representing the tangible (bribes if there will be any) and intangible benefits accrued as a result of exercising influence on the DAO decisions
8. Conditional Action (8₃), representing the delegation of stake
9. Future Cashflow (2₃), representing the cashflow in tokens granted by the delegatee in the form and volume determined an agreement of delegating token stake (or its part) to Agent Bond of particular agent, seeking whitelisting

## Value Capturing Mechanisms

Two VCMs can be distinguished. Refer to the figure below.


Observe that the numbering of OoVs on the diagram above exactly matches that in the enumerated list provided in the OoV section. 

Here you can clearly see the two different VCMs. The first consists of only one OoV (2₁) and represents an unconditional cashflow (this cashflow should be considered an effective cashflow rather than an actual number of tokens being transferred, as it is realized in the form of continuous token appreciation). The second contains the bulk of the token's functionality, all of which is jointly conditioned on the token lock-up. 


# Miscellaneous notes

- Partnership status may be made tiered, depending on the amount locked (similar to possible differentiation of agents dependent on their associated bond size)

# Acknowledgments

Authors of this proposal express gratitude to community members of ai16z - [yardy](https://x.com/myswerve) and [yikes](https://x.com/yikesawjeez) This proposal for the new ai16z token design could never happen without detailed information about the current state of the ecosystem, ElizaOS development, and participation in brainstorming from their side.