Autonolas Tokenomics Core Technical Document

Autonolas Tokenomics v1
- Towards a Self-Sustainable Autonomous Services

Ecosystem via Software Composability Incentives -
Mariapia Moscatiello, David Minarsch, David Galindo
Valory AG, Zug, Switzerland

[email protected]
https://valory.xyz
Abstract. This yellow paper offers a comprehensive overview of the

token-economics model of the Autonolas protocol. The protocol aims
to incentivize software composability to foster the growth of a self-
sustainable ecosystem of autonomous applications.
Key words: token-economics, software composability, autonomous ap-

plications, protocol-owned liquidity, protocol-owned services, open-source
code.
2 Valory AG
1 Context
Today’s world is increasingly reliant on software. Indeed, humans have strived for
centuries to automate repetitive processes for their economic benefit or saving
time, software being its epitome. Despite that, more often than not, humans
are paradoxically placed at the service of machines. It is our conviction that the
focus is shifting from automation towards higher levels of machine autonomy at
the service of human autonomy.
We believe the latter can be accelerated by creating autonomous applications
or services that, by design, require little to no input from humans, run continu-
ously, and take their own actions to benefit humans. Autonomous services are,
additionally, capable of complex processing and have composability properties
to facilitate growing their number with less and less effort. They can be operated
by one or different entities transparently, and can achieve varying levels of decen-
tralization. When operated by groups with open participation, the reliable and
collaborative aspects of autonomous services offer great potential for the benefit
of society. A very relevant opportunity is that of co-owned and co-operated AI
as autonomous services (see in [24, 25] for more details).
Autonomous services can be implemented as agent services [8]. As such, they
take the form of a multi-agent-system [4] that can be anchored to a settlement
layer [11] but are primarily run off-chain, e.g. outside the settlement layer envi-
ronment (such as a public blockchain). The execution of an agent service logic can
be coordinated between participating agents, and the service intermediate states
are replicated on a short-lived blockchain (also called consensus gadget [8, 5]),
specific to each service. The most important intermediate values obtained in a
given service can be secured on a public (or private) blockchain. The owner of the
service, e.g. the entity that provides service specifications, deploys it and man-
ages it, among other decisions and management activities, chooses in advance
which values will be regularly committed to the blockchain.
For more information on the technical architecture of autonomous services
see Chapter 2 in [23].
The foundation of a self-sustainable ecosystem of autonomous services is at
the heart of the Autonolas protocol, and consists of the following elements:
– An open-source software stack to realize autonomous services form compos-
able parts
– Software components1 that provide specific functionalities and can be com-
posed into software agents 2 . Agents can be themselves composed into dis-
tributed software services, e.g. autonomous services
– A protocol, that is blockchain-agnostic and could eventually be deployed on
all major smart-contract blockchains, that provides the tools for the coordi-
nation, security, and management of autonomous services
1
Software components are throughout the paper referred to as components or agent
components.
2
Agents are also called canonical agents.
Autonolas Tokenomics 3
– A tokenomics aiming to incentivise software composability to grow a sus-

tainable autonomous services ecosystem
2 Introduction
The token-economics model that we present in this section lies at the heart of
the Autonolas protocol3 and has the aim of enabling a self-sustainable ecosystem
of autonomous services4 .
The key resource in increasing the number of software services and/or code
components in Autonolas is that of software developers. As such, the model gives
due consideration to attracting and retaining software developers and facilitating
the composability of their code contributions, which enables software code to
become more than the sum of its parts. The model is additionally geared towards
attracting capital in order to make this capital useful, by pairing it with useful
code. Finally, the model introduces a novel mode of production for the ecosystem
of autonomous services to become sustainable. We expand on these objectives
next.
2.1 Model objectives
• Pairing Capital and Code.

The first objective of the tokenomics model is to enable the pairing of capital
and code in a permissionless manner. This pairing is essential because code on
its own does not communicate its value, and capital on its own is not productive.
Combined, these tenets reinforce each other. Indeed, by pairing quality code with
capital, we partially tackle a key problem faced in open-source development: de-
veloper time is a scarce resource subject to insufficient remuneration. A bonding
mechanism can be used to grow the protocol’s capital in the form of protocol-
owned liquidity (and this bonding mechanism is, as we shall see, designed in such
a way that allows bonded capital not to exceed code usefulness). And a novel
“staking” model for code allow developers to track their code contributions on-
chain (e.g. on Ethereum) and receive rewards for its usefulness5 .
• Enabling Protocol-owned Services (PoSe).
The second objective is to create a flywheel that attracts increasingly more
value and provides truly-decentralized autonomous services, owned by a DAO6 ,
operated by ecosystem actors, and coded by the ecosystem developers. The novel
3
The Autonolas (on-chain) protocol was deployed on the Ethereum mainnet in the
Summer of 2022.
4
A high level summary of this tokenomics is also provided in the Autonolas whitepa-
per, see Chaper 3 in [23].
5
Code usefulness is measured in terms of the relative contribution of the code to the
donations accrued by the Autonolas protocol. The term usefulness and its related
measures will be more clear in what follows, cf. Sections 3.1 and 5.1.
6
Decentralized Autonomous Organization.
4 Valory AG
tokenomics primitive, defined as protocol-owned service (PoSe), enables the DAO

that manages the PoSe to own a productive service and derive profits from it.
The flywheel can be created by acquiring and productively deploying in the
ecosystem the profits accruing from Autonolas’ PoSes and the donations arising
from autonomous service (see Section 2.3).
• Incentivising Composability.
The third objective is to enable and incentivize software composability. In a
nutshell, “a platform is composable if its existing resources can be used as build-
ing blocks and programmed into higher order applications.” Composability of
software components in an ecosystem enables exponential returns. This com-
posability is enabled by representing code and services as NFTs registered on
a public blockchain and be combined together into higher-order applications.
The composability is then extended by the tokenomics model that allows devel-
opers to track their code contributions on-chain and receive rewards for their
usefulness (cf. footnote 5 above).
To accomplish these objectives, a token is used as a coordination mechanism.
This explains why we talk about token-economics model or, as more widely
known, tokenomics model. Notably, Autonolas tokenomics coordinates the above
objectives via the OLAS token introduced below.
2.2 OLAS token
OLAS is a tradable utility token that provides access to the core functionalities of
the Autonolas protocol. The token follows the ERC20 standard [13] and has been
deployed on the Ethereum mainnet (OLAS token). OLAS follows an inflationary
model that accounts for the economic primitives enabled by this tokenomics, such
as the bonding mechanism and specific OLAS top-ups, e.g. extra incentives that
developers can eventually receive (cf. Sections 3.1 and 5.2).
However, the bonding mechanism and top-up incentives are designed to not
lead to an unrestricted amount of OLAS being issued. Notably, an inflation
schedule is used to limit the maximum of what can be minted every year (cf.
Section 4).
Regarding incentives, 47.35% of the fixed token supply (i.e. 1 billion OLAS)
of the first 10 years is programmed to be distributed to the ecosystem. After 10
years the maximum token inflation per annum is capped at 2% and the DAO
governance can opt to further reduce it. The aim is to have an s-shaped curve of
token emissions to allow for the ecosysistem to organically grow over time. The
rest of the fixed token supply is distributed as follows:
– DAO Treasury: 10%
– Development reserve: 10%
– DAO founding members: 32.65%
Fig. 1 gives a graphical representation of the OLAS allocation. Note that
OLAS initially allocated for founding members are, in practical terms, locked,
and unlock over the course of four years.
Fig. 1. OLAS token allocation, where Rewards are obtained by minting
2.3 Business Model
In order to build a sustainable autonomous services ecosystem, the majority of

protocol profits are expected to arise from the following three primary contrib-
utors.
– Protocol-Owned-Services: The Autonolas DAO can run services whose prof-
its are then returned to the protocol and are owned by the protocol treasury.
Towards the growth of the ecosystem, the DAO can choose to share some
of the profits - through the donations mechanism - with the developers who
contributed useful code to the PoSes.
– Protocol-owned liquidity: This can either be deployed to third-party proto-
cols for purposes like providing liquidity in decentralized exchanges or put
to work in protocol-owned services. All profits returned from PoL are under
the protocol’s treasury ownership.
– Third-party services (incl. third-party PoSes): A limited amount of the pro-
tocol’s profits likely comes from the treasury’s fee on the voluntary donations
from third-party services. Specifically, anyone can use the donation mecha-
nism to provide a donation for services registered on the Autonolas protocol.
The donation mechanism allow then to calculate a fair distributions of the
donations to share among the developers (owner of staked code NTFs) who
contributed with useful code to the useful services. The DAO can opt to
turn on fees on the amount donated. Such fees are then under the protocol’s
treasury ownership.
Slashed agent operator bonds (cf. Section “Agent Operator Perspective” in
[23]) are another, likely limited, source of treasury profits.
6 Valory AG
Fig. 2. Value flow: from the donator to useful code rewards and to the protocol trea-
sury. During the initial 10-year growth phase the code rewards can be topped up with
OLAS issuance.
3 Autonolas tokenomics in a nutshell

We recall that the focus of this tokenomics model is to increase the number and
quality of autonomous software systems (or autonomous services). We believe
that a crucial step in achieving this goal is to place software composability at
the core of the design of autonomous services. In other words, software compo-
nents of autonomous services can be composed into larger components or into
agents, agents into services, and services can be easily composed with each other.
The mathematical model leverages these properties of composability in order to
incentivize software development and push further composability toward the ex-
ponential growth of functionalities. Moreover, the mathematical model and the
Autonolas protocol are designed in such a way, the tokenomics objectives are
reached as autonomously as possible.
To accomplish Autonolas’ objectives, our proposed tokenomics model pri-

marily leverages the following primitives:
i. Staking model for agents and components code. Developers of agents
and components can register their code on-chain by using Autonolas reg-
istries (see [9] for the registries repository and “On-chain Protocol to Anchor
Agent Services” section of [23] for more details on the technical architecture).
By means of NFTs [14], the registries allow developers to uniquely represent
on-chain their code that is stored off-chain. Then the developer can accrue
incentives proportional to their code contribution.
ii. Bonding mechanism. The protocol can grow its own liquidity by incen-
tivizing liquidity providers to sell their liquidity pairs (with one of the tokens
in the pair being the protocol token, e.g. OLAS-ETH) to the protocol in ex-
change for OLAS at a discount.
iii. Protocol-owned services (PoSes). These are autonomous services, owned
by a DAO, run by ecosystem operators, and implemented by (third party)
developers. This novel primitive enables the DAO that created the PoSe to
own productive autonomous services and derive donations from them.
3.1 How is the staking of the code incentivized?
The workflow for developers can be summarized as follows.

1. Developers build their components or agents as code.
2. Developers can have their code uniquely represented by NFTs on-chain. In
a sense, developers are staking their code NFTs in favor of the ecosystem.
3. Developers (that may and may not correspond with any of the developers
that created the underlying component) can use staked components and
combine them together into new components or agents and then stake their
new code NFTs7
7
Technically, developers can also decide to not stake their code contribution, though
tokenomics only incentivize staked code.
8 Valory AG
Service owners can therefore use staked agents and components to build
autonomous services. Using the Autonolas protocol, service owners can register,
manage and secure their own services on-chain.
Once the code can be uniquely tracked on-chain through their representation
as an NFT, Autonolas tokenomics allows to automatically measure the code
NFT’s contribution to the ecosystem and, based on that, compute the corre-
sponding code NFT incentives.
The business model described in Section 2.3 shows that donations accrued
from autonomous services provide one of the primary contributions to the pro-
tocol. Each donation (currently accepted in ETH) sent from a service owner
(or any other entity) is an indication of the usefulness of the service, and such
donation is considered as a proxy for the ecosystem of the code making up the
useful service. Therefore the usefulness of code NFTs is measured in terms of
the donations that such code NFTs facilitate (see Section 5.1 for a full account
of measures for useful contribution).
Autonolas tokenomics autonomously allocates a proportional share of the
donation accrued by the protocol to useful code NFTs that facilitated it (see
reward formulae in Section 5.2).
Moreover, whenever the agent or the component NFT is referenced in a useful

service whose owner or whose donator locks OLAS for Autonolas governace
token veOLAS8 , the Autonolas Protocol tops up the share of donations going to
developers that own the agent or component NFT with freshly minted OLAS.
The OLAS top-up acts like an “NFT staking reward”: e.g. developers stake their
“useful” code NFTs for autonomous services and receive a share of the OLAS
inflation in exchange.
Incentives in ETH and top-ups in OLAS create a “push” and “pull” dynamic.
The “push” results from the potential yields in ETH tokens that attracts devel-
opers not yet interested in the protocol token. Other than the potential yields in
ETH and OLAS boosts, the “pull” also results from the potential governance im-
pact on adjusting yields and reward boost for useful code NFTs that developers
can accrue by locking their OLAS boosts.
3.2 How and when is the bonding mechanism incentivized?
Another source of the protocol’s capital, as mentioned in Section 2.3, is provided

by leveraging a bonding mechanism for protocol liquidity inflow. Similarly to
what Olympus DAO bonding offers [15], bonds allow users to buy OLAS from
the protocol at a discount by exchanging it for liquidity assets (LP tokens, e.g.
ETH-OLAS). Autonolas bonds have a certain time to vest, called the vesting
8
Note that there is a minimum threshold of veOLAS which should be owned by the
service’s owner in order to enable OLAS top-up.
period. After the vesting period expires, the bonder can claim the OLAS in
full. The main difference with Olympus DAO is that the Autonolas bonding
mechanism is built in such a way that bonded capital in the protocol does not
exceed code usefulness. Moreover, as already mentioned in Section 2.2, Autonolas
bonding mechanism not brings an unrestricted inflationary schedule with large
amounts of new OLAS issuance in short time. Notably, the inflation schedule
described in Section 4 is used to limit how much can be minted every year at
maximum. In turn, since bonding implies minting new OLAS tokens, there is a
maximum amount that can be bonded every year.
Specifically, a control mechanism is introduced to ensure that the growth of

Protocol-owned Liquidity (“Capital ”) is proportional to the potential growth of
the components and agents (“Code”) productively deployed in services in the
ecosystem. Such a control mechanism is enforced by several built-in on-chain
metrics which are used to estimate the potential for the production of code
by means of a production function P F (.) (see Section 5.3 for more details).
Currently, the mechanism can be described as follows: the larger the current
value of P F (.) is, the larger the discount at which bonders receive OLAS, and the
smaller P F (.), the smaller the discount, while respecting the inflation schedule.
This control mechanism enables “push” and “pull” dynamics when there is
a high potential output in the production of useful code that, in turn, could
be productively deployed in autonomous services. The “push” results from an
advantageous discount that a bonder can receive in purchasing bonds. The “pull”
results in the willingness of the OLAS holder to provide liquidity to the protocol
thus contributing to token price stability.
3.3 Incentive compatibility
This tokenomics model is aimed at aligning the goals between the various players
in the ecosystem. Such goal alignment can be enforced through economic incen-
tives designed such that the overall higher expectation of benefit arises from
conducting honest rather than adversarial actions. Players that are incentivized
with rewards, or that are crucial for reward allocation, are code developers (e.g.
agent and component NFT owners), autonomous service owners, and Autonolas
DAO members.
Developers perspective. The more useful services reference a code NFT, the
more incentives are allocated to that code. As more code is staked, more services
can be created and, in turn, the higher is the likelihood that such services are
useful and larger can be incentives for the useful code.
Moreover, the amount of gas needed for creating services increases with com-
plex code, e.g., components and/or agents with a lot of dependencies. So the
likelihood to have more references for staked code increases when the developer
built an agent or a component by adding the minimal required information and
the minimum number of dependencies to make such code self-consistent (cf.
10 Valory AG
Section D in the Appendix for further details). Therefore the developer benefits
from correctly staking their code and adding due diligence into their development
process.
Service owner perspective. Continuous staking of newly developed or well-

maintained agents and components allows service owners to update their services
and or deploy new ones. This in turn increases the likelihood that service owners
have competitive services with higher chances of obtaining increased revenue
from their users.
As more donations are accrued by the protocol from a service owner, the
more incentives are allocated to the code referenced in such a service, and in
turn more developers are incentivized to continue deploying and staking new
code.
Thus, service owners not only have an interest in donating to the protocol
in order to increase developer incentives, but they are also pushed to stake
OLAS for veOLAS (giving them eligibility to participate in the Autonolas DAO
governance) to adjust and boost incentives for owners of code NFTs.
DAO members perspective. Autonolas DAO is composed of veOLAS holders

(cf. section “Level 2: Locking” in [23]). Holders of veOLAS are incentivized to
maximize the utility of the OLAS token which they have locked away in return
for governance rights. Notably, this can be done by wisely choosing governance
parameters that determine how donations accrued by the Protocol and newly
minted OLAS are shared across two recipients (Code owners of NFTs and pro-
tocol treasury) of rewards in Autonolas tokenomics.
Moreover, upon activation of off-chain signaling (cf. Section “Level 3: Off-
chain Signaling” in [23]), veOLAS holders will9 also be able to shape the protocol
by signaling the positive/negative contributions of agents, components, or ser-
vices which complements on-chain built-in code usefulness measures.
3.4 Ecosystem Flywheel
Autonolas provides a token-mediated coordination mechanism for the creation,

operation, and sustainability of autonomous services. This is achieved via a fly-
wheel designed to attract increasingly more value and provide more PoSes, owned
by DAOs, operated by participants in the ecosystem, and implemented by de-
velopers.
At a high level, the Autonolas flywheel looks as follows:
1. A developer builds a component or agent code and stakes the associated
code NFTs on-chain.
2. The component/agent enables more functionality which adds value to the
ecosystem.
3. Autonolas DAO or any other DAO can operate its own services made up of
agents and their components.
9
This functionality is not active in the early days of the protocol’s operation.
3. Autonolas protocol accrues donations from its own PoSes and/or third-party
PoSes.
4. Autonolas protocol rewards useful component/agent NFTs owner with a
share of accrued donations, and eventually, tops up such rewards with newly
minted OLAS.
5. Bonders bring capital (in the form of LP tokens) to gain a discount on the
OLAS price. The discount increases downstream protocol donations and/or
encourages more useful code to be staked. Protocol-owned liquidity and
OLAS price see upward pressure.
6. The deployment of Protocol-owned Liquidity and the increase of OLAS price
attracts developers to contribute with more Code (which closes the loop of
the flywheel).
Fig. 3. Ecosystem flywheel
4 OLAS Inflation Schedule
As discussed earlier (cf. Section 2.2), OLAS is an inflationary token. During the
first 10 years, 47.35% of the total token supply (1 billion) is expected to be issued
via bonding (cf. Section 5.3) and component/agent top-ups (cf. Section 5.2).
Further, the protocol is programmed to maintain a low (0 − 2% p.a.) level of
token inflation thereafter. Issuing most of the OLAS before Autonolas has full
recognition is to be avoided whenever possible. Hence during the first years from
the protocol’s launch, inflation is relatively small, with the highest inflation ratio
taking place in years 2 to 4. Such a choice implies an s-shaped curve of token
issuance.
Technically, the inflation schedule can be described by means of the following

parameters:
12 Valory AG
• First year inflation rate: the percentage of the initial token supply that is
minted during the year of the OLAS token launch
• Second year inflation rate: the percentage of the token supply that is minted
during the second year
• Initial inflation rate: the percentage of the token supply that is minted for
the third year
• Dis-inflation rate: the rate with which inflation is decreased every year in
the range comprising year 3 to year 9
• Long-term inflation rate: tokens minted in the long run
Fixed parameters After having simulated various inflation schedules the fol-
lowing parameters have been proposed:
• First year inflation rate: 0.6%
• Second year inflation rate: 7.2%
• Initial inflation rate: 12.5%
• Dis-inflation rate: 16%
• Long-term inflation rate: 2%
In Fig. 4 is shown the annual inflation rate, starting from 0.6% and arriving
at 7.2% during the second year after the OLAS token launch. Then during the
third year the inflation rate is set to 12.5%. The inflation rate then decreases by
∼ 16% yearly, e.g. the inflation rate reaches 12.5(1 − 0.16) = 10.5% during the
fourth year after the OLAS token launch and so on.
Fig. 4. Inflation schedule for the first 10 years from the OLAS token launch
From this Inflation Schedule, we extract in Fig. 5 the s-shaped curve of token
issuance over 10 years.
Fig. 5. s-shaped token supply curve for the first 10 years from the OLAS token launch
Inflation distribution This inflation schedule dictates how much OLAS can
be minted per year at a maximum. The distribution of the annual inflation is
parametrized by the DAO governance. Specifically, the DAO governance chooses
the following values:
• the fraction a of inflation intended for the bonding mechanism (cf. 5.3)
• the fraction b of inflation intended for agents/components OLAS top-ups
(see 5.2)
Note that, if not all the fraction of inflation intended for bonding gets ac-
tually minted during a specific period, the remaining amount can be added to
the fraction of the next period. Finally, it is worth noting that the Autonolas
Treasury gets nothing from the mint.
The role of Governance The parameters of 1 billion OLAS tokens that can be
emitted during the first 10 years and the long-term inflation rate are immutable
(implemented in the OLAS token smart contract) in order to give further guid-
ance to governance processes. However, except for these immutable constraints,
the DAO may modify the bonding fraction a and OLAS top-ups fraction b. Fur-
ther, by deploying a new tokenomics contract, the governance can also increase
the maximal annual inflation rates with only constraints of minting no more
than 1 billion of OLAS during the first 10 years and no more than 2% of the
total supply after ten years.
14 Valory AG
5 Tokenomics Mathematical Model

Definition 1. Let C be the set of all components registered on the protocol, A
be the set of all registered agents, and S be the set of all registered services.
Let Ca be the set of components referenced in the agent a ∈ A, Cs be the set of
components referenced in the service s, and As be the set of agents referenced
in the service s.
Definition 2. An epoch consists of a time frame in which we consider events that
contribute to our measurements. Since the protocol is deployed on a blockchain a
time frame can be defined in block numbers, specifically, we can say that an epoch
is any consecutive period of m blocks. An epoch can be alternatively defined as
a period of se seconds. Let n be the current block number with timestamp t and
let m0 be the tokenomics deployment block with timestamp t0 . Then
n − m0 = m · km + dm
where dm is the remainder and it takes values from 0 to (m − 1). Similarly,
t − t0 = se · hse + rse
where rse is the remainder and it takes values from 0 to (se − 1). Hence the
block number n is in the epoch number (km + 1) (alternatively in the (km + 1)-
th epoch), where m stands for the consecutive blocks in an epoch. Similarly,
the block timestamp t is in the epoch number (hse + 1) (alternatively in the
(hse + 1)-th epoch), where se takes into account the choice of the consecutive
seconds in an epoch. Note that the number m and se are parameters that can
be tuned by the DAO governance and have a minimal value ( block numbers in
7 days and 7 days in seconds, respectively). For the sake of simplicity, we often
omit subscripts.
Definition 3. The following value citcs (e) is used to measure whether the com-
ponent c has been referenced in a service s at the e-th epoch:
(
1, when c is referenced in the service s at the e-th epoch
citcs (e) =
0, otherwise
Similarly, the following value is referenced to measure whether the agent a has
been referenced in a service s at the e-th epoch:
(
a 1, when a is referenced in the service s at the e-th epoch
cits (e) =
0, otherwise
5.1 Definition of the Contribution Measures for Usefulness of Code

Here we introduce measures for the usefulness of code. Throughout we denote by
s(e) a generic registered autonomous service and rs (e) be the donation (in ETH)
that the protocol received from a service owner (or any other entity) as signal
of the usefulness of the service s during the e-th epoch. Whenever rs (e) ̸= 0 the
service s is said to be useful during the e-th epoch.
Usefulness of Code in Terms of Donations: Component Case Let c ∈

C be a code component. We compute, U CFc , the Useful Code Factor for the
Component c, by considering the number of times c featured in a useful service.
When ∃s(e) : rs (e) ̸= 0, then
c
P
s(e) cits (e)rs (e)
U CFc (e) = P . (1)
s(e) rs (e)
That is when there is at least a useful service during the e-th epoch, U CFc (e) is
a fraction where the numerator is the sum of all donations across all services in
which the component c features and the denominator is the sum of all donations
across all services. Otherwise, if there is no useful service during the e-th epoch,
then
U CFc (e) = 0. (2)
Specifically, U CFc can be interpreted as the relative contribution of a component
at the e-th epoch. Whenever U CFc (e) ̸= 0 we say that c is useful component
during the e-th epoch.
Usefulness of Code in Terms of Donations: Agent Case An agent is

made of components, hence the measure of the usefulness of agent code a could
be viewed as the usefulness of the components making up a. Instead, as we have
done per component, we will define agent usefulness in terms of the donations
for useful services referencing a.
Specifically, when ∃s(e) : rs (e) ̸= 0, we define, U CFa , the Useful Code Factor
of the Agent a, as follows:
a
P
s(e) cits (e)rs (e)
U CFa (e) = P . (3)
s(e) rs (e)
That is, when there is at least one useful service during the e-th epoch, U CFa (e)
is a fraction where the numerator is the sum of all donations across all services
in which the agent a features and as denominator the sum of all donations across
all services. Otherwise, if there is no useful service in the e-th epoch, then
U CFa (e) = 0. (4)
Hence, also U F Ca can be seen as the relative contribution of an agent in an

epoch. Moreover, we say that a is a useful agent during the e-th epoch when
U CFa (e) ̸= 0
The following observation is an immediate consequence of the U CFc and

U F Ca definitions.
Remark 1. Let X be either the set of all component, C, or the set of all agents,
A, and let x be respectively a component c or an agent a, and let code be
respectively either a component or an agent. Then the following hold true.
16 Valory AG
0 ≤ U CFx (e) ≤1, ∀x ∈ X, ∀e.

X
0≤ U CFx (e) ≤ number of profitable software components
x∈X
X
U CFx (e) = 0 ⇐⇒ ∀s(e) : rs (e) = 0
x∈X
A crucial requirement for using these measures in our tokenomics model is

that they must be incentive-compatible. That is, it must be non-trivial to affect
them, and actions affecting them must lead to incentive-compatible outcomes.
For this reason, the measures were for based only on components and agents
which feature in services returning donations to the protocol. For a list of prop-
erties of these measures and their proofs, see Proposition 1 in the Appendix.
5.2 Incentives for staked code NFTs
As described in the Section 2.1, Autonolas tokenomics aims to incentivise useful

code NFTs and it autonomously allocates the proportional share of the protocol
accrued donation to the code NFTs that facilitated it. Donations are in third-
party tokens, currently accepted in ETH. Consequently, rewards for useful code
NFTs are in third-party tokens as well (cf. the subsection Reward formula
below). The rewards in ETH can eventually be topped-up with newly issued
OLAS tokens. These so-called OLAS top-ups are for owners of useful code NFTs
referenced in whitelisted PoSes. The whitelist is operated in a permissionless way:
service owners can opt into the whitelist by locking up OLAS for veOLAS to
align long-term incentives (cf. the subsection Top-up formula below).
Reward formula As mentioned in the Section 2.3, the donations can be accrued
by the Autonolas protocol from Autonolas PoSes or third-party PoSes. The
totality of such donations are then divided among useful component-agent NFT
rewards and the DAO treasury. However, the DAO can choose the fractions of
the donations intended for funding each one of the categories mentioned before.
Let’s assume that by the end of the e-th epoch, the services s1 , . . . , st are
all the useful services, e.g. the service for which an entity (that may or not
coincide with the service owner) has made a donation. Let r1 + · · · + rt be the
total donations accrued by the protocol during such an epoch, let Rcomp (e) =
cf ·(r1 +· · ·+rt ) be the fraction of the total donations to fund useful components
reward, and let Ragents (e) = af · (r1 + · · · + rt ) be the fraction of the total
donations used to fund rewards for useful agents. Further, let ncomp (sj ) and
nagents (sj ) be the numbers of components and agents that are referenced in
the service sj . Then, the following amounts are autonomously reserved to the
owner of the NFTs representing the useful component ci and the useful agent ai
respectively.
c X citcsij (e)rj
Rcomp (e) X citsij (e)rj
rewci (e) = P = cf · , (5)
1≤j≤t rj ncomp (sj )
1≤j≤t
ncomp (sj )
1≤j≤t
a X citasji (e)rj
Ragents (e) X citsji (e)rj
rewai (e) = P = af · , (6)
1≤j≤t rj nagents (sj )
1≤j≤t
nagents (sj )
1≤j≤t
where citcsij citasji are the values introduced in Definition 3.
Note that the formulas (5) and (6) can be obtained by utilizing the useful
code factors U CFci and U CFai introduced in Section 5.1. The curious reader
can find more details in Appendix B.
This reward allocation demonstrates incentive compatibility in the following

sense: to each component ci (resp. agent ai ) it is allocated a fraction, i.e. cf
(resp. af ), of the sum of weighted donations that ci (resp. ai ) facilitates, where
the weight relative to the donation rj of ci (resp. ai ) is citcsij (e)/ncomp (sj ) (resp.
citasji (e)/nagents (sj )). Notably, ci (resp. ai ) receives no more than the total dona-
tions that the services referencing ci (resp. ai ) provided to the protocol, and, all
ceteris paribus, as more useful services reference ci (resp. ai ), they will receive
more rewards.
Top-up formula The OLAS top-ups are incentives for useful code NFTs ref-
erenced in whitelisted PoSes. To have their PoSes whitelisted, service owners
have to lock up a certain amount of OLAS for a certain amount of time in order
to own at least the required veOLAS threshold. This threshold is chosen by the
DAO and is initially set to 10’000 veOLAS.
Let sj be a whitelisted service and rj the respective donation accrued

by the protocol at the e-th epoch, for j = 1, . . . w. Let TopUpcomp (e) and
TopUpagents (e) be the fractions of the amount of OLAS that can be minted
through inflation during the e-th epoch for OLAS top-up of useful components
and agents in whitelisted services. Then the following amounts are autonomously
reserved to the owner of the NFTs representing the useful component ci and the
useful agent ai .
TopUpcomp (e) X citcsij (e)rj

TopUpci (e) = P ; (7)
1≤j≤w rj ncomp (sj )
1≤j≤w
TopUpagents (e) X citasji (e)rj

TopUpai (e) = P , (8)
1≤j≤w rj nagents (sj )
1≤j≤w
where ncomp (sj ), nagents (sj ), citcsij (e), and citasji (e) are defined in the previous
subsections.
Currently, the veOLAS threshold is set to a low value, and all available
OLAS (sets by the DAO for code top-ups) are used each epoch. Hence there is a
18 Valory AG
considerably large incentive in registering services and making donations. This

choice had been made to further incentivized early service developers and early
users of the protocol in the bootstrapping phase.
While incentivizing participation, such a setup could be utilized in unin-
tended ways, resulting in behavior that enables users to accumulate a significant
portion of the OLAS inflation designated for top-ups. This behavior becomes
less and less profitable after major players start utilizing the protocol, and more
donations to more services are processed and shared with multiple stakeholders.
The DAO can further minimize it by allocating a larger share of service dona-
tions (in ETH) to the treasury. During the bootstrapping phase, we acknowledge
that counter-intended behavior poses a risk that can be accepted to boost early
participation in the protocol. However, the DAO retains the ability to update
the top-up formulas whenever necessary.
5.3 Bonding: Discount Factor, Production Function, and Direct

Control Factor
In this section, we introduce the concept of bonding and how Autonolas con-
trols this financial primitive to incentivise the pairing of capital and code, while
respecting the OLAS inflation schedule.
The bonding mechanism is a financial primitive to acquire assets. In the
crypto space, protocols utilize bonds as a means to accumulate assets, including
their own liquidity, by offering their own tokens at a discounted rate. Bonds are
one of the mechanisms (cf. Section 2.3) for Treasury inflows, and thus, for the
growth of the network. Bonders provide capital with the promise of a fixed return
after a certain vesting time. The return is provided in OLAS, so the bonder’s
profit would be contingent upon the price of OLAS at the time of bond maturity.
Specifically, an investor with whitelisted liquidity provider (LP) assets from
a given DEX10 , e.g., OLAS-DAI, OLAS-USDC, or OLAS-ETH can bond those
assets11 at time t. Then at time t + tv , where tv is the vesting time, the investor
receives OLAS at a discount relative to the price quoted on the relevant DEX.
For the sake of argument, one can think that the vesting period is in the range
of days, typically between 7 and 14. This is however a parameter that can be
adjusted through governance.
So, let’s assume that an investor wants to bond LP-assets at time t, with
a price of bp on a relative DEX. Then, at time t + tv , the investor receives a
number of OLAS tokens priced at ubp . The bonder’s profit then depends on the
price ubp . Specifically, the following holds
ubp (t) = (1 + ϵ(t))bp (t).
That is, at time t + tv , the investors receive a number of OLAS tokens whose
price at time t was bp (t) + ϵ(t)bp (t). The value ϵ(t) can be defined as the interest
rate on purchased bonds with price bp (t).
10
A DEX is a decentralized exchange [10].
11
LP assets can be bonded via the Autonolas depository smart contract [21].
The discount factor is the value that needs to be multiplied by the future
cash flow of an investment to obtain the initial price. So the discount factor
DF (t) is defined as
1
DF (t) = .
1 + ϵ(t)
Supply and demand of bonds can be regulated using the interest rate and
the discount factor. Specifically, in situations where the supply of bonds is large
and the demand is low, incentivizing demand growth can be achieved by setting
the interest ϵ(t) to a high value and DF (t) to a low one. This ensures that the
return on investment (ROI) for simply bonding for a short duration is relatively
high. On the other hand, when ϵ(t) is set to a very small (or negative) value,
and thus DF (t) is set to a very high value, it implies a minimal or no return on
investment (ROI). In principle this discourages the purchase of additional bonds
in scenarios where supply is scarce and demand is high.
Similar to protocols such as Olympus DAO [15, 16], Autonolas bonds also
adapt to supply and demand by providing a variable return on investment rate
to the market and its bonders. However, the innovation in Autonolas lies in the
inclusion of additional parameters that enable the discount factor to influence
the ROI. This ensures that the bonded capital aligns with the usefulness of the
code while adhering to the OLAS inflation schedule.
Production Function In order to pair code and capital, it is necessary to

have a measure of the potential output resulting from the development of agents
and components, which can be achieved through a production function denoted
as P F . In Economics, a production function establishes a relationship between
the outputs of a production process and the inputs used in that process. It is a
mathematical function that quantifies the amount of output achievable given a
certain set of inputs. Typically, these inputs include capital and labor.
Since the protocol capital should not exceed the usefulness of the code, the
output of the production is useful code (components and agents). New code allows
the creation of new services which, in turn, increases the likelihood of donations
to the protocol. Donations as well as productively deployed protocol-owned liq-
uidity (PoL) allows for funding new developers. So the production process is the
creation of the code.
While the inputs are the capital that the treasury gained and the number
of developers that can potentially build new code. Specifically, let K(e) be the
share of the donations accrued by the protocol from donations during the e-th
epoch that is reserved to the treasury. Hence K(e) can be seen as the capital
“gained” from donations and that can be later used by the protocol to fund new
developers. Therefore is used as the “capital” input of the product function12 .
12
It is worth noting that, once the bonding mechanism starts, as a result of owning
the LP-tokens, the protocol can also accrue some fees. However, the amount accrued
from fees is not accounted for the “capital” input because not being directly matured
by only leveraging the produced code.
20 Valory AG
Moreover, let D(e) be the number of developers that produced useful agents and
components13 during the e-th epoch. Hence D(e) can be seen as the estimated
number of developers that can potentially produce new useful code in the next
epoch. Therefore is used as the “labour” input of the product function.
Summarizing the following parameters are used in the product function:
• Output: valuable code that can potentially enable more services that, in turn,
can bring donations
• Production process: creation of components and agents
• Inputs:
◦ K(e) that is the capital gained by the protocol via services donations at
the e-th epoch that can fund the development of new code
◦ D(e) the number of developers (labour ) that produced useful code during
the e-th epoch.
All ceteris paribus, as the capital K increases, it is possible to pay more
developers that, in theory, bring new valuable code. And, all ceteris paribus, as
the number of developers producing valuable code in the ecosystem increases,
in theory, more valuable code can be built. Considering these observations and
the fact that we aim to prioritize getting simple, sufficient solutions in place as
soon as possible, we consider a perfect substitutes production function where
the inputs are substituted at a constant rate
f (K, D) = A(k · K + d · D)
for some constants A, k, d. The value A is called factor of productivity and mea-
sures residual growth in total output that cannot be explained by the accumula-
tion of traditional inputs such as labour and capital. Since we are considering a
simple path, we now set A = 1. In the future, when more data can be collected,
the model can be adjusted or enriched to face more complex situations14 .
It remains to define the parameters k and d in such a way that f (K, D)
can output the potential useful code that can be produced with K, D as inputs.
Specifically, we can consider the following definitions:
• k is the number of developers that can be paid per unit of

capital per epoch
• d is the number of units of valuable code that can built by a developer
during an epoch.
By units of valuable code we mean either nc components or na agents. Currently,

we consider a unit of valuable code to be either one component (so nc = 1) or
two agents (so na = 2). Therefore:
13
Useful components or agents are defined in Section 5.1.
14
Note that the DAO can at any time update this bonding model if there is a necessity
of doing so.
• k · K(e) is the number of developers that can be potentially paid per one
epoch with capital K(e)
• d · k · K(e) is the number of the units of valuable code that can be potentially
built in one epoch by k · K(e) developers
• d · D(e) is the number of units of valuable code that D(e) developers can
potentially build during one epoch
In particular, f (K(e), D(e)) = d(k · K(e) + D(e)) determines the amount of
valuable code that can be potentially built during one epoch with capital K(e)
and labour D(e).
Parameters k and d are estimated based on the earnings and performance of
known developers. It is worth noting that the older the protocol, the more data
can be collected and a more realistic estimation of k and d can be made.
We want to conclude this subsection by explicitly mentioning the reasons for
boosting the bonds demand when f (K(e), D(e)) is very large. Firstly, note that
having f (K(e), D(e)) very large, means that with the inputs K(e) and D(e) it is
possible to potentially produce a large amount of valuable code. The production
of more valuable code means that potentially the protocol can accrue even more
donations, and therefore more ETH rewards and OLAS top-ups are distributed.
So bonds demand should be boosted in such a way the protocol increases its
own liquidity and a large amount of liquidity to exchange OLAS is available. So
high volatility in OLAS prices can be avoided.
Measure supply and demand of bonds. To avoid large OLAS issuance and
avoid being beyond inflation limits, Autonolas leverages the fact that investors
prefer liquidity today to small amounts of interest on an investment in the future.
Towards this direction, it is used a bonding rate BR(.) that gives information
on the supply and demand of bonds.
Let τe be the time corresponding to the beginning of the e-th epoch15 and let
τe ≤ t < τe+1 . The bonded amount at time t can be determined by the value that
the LP tokens supplied by bonders are priced in OLAS at the time t. Specifically,
when we say that, at time t, a user has bonded x(t) amount we mean that the
user supplies y(t) LP-token shares (e.g. LP OLAS-Y pairs16 ) which are priced
with x(t) OLAS at the time t of the bonding. Let B(t, e) be the amount bonded
at time t. Denoting by X(t′ , e) the amount of OLAS bonded during the interval
of time [τe , t′ ) ⊆ [τe , τe+1 ), then X(t′ , e) can be computed as follows
Z t′
′
X(t , e) = B(t, e)dt, ∀t′ ∈ [τe , τe+1 ). (9)
τe
Moreover, the amount bondend during the e-th epoch, denoted by X(e), can be
obtained as
15
We recall that an epoch is a consecutive period of m of blocks. When we say the
beginning of the e-th epoch, we mean near the timestamp of the first epoch’s block
16
Here Y can be any other tokens for a bonding program was opened, e.g. Y can be
DAI, ETH, USDC, etc.
22 Valory AG
Z τe+1
X(e) = B(t, e)dt. (10)
τe
Let S(e) be the OLAS supply that can be minted during the e-th epoch.
Such a value can be extracted by the OLAS inflation schedule (see for details on
the inflation schedule 4).
Let M B(e) be the fraction of S(e) that governance allows bonding during
e-th epoch, or in other words, the maximal supply of bonds (priced in OLAS)
that can be purchased during e-th epoch. Being M B(e) a fraction of S(e), it
is smaller than S(e) and so, in each epoch, the supply of bonds is bounded in
terms of the maximum printable amount of OLAS.
It is possible that not all the bondable amounts during an epoch so that
the difference between the bonds supply of the epoch and the bonds purchased
during such an epoch is non-zero. Such a difference, at the e-th epoch, is denoted
by Excess(e − 1). Denoting by EM B(e) the sum of M B(e) and Excess(e − 1),
we have that EM B(e) is the maximal supply of bonds that can be purchased
during the e-th epoch plus the excess of bonds supply that was not purchased
during the previous epochs.
The relations among some of the variables above introduced can be written
in formulas as follows.
EM B(e) := M B(e) + Excess(e − 1)

Excess(e − 1) := EM B(e − 1) − X(e − 1)
We define the bonding rate, BR(t), as follows:
BR(t) := 1 − X(t, e)/EM B(e)
Note that when the bonded amount during the interval of time [e, t), X(t, e),
approaches EM B(e) (everything also equal), BR(t) approaches 0. While, when
X(t, e) approaches 0 (everything also equal), i.e., there is a small or no amount
bonded purchased during the interval of time [e, t), then BR(t) approaches 1.
Therefore 0 ≤ BR(t) ≤ 1, and BR(t) gives information about the supply and
demand of bonds:
– all ceteris paribus, when BR(t) approaches 0, the bonds supply is over;
– all ceteris paribus, when BR(t) approaches 1, there is an over-supply of
bonds.
Direct Control Factor Finally, everything is combined together in a direct

control factor (DCF). Such a DCF is used to progressively define the discount
factor and it allows using PF in such a way the larger P F , the greater the ROI
and the smaller P F , the smaller the ROI while respecting the OLAS inflation
schedule.
We recall that we have seen so far how the production function f can be
defined and that larger f (K, D) the larger the ROI should be and the smaller
f (K, D), the smaller the ROI should be. And we introduced the bonding rate
BR(t) which allows to have information on supply and demand of the bonds.
Now we see how all these are put together to provide Autonolas with a direct
control factor (DCF) which allows to internally control the bonding mechanism.
Firstly, the following parameters are fixed by the DAO governance.
• ϵ(e) := the maximum interest rate that bonders can receive during the e-th
epoch by providing some LP tokens upfront.
• M B(e) := the fraction of S(e) reserved for bonding during epoch e.
The direct control factor at the time τe ≤ t < τe+1 , can be defined as follows.
( n o
1 BR(t) BR(t)
· max 1+ϵ(e) 1+f (K(e−1),D(e−1))/100 , if BR(t) ̸= 0
,
DCF (t) = BR(t)
+∞, otherwise
Hence, if BR(t) = 0 for some t ∈ [τe , τe+1 ), no new bonding program can be
created for the e-th epoch. While, when BR(t) ̸= 0, the discount factor DF
during the e-th epoch can be progressively set equal to DCR(t). That is, when
BR(t) ̸= 0, i.e., X(t, e) < EM B(e), then

1 1
DF (t, e) = max , .
1 + ϵ(e) 1 + (f (K(e − 1), D(e − 1)))/100
In figures Fig. 6, 7 the trends of the interest rate and the discount factor with
respect to the growth of the production function f (K, D) output are represented.
Fig. 6. Trend of the discount factor on a bond with respect to the growth of the
production function output
In summary, whether the supply of the epoch for bonds is over, no new
bonding program is possible for the epoch. Otherwise, if there is still supply
24 Valory AG
Fig. 7. Trend of the (re-scaled) interest on a bond with respect to the growth of the
production function output
to fund bonds and f (K(e − 1), D(e − 1)) is large (yielding a potentially high
production of useful code) bonding is incentivized by having that the interest
rate during the e-th epoch approaches the maximum interest rate set by the
governance ϵ(e). Moreover, whether the supply of the epoch for bonds is not
yet over and f (K(e − 1), D(e − 1))/100 is very small (even smaller than the
epsilon rate ϵ(e)) the bonding is disincentivized by setting the interest rate on the
bonding during the e-th epoch equal to the small value f (K(e−1), D(e−1))/100.
Bootstrapping phase In the early stage of the protocol’s life, it is likely that
donations accrued by the protocol are low, hence there is a high likelihood that,
the production function is small or near zero. Nevertheless, governance has the
possibility of incentivizing bonding also in the early stage of the protocol, e.g.
when there is a high likelihood that the discount factor approaches 1 and the
interest rate approaches zero.
Notably, the governance prices an LP-token when creating a bonding program
(for more details on how bonding programs are created see [21, 22]). Hence it
can boost bond demand by evaluating LP tokens at a higher price with respect
to any relevant DEX. So, bonders by selling their LP tokens shares at higher
prices with respect to the market have an advantage in purchasing bonds in this
way.
6 Conclusion
We have seen how Autonolas tokenomics seeks to create a sustainable ecosystem
of autonomous services by spinning up a virtuous flywheel. By attracting de-
velopers that provide valuable code, the number of valuable services increases,
which in turn boosts protocol’s donations, leaving the ground fertile for at-
tracting further new developers. This is emphasized in the tokenomics model
by incentivizing developers to contribute valuable code to the ecosystem, and it
does so by leveraging the composability of the code contributions. Concretely,
the protocol’s profits generated via service donations (in ETH) are shared with
developers that contributed useful code to the ecosystem and such rewards are
eventually topped-up with part of OLAS inflation over the first ten years (as
explained in different parts of Section 4 and Section 5.2).
Notably, the donation system create a “push” and “pull” market dynamic
from the perspectives of both donators and developers. Specifically, from the
donator perspective:
– the “push” results from the potential impact that donators can have affecting
the rewards and boost for the code NFT owners.
– The ”pull” arise from the fact that donators are attracted by the ability to
trigger significant boosts with small donations.
From the developer perspective:
– the “push” results from the potential yields in ETH tokens that attracts
developers not yet interested in the protocol token.
– The “pull” results from developers interest on significant reward boosts to
their useful code contributions. This implies that developers can receive sub-
stantial rewards for their valuable contributions, and, that, in turn, can be
additionally used to accrue the ability to adjust yields and boost by locking
OLAS boost.
Additionally, Autonolas tokenomics proposes several metrics to evaluate the

usefulness of a piece of code, i.e. an agent or a component, from an economic
point of view. These metrics are built upon a set of useful code factors (see Sec-
tion 5.1) and such measures were built with the additional aim of incentivizing
software composability. Specifically, whenever a component is split into smaller
pieces, and the resulting new components are referenced in more useful services
than the original component, our analysis suggests that the smaller pieces are
more useful than the original component. However, our metrics also show that
the strategy of splitting up components into smaller pieces is not always fruitful.
For instance, if the smaller components are not referenced in more useful services
than the original component, then these smaller components do not qualify as
more useful than the original component. Furthermore, code usefulness metrics
depend on the number of profitable services and on the amount of donations that
the services return to the protocol. For instance, all ceteris paribus, the useful-
ness of a piece of code is inversely proportional to the amount that the services
not referencing such a piece of code returned to the protocol. Moreover, code
usefulness is not hugely different when the overall quantity of profits obtained
by the protocol from services not referencing the code is sufficiently small com-
pared to that obtained by the services referencing it. A proof of the properties
mentioned so far and a more complete list of properties of these measures can
26 Valory AG
be found in the Appendix (see in particular Propositions 1, 2). These metrics

can be enriched even more upon activiation of the off-chain signaling game of
Level 3 of the tokenomics (cf. section “Level 3: Off-chain Signaling” in [23]).
Once there is a high likelihood of new useful code in the ecosystem, the
tokenomics is geared towards attracting bonders, who can make their capital
productive, by pairing it with code. Specifically, whenever there is large potential
production of code usefulness in the ecosystem, the protocol incentivizes users
to pursue bonds (see Section 5.3). Since the bonding mechanism is one of the
means for the growth of the protocol capital and for protocol liquidity inflow, by
incentivizing bonding in such a way, the protocol can invest part of its own grown
capital to enrich the ecosystem investing in new code and own a large amount
of its liquidity. This in turn may bring more stability to the OLAS token.
The bonding mechanism is partly controlled by a production function (see
Section 5.3). To reflect the fact that the more the amount of capital in the
protocol and the bigger the developer number the more useful code is developed,
such a production function increases with a larger quantity of either capital or
the number of developers. Once the production function increases, there is more
discount in purchasing OLAS via bonding. On the contrary, in periods where
almost no useful code is produced, there is almost no discount on purchasing
OLAS via bonding. Finally, it is worth noting that Autonolas bonding does not
disproportionately affect OLAS minting schedule. More concretely, bonds supply
and demand are controlled with respect to the prescribed maximal annual OLAS
inflation. A proof of the properties mentioned so far and a more complete list of
properties in the Appendix (see in particular Proposition 3).
Due to the bonding mechanism and the OLAS top-ups, OLAS follows an in-
flationary token model. However, it has a fixed total token supply over 10 years,
and reaches a stable or at most a slightly inflationary supply afterward (at most
2% p.a. to make up for bonding). Finally, the locking mechanism which prevents
locked OLAS from being traded contributes to OLAS price stability (cf. Section
“Level 2: locking” in [23]). Notably, the locking mechanism creates the follow-
ing “push” and “pull” dynamics. In the bootstrapping phase of the protocol,
“push” results from the potential governance impact on adjusting yields and
reward boosts for early code NFTs owners. After bootstrapping, the “push” also
results in the ability to signal valuable code that can be productively deployed
by veOLAS holders in Autonolas-owned autonomous services (cf. Section “Level
3: Off-chain Signaling” in [23]). The “pull” results from OLAS holders being
incentivized to participate in governance to increase the demand and the utility
of OLAS and see token price appreciation.
References
1. T. Chitra, K. Kulkarni, G. Angeris, A. Evans, V. Xu. DeFi, Liquidity Management
via Optimal Control: Ohm as a Case Study
2. P. Hall. The Distribution of Means for Samples of Size N Drawn from a Population
in which the Variate Takes Values Between 0 and 1, All Such Values Being Equally
Probable. Biometrika, Vol. 19, No. 3/4., 240–245. doi:10.1093/biomet/19.3-4.240
3. J. M. Perloff. Microeconomics. 5th ed. Addison Wesley, 2008. ISBN: 9780321558497.
4. M. Wooldridge. An Introduction to MultiAgent Systems, Wiley, June 2009.
5. Autonolas. Maintaining and Resetting Consensus in Autonomous Services
6. Autonolas. Open-aea framework
7. Autonolas. Open-autonomy framework
8. Autonolas. What is an Agent Service
9. Autonolas. Autonolas registries repository
10. Coinbase. What is a DEX?
11. Cryptopedia. Layer-1 and Layer-2 Blockchain Scaling Solutions
12. Curve DAO. Vote-Escrowed CRV
13. Ethereum.org. ERC-20 TOKEN STANDARD
14. Ethereum.org. ERC-721 NON-FUNGIBLE TOKEN STANDARD
15. Olympus DAO. Bonding
16. Olympus DAO. Stabilizing Currency Through a Protocol-Enforced Range
17. Nat Eliason. Tokenomics 101. The Basics of Evaluating Cryptocurrencies
18. Nat Eliason. Tokenomics 102. Digging Deeper on Supply
19. Nat Eliason. Tokenomics 103. Utility
20. Nat Eliason. Tokenomics 104. How to Launch a Token (Tactics, Questions, Wen,
etc)
21. Valory AG. Autonolas Tokenomics Contracts.
22. Valory AG. Overview of Autonolas tokenomics and smart contracts architecture
23. Valory AG. Autonolas whitepaper
24. Valory AG. Introducing Co-owned AI
25. Valory AG. Co-owned AI
A Properties of Autonolas Tokenomics measures

A service the making a donation to the protocol during the e-th epoch is called
profitable service during such an epoch.
Proposition 1. Let c be a component and a be an agent. All ceteris paribus,

the following hold true.
1. Assume that during the e-th epoch the number of services increases and that
the newly registered services are not profitable. Then U CFc (e) ( respectively
U CFa (e)) remains constant for every component c featuring in the same
number of profitable services (respectively agent a).
2. U CFc (e) ( respectively U CFa (e)) decreases as the number of profitable ser-
vices not referencing c ( respectively a) increases.
3. U CFc (e) ( respectively U CFa (e)) increases as the number of profitable ser-
vices not referencing c ( respectively a) decreases.
28 Valory AG
4. If the number of profitable services not referencing c ( respectively a) in-

creases but the sum of donations from such services is very small compared
to the profits arising from the profitable services referencing c ( respectively
a), then U CFc (e) ( respectively U CFa (e)) does not decrease significantly.
5. If we have two components c and c′ , and c is referenced in more services
producing profits than c′ , but c′ is more valuable with respect c in terms
of the profits that the services referencing c′ gave to the protocol, then
U CFc (e) < U CFc′ (e)
6. Let c′ and c′′ two components such that combined together give the same
code as another component c. If c, c′ , and c′′ are all referenced in the
same profitable services then U CFc (e) = U CFc′ (e) = U CFc′′ (e). While
if either c′ or c′′ are referenced in more services returning profits then
U CFc′ (e), U CFc′′ (e) > U CFc (e).
7. U CFa is not affected by splitting up or combining components.
Proof. Except for the point 7, the proofs of the points 1-6 for U CFc and U CFa
are equal, so, in those points, we are going to consider just U CFc .
1. When U CFc (e) = 0 there is nothing to prove. So assume that c is features
in the services s1 , . . . , st that, during e-th epoch, make the following dona-
tions to the protocol r1 , . . . , rt . While c is not referenced in the new services
st+1 , . . . , sk that make no donations during the current epoch. Then neither
the numerator nor the denominator of U CFc (e) change, so U CFc (e) remains
constant.
2. When U CFc (e) = 0 there is nothing to prove. So assume that c is referenced
in the services s1 , . . . , st that during the e-th epoch made the following dona-
tions to the protocol r1 , . . . , rt . While c is not referenced in the new services
st+1 , . . . , sk which made the following donations to the protocol rt+1 , . . . , rk
during the current epoch. When the number of profitable services increases,
so the number of profitable services passes from k to t + 1, t + 2, . . . , k, the
numerator of U CFc (e) remains r1 , . . . , rt while its denominator progressively
increases as follows
r1 + · · · + rt < r1 + · · · + rt + rt+1 < · · · < r1 + · · · + rt + rt+1 + · · · + rk .
In other words, the denominator increases each time a new service makes
a donation to the protocol. Consequently, U CFc (e) decreases as more prof-
itable services non referencing c increases.
3. If U CFc (e) = 0 we have nothing to prove. Assume that the services s1 , . . . , sk
during the e-th epoch made respectively the following donations to the proto-
col r1 , . . . , rk . Assume that the number of profitable services not referencing
c decreases. Let t ≤ k.
So assume that c is referenced in the services s1 , . . . , st that during the e-th
epoch made the following donations to the protocol r1 , . . . , rt and assume
that the number of profitable services not referencing c decreases.
So firstly assume that c is referenced in the services s1 , . . . , st but not in
st+1 , . . . , sk . In this case:
r1 + · · · + rt
U CFc (e) = . (11)
r1 + · · · + rt + rt+1 + · · · + rk
Secondly, we assume that c features in the services s1 , . . . , st , sk but not in

st+1 , . . . , sk−1 . So
r1 + · · · + rt + rk
U CFc (e) = (12)
r1 + · · · + rt + rt+1 + · · · + rk
Continuing in this way, until we have that c is referenced in all the services
s1 , . . . , st , st+1 , . . . , sk and so
r1 + · · · + rt + rt+1 + · · · + rk
U CFc (e) = . (13)
r1 + · · · + rt + rt+1 + · · · + rk
Since the numerator increases while the numerator remains constant, we have
that the fraction in the equation 11 is bigger than the one in equation 12
that in turn is bigger than the fraction in equation 13. So the statement is
proved.
4. Assume that c is referenced in the services s1 , . . . , st that during the e-th
epoch made the following donations to the protocol r1 , . . . , rt , while c is not
referenced in st+1 , . . . , sk . Assume further that the latter, during the e-th
epoch, made the following donations rt+1 , . . . , rk and that c′ is referenced in
all the services s1 , . . . , sk . Further
rt+1 + · · · + rk << r1 + · · · + rt ,
so that rt+1 +· · ·+rk is negligible with respect to r1 +· · ·+rt . So r1 +· · ·+rt

is not so different from r1 + · · · + rt + rt+1 + · · · + rk and, in turn,
r1 + · · · + rt
U CFc (e) =
r1 + · · · + rt + rt+1 + · · · + rk
is not so different from

r1 + · · · + rt
U CFc′ (e) = = 1.
r1 + · · · + rt + rt
E.g. assume that
r1 + · · · + rt = 100(rt+1 + · · · + rk ).
Then
r1 + · · · + rt 100
U CFc (e) = = ∼ 0.99
r1 + · · · + rt + rt+1 + · · · + rk 101
while
U CFc′ (e) = 1.
30 Valory AG
5. Assume that c is referenced in the services s1 , . . . , st that during the e-

th epoch made the following donations to the protocol r1 , . . . , rt , while c′
is referenced in the service sk producing the following profits rk for the
protocol. Say that c′ is more valuable with respect to c in terms of the profits
that services referencing c′ gave to the protocol means that rk > r1 +· · ·+rt .
Then
r1 + · · · + rt rk
U CFc (e) = < = U CFc′ (e).
r1 + · · · + rt + rk r1 + · · · + rt + rk
6. If c′ and c′′ and c are all referenced only in s1 , . . . , st which made donations
r1 , . . . , rt . By definition of U CFc = U CFc′ = U CFc′′ . However, if c can be
spitted as c′ and c′′ , c and c′ can be used in the services s1 , . . . , st but c′′ is
referenced in the services s1 , . . . , st+1 and st+1 donates to the protocol rt+1 ,
and at the e-epoch s1 , . . . , st are the only profitable services then
r1 + · · · + rt r1 + · · · + rt + rt+1
U CFc = U CFc = < = 1 = U CFc′′ .
r1 + · · · + rt + rt+1 r1 + · · · + rt + rt+1
7. From equation 3 it is clear that U CFa is not affected by splitting up or
combining components.
B Code NFTs rewards by means of the useful code factors

The Kronecker delta is as usual denoted and described as follows
(
1, if k = j
δk (j) =
0, otherwise.
Proposition 2. Let ci and ai be a useful component and a useful agent. The

reward equations (5) and (6) can be obtained by using the useful code factors
U CFci and U CFai as follows
X δscki (e)
rewci (e) = U CFci (e) · Rcomp (e), (14)
ncomp (sk )
1≤k≤t
X δsaki (e)
rewai (e) = U CFai (e) · Ragents (e), (15)
nagents (sk )
1≤k≤t
where δscki (e) and δsaki (e) are such that
δscki (e) · citcsij (e) = citcsij (e) · δscki (e) = δk (j)citcsij (e)
δsaki (e) · citasji (e) = citasji (e) · δsaki (e) = δk (j)citasji (e).
Proof. The proof is the same for component and agent, so we are going to only
consider the component ci . Replacing the definitions of U CFci (e) (cf. 5.1) and
Rcomp (e) (cf. 5.2) on the left-hand side of equation (14) yields:
citcsij (e)rj (e) X

P
X δscki (e) 1≤j≤t δscki (e) X
U CFci (e) Rcomp (e) = P cf rj (e)
ncomp (sk ) 1≤j≤t rj (e) ncomp (sk )
1≤k≤t 1≤k≤t 1≤j≤t
X X δscki (e)
= citcsij (e)rj (e) · · cf
ncomp (sk )
1≤j≤t 1≤k≤t
X citcsij (e)rj (e)
= · cf.
ncomp (sj )
1≤j≤t
The latter coincides with the definition given in equation (5), hence the result
follows.
C Bonding-Related Properties of Autonolas Tokenomics

Recall that, for the moment we consider the following product function:
f (K(e), D(e)) = d(k(e) · K + D(e))
where
• K(e) that is the capital gained by the protocol at the e-th epoch that can
fund the development of new code;
• D(e) the number of developers (the labour) that produced valuable code
during the e-th epoch;
• k is the (average) number of valuable developers the can be paid per unit of
capital per epoch;
• d is the (average) number of units of valuable code17 built by a developer
during an epoch.
Proposition 3. Assume we are at the e-th epoch. All ceteris paribus, the fol-
lowing properties hold true.
1. Having a larger quantity of even a single input {K(e), D(e)} strictly increases
the production.
2. The production function f has constant returns to scale.
3. The production function f has non-negative values.
4. When BR(−) is non-zero, i.e., that is there is still bond supply to be
purchasable, then the DF (e, −) is constant during the epoch. Otherwise
DF (e, −) is infinite.
5. The function
1
1 + ϵ(e)
is not defined when ϵ(e) = −1. In particular,
1 1
lim = −∞ and lim = +∞.
ϵ(e)→−1− 1 + ϵ(e) ϵ(e)→−1+ 1 + ϵ(e)
17
The number of valuable code is either nc components or na agents, and we started
with nc = 1 and na = 1
32 Valory AG
6. When −1 < ϵ(e) ≤ 0 and BR(t) ̸= 0, then

1
DF (e) = .
1 + ϵ(e)
7. If ϵ(e) < −1 and BR(t) ̸= 0, then

1
DF (e) = .
1 + f (K(e − 1), D(e − 1))/100
8. When BR(t) ̸= 0 and ϵ(e) > 0, then

1
DF (t, e) ≥ .
1 + ϵ(e)
9. When BR(t) ̸= 0 and K and D are such that f (K(e−1), D(e−1)) approaches
+∞, then DF (e) approaches
1
.
1 + ϵ(e)
10. When BR(t) ̸= 0, ϵ(e) > 0, and K(e − 1) and D(e − 1) approach 0, then
DF (e, t) approaches one.
Proof. 1. All ceteris paribus, as D′ (e) > D(e),
f (K(e), D(e)) = d(k · K(e) + D(e)) < d(k · K(e) + D′ (e)) = f (K(e), D′ (e)).
Same proof for an increase in capital.

2. Let m ∈ N. Then
f (mK(e), mD(e)) = d(k · m · K(e) + m · D(e)) = m · d(k · K(e) + D(e))

= m · f (K(e), D(e)).
3. The production function cannot have negative values because the worst case
is when the protocol receives no profits and there are no developers during
the epochs. So in the worst case, f (K, D) = 0.
4. Immediate from the definition of DF .
5. Easy to prove with basic knowledge of Calculus.
6. When BR(t) ̸= 0, then

1 1
DF (t, e) = max , .
1 + ϵ(e) 1 + f (K(e − 1), D(e − 1))/100
If −1 < ϵ(e) ≤ 0, then

1
1≤ < +∞.
1 + ϵ(e)
By 3. we have that f (K(e − 1), D(e − 1)) ≥ 0, so
1
≤ 1.
1 + f (K(e − 1), D(e − 1))/100
Hence
1
DF (t, e) = .
1 + ϵ(e)
7. If ϵ(e) < −1, then
1
< 0.
1 + ϵ(e)
By 3. we have that f (K(e − 1), D(e − 1)) ≥ 0, so
1
0< ≤ 1.
1 + f (K(e − 1), D(e − 1))/100
Hence
1
DF (t, e) = .
1 + f (K(e − 1), D(e − 1))/100
8. Let ϵ(e). When f (K(e − 1), D(e − 1))/100 ≥ ϵ(e), then
1 1
≤ ,
1 + f (K(e − 1), D(e − 1))/100 1 + ϵ(e)
so
1
DF (t, e) = .
1 + ϵ(e)
If f (K(e − 1), D(e − 1))/100 ≤ ϵ(e),
1 1
≥
1 + f (K(e − 1), D(e − 1))/100 1 + ϵ(e)
So
1 1
DF (t, e) = ≥ .
1 + f (K(e − 1), D(e − 1))/100 1 + ϵ(e)
That is, once ϵ(e) it is fixed and it is bigger than 0, we have that DF (t, e)
can only be bigger than
1
.
1 + ϵ(e)
9. Since f (K, D) increases with K and D. Very large f (K(e − 1), D(e − 1))
corresponds to very small
1
.
1 + f (K(e − 1), D(e − 1))/100
Moreover, once f (K(e − 1), D(e − 1))/100 ≥ ϵ(e), then

1
DF (t, e) = .
1 + ϵ(e)
34 Valory AG
1
10. Since f (K, D) approaches zero with K and D. Then 1+f (K(e−1),D(e−1))/100
approaches. Since for ϵ(e) > 0, we have that
1
< 1,
1 + ϵ(e)
then
1
DF (t, e) +
1 + f (K(e − 1), D(e − 1))/100
approaches 1.
D Assessment of incentives compatibility for incentivizing

composability
D.1 Size of a component
This section is mainly focused on components because of their natural com-

posability properties. Notably, while agents to accrue more functionalities can
reference more components, usually, components are instead composed together
to provide complex features. With the analysis provided here, we aim to en-
courage a developer to register components of the “right size” and reference
only those in agents and services. The term “right size” will be clear from what
follows.
First, note that the creation of every component is subject to a gas fee which
depends upon the gas price at the moment of the creation and the number of
gas units used. In turn, the gas units depend upon the number of dependen-
cies (i.e. the referenced components or subcomponents) that a component has.
The higher the number of dependencies, the higher the gas units for creating
a component with such dependencies. In turn, the higher the number of com-
ponent dependencies, the higher the gas units for creating agents and services
referencing such components. Specifically, from Fig. 8 we can see how the gas
units for creating a component increase with the number of its dependencies.
Since Ethereum limits the gas per block to a fixed amount of 30 million units of
gas, is likely that a component with way more than 100 dependencies cannot be
registered on-chain.
On the other side, to pursue the goal of composability and re-usability of
components, it is required that self-contained components should be registered
separately and later referenced as dependencies in larger components.
Therefore pairing the fact that minting fees are expensive for creating ‘com-
plex’ components and the fact that a component should be reusable, components
should be built with the idea of adding the minimal required information, and
the minimum number of dependencies to make those self-contained. From this,
the component ‘size’ can be considered to be ‘right’ when such a component is
self-contained (In [6], see section ‘Development - Intermediate’ and subsections
therein).
Fig. 8. Gas units required to create a component with “number of splits” subcompo-
nents at the net of the gas units for one component. Limits per Ethereum block is 30
million units of gas.
Autonolas tokenomics aim to incentivize this wise development. Specifically,

the referencing of subcomponents is incentivized by rewarding useful dependen-
cies of useful components. Where, as usual, the usefulness of a component is
intended in terms of donations that the protocol can receive thanks to such a
component (for more details see the subsections 5.1 and 5.2). However, consid-
ering the gas fees and the fact that the component rewards depend also on the
number of the components referenced in services, referencing components with a
lot of dependencies is advantageous when such dependencies are really necessary.
Evidence of the latter argument is provided in the next subsection.
D.2 Split-components
Here, we provide some results in order to analyze the scenario of a malicious

developer that, in order, to accrue more rewards, starts to split a component
by creating multiple ‘dummy’ dependencies. Here, by ‘dummy’ dependency we
mean a component that is neither self-contained nor reusable to provide more
features to a composite component.
Let’s denote by component with n splits a component that has n−1 dependen-
cies (e.g. n − 1 subcomponents different from the component were referenced).
We consider that a component with n splits is malicious when it could have
been created with no dependency but instead was registered with n − 1 dummy
dependencies. Being its dependencies dummy, it is safe to assume that such
dependencies are only referenced only in services that reference the malicious
component itself and no other services reference any of them.
36 Valory AG
Let’s first consider the case where only one useful service, s, references the
malicious component c with n splits and that such a service references other dif-
ferent g components. Assume that thanks to s the protocol accrues as a donation
the amount r. From equation (5), we can deduce that the developer owner of c
receives the following reward
n
rew(n) = cf · r · , (16)
n+g
where we recall that cf ·r is the share of the donation r reserved to fund the useful
components in s. Note that, the reward approaches its maximum value cf · r
when the splits n is sufficiently larger than the number of extra components g.
Moreover, if a service reference a number of extra components g relatively larger
than the number of splits s, the reward of the malicious developer decreases. A
graphical representation of this is summarized in Fig. 9. Specifically, the blue
curve represents the percentage of the donation share cf · r that a malicious
component c with n splits can receive if the s references c and only one other
component different from c and its dependencies. Similarly, the purple curve
represents the percentage of the donation share cf · r that is given as a reward
to a malicious component c with n splits when the service referenced 100 extra
components. When the service s references 2 < m < 100 extra components, the
rewards curves sit between the blue and the purple ones.
Fig. 9. Reward (as a percentage of total reward) of a malicious component with n

splits when 1, or 20, 50, or 80, or 100 extra components are referenced by the service
Fig. 9 shows that when the number of splits n is sufficiently larger than
the number of extra components g, the rewards distribution approaches the
maximum percentage. However, also shows that when the number of extra com-
ponents increases the reward of the malicious developers decreases. E.g. when
the service references only one extra component, with just 10 splits a malicious
developer can accrue around 90% of the maximal reward cf · r, but, if at least
other 20 components are referenced in the service, the reward of a malicious

component with 10 splits reaches at most 33% of cf · r.
Now, let’s assume that a malicious component c with n-splits is referenced

in the t services, s1 , . . . , st . Assume that these services reference respectively
g1 , . . . , gt extra components and that the donations signaling appreciations for
the services s1 , . . . , st are respectively r1 , . . . , rt . Then, from equation (5), we
can deduce that the developer owner of c receives the following reward
X n
rew(n) = cf · · rj . (17)
n + gj
1≤j≤t
Let gmin and gmax be respectively the minimal and maximal value among the
extra components g1 , . . . , gt and let rmim and rmax be respectively the minimal
and maximal value among the donations r1 , . . . , rt . Then the following holds
n n
cf · t · · rmim ≤ rew(n) ≤ cf · t · · rmax , (18)
n + gmax n + gmin
From equation (18) we can see that

– the percentage of the maximal rewards cf · t · rmax that can be accrued
by the malicious developer grows with the number of splits n at most like
n/(n + gmin ) at a fixed value of gmin
– the speed of the growth towards the maximal reward cf · t · rmax decreases
with the increase of the minimal number gmin of extra components referenced
– the percentage of the minimal rewards cf · t · rmin that can be accrued
by the malicious developer grows with the number of splits n at least like
n/(n + gmin ) at a fixed value of gmin
– the speed of the growth towards the minimal reward cf ·t·rmin decreases with
the increase of the maximal number gmax of extra components referenced.
Hence the analysis does not change even if the number of services referencing
the malicious component is t.
As for the adversarial attack of splitting the components, we can conclude

that there is a low probability that it will ever succeed. Notably, there is a
low likelihood that the owner of services references one component with several
splits (for which they have to pay more gas) and a low number of well-designed
components. Further, there is a low chance that a service not referencing a
well-designed code receives donations as a signal of appreciation. Finally, since
creating a malicious component with several splits is expensive (cf. Fig. 8), the
attack of would also have a high adversarial cost without certainty of repayment.
It is worth mentioning here, that when the protocol unlocks the off-chain
signaling game (cf. section “Level 3: Off-chain Signaling” in [23]) which allows
signaling the positive/negative contribution of a component to enrich on-chain
metrics, veOLAS holders can have a crucial role in highlighting the negative
contributions of malicious components by signaling it off-chain. A sign that the
38 Valory AG
DAO considers negative the contribution of a component implies that honest

developers do not reference such a component anymore. The less such a compo-
nent is referenced in other components/agents, the fewer services reference the
component, and the less become the likelihood of rewards for such a component.
As a final note, it is crucial to observe that registering a malicious component

with n splits can be considered an adversarial attack not only against the pro-
tocol but also against agents and services referencing such a component. This
is because the reference of such a malicious component may negatively affect
the rewards of the other eventually well-designed components in the agent and
the service. Therefore agent developers and service owners have the responsibil-
ity and the advantage of referencing only well-developed components to receive
future profits from those (cf. Section 3.3).

Autonolas Tokenomics Core Technical Document

Uploaded by

Copyright:

Available Formats

Autonolas Tokenomics Core Technical Document

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Autonolas Tokenomics Core Technical Document

Uploaded by

Copyright:

Available Formats

Autonolas Tokenomics v1

- Towards a Self-Sustainable Autonomous Services

Mariapia Moscatiello, David Minarsch, David Galindo

Valory AG, Zug, Switzerland

Abstract. This yellow paper offers a comprehensive overview of the

Key words: token-economics, software composability, autonomous ap-

– A tokenomics aiming to incentivise software composability to grow a sus-

2.1 Model objectives

• Pairing Capital and Code.

tokenomics primitive, defined as protocol-owned service (PoSe), enables the DAO

2.2 OLAS token

Fig. 1. OLAS token allocation, where Rewards are obtained by minting

2.3 Business Model

In order to build a sustainable autonomous services ecosystem, the majority of

3 Autonolas tokenomics in a nutshell

To accomplish Autonolas’ objectives, our proposed tokenomics model pri-

3.1 How is the staking of the code incentivized?

The workflow for developers can be summarized as follows.

Moreover, whenever the agent or the component NFT is referenced in a useful

3.2 How and when is the bonding mechanism incentivized?

Another source of the protocol’s capital, as mentioned in Section 2.3, is provided

Specifically, a control mechanism is introduced to ensure that the growth of

3.3 Incentive compatibility

Service owner perspective. Continuous staking of newly developed or well-

DAO members perspective. Autonolas DAO is composed of veOLAS holders

3.4 Ecosystem Flywheel

Autonolas provides a token-mediated coordination mechanism for the creation,

Fig. 3. Ecosystem flywheel

4 OLAS Inflation Schedule

Technically, the inflation schedule can be described by means of the following

5 Tokenomics Mathematical Model

5.1 Definition of the Contribution Measures for Usefulness of Code

Usefulness of Code in Terms of Donations: Component Case Let c ∈

Usefulness of Code in Terms of Donations: Agent Case An agent is

U CFa (e) = 0. (4)

Hence, also U F Ca can be seen as the relative contribution of an agent in an

The following observation is an immediate consequence of the U CFc and

0 ≤ U CFx (e) ≤1, ∀x ∈ X, ∀e.

A crucial requirement for using these measures in our tokenomics model is

5.2 Incentives for staked code NFTs

As described in the Section 2.1, Autonolas tokenomics aims to incentivise useful

where citcsij citasji are the values introduced in Definition 3.

This reward allocation demonstrates incentive compatibility in the following

Let sj be a whitelisted service and rj the respective donation accrued

TopUpcomp (e) X citcsij (e)rj

TopUpagents (e) X citasji (e)rj

considerably large incentive in registering services and making donations. This

5.3 Bonding: Discount Factor, Production Function, and Direct

ubp (t) = (1 + ϵ(t))bp (t).

Production Function In order to pair code and capital, it is necessary to

• k is the number of developers that can be paid per unit of

By units of valuable code we mean either nc components or na agents. Currently,

EM B(e) := M B(e) + Excess(e − 1)

We define the bonding rate, BR(t), as follows:

BR(t) := 1 − X(t, e)/EM B(e)

Direct Control Factor Finally, everything is combined together in a direct

Additionally, Autonolas tokenomics proposes several metrics to evaluate the

be found in the Appendix (see in particular Propositions 1, 2). These metrics

A Properties of Autonolas Tokenomics measures