Passionate about what the future operating system of the world will look like
Share Dialog
Share Dialog
Passionate about what the future operating system of the world will look like
Subscribe to CuriousRabbit.eth
Subscribe to CuriousRabbit.eth
<100 subscribers
<100 subscribers
In the words of Charlie Munger, "Show me the incentive and I'll show you the outcome." This insight is particularly relevant in the world of blockchain and Web3, where we're exploring novel ways to motivate and direct human behavior by using digital tokens as tools to create, capture and share value. Many projects in this space rely on straightforward, fixed plans for how these tokens are 'emitted' however this lack of flexibility can lead to unsustainable economics in the face of fluctuating adoption and market conditions. To promote longevity of these new digital ecosystems, it's becoming clear that we need to refine how these tokens are distributed. A key part of this solution lies in dynamic, adaptive systems known as KPI-based emission controllers.
The challenge lies in finding the right balance: How can we release enough tokens to keep our digital ecosystem active and incentivized, without issuing so many that they lose their value?
One possible answer is KPI-based emission controllers. Imagine a system where the release of tokens is adjusted in real-time, much like how a thermostat controls a room's temperature. These adjustments are based on Key Performance Indicators (KPIs) - measurable values that reflect how well a project is doing. By aligning token release with these KPIs, we can create a system that responds flexibly to the market's needs, ensuring a healthy balance between supply and demand.
Our strategy for managing token emissions is going to evolve from a 'set and forget' model to a more dynamic and responsive system. Instead of relying on predetermined schedules that dictate when tokens are released, we're moving towards a system that allows for adjustments in real time. This shift aims to achieve several key objectives: improving the efficiency of how tokens are managed, ensuring the long-term sustainability of the token economy, making the system more resilient to market changes, and ultimately, helping maintain a stable and appreciating value for the token.
The real challenge isn't in understanding these concepts but in building and implementing them effectively - that's the 'elephant in the room.' This article is here to tackle that challenge head-on. So, get ready: we're about to embark on a detailed journey into the creation and application of KPI-based token emission controllers.
Before diving deeper, lets define our primary objective: What exactly are we trying to achieve with KPI-based emission controllers?
Success can look different for various projects, but for the purpose of this discussion, let's focus on a universal goal.
Our Mission: To foster ECOSYSTEM GROWTH by developping a KPI-based controller that promotes sustainable price appreciation for our tokens and encourages economic activity.
While this broad goal is a good starting point, it's important to remember that for any project, the definition of success should be clear, specific, and directly linked to the project's overall objectives. Ideally, this should include precise, measurable targets that align with the strategic direction of the project.
Identifying the right Key Performance Indicators (KPIs) is crucial. These are the metrics that act like the heartbeat of our project, indicating its health and progress. KPIs can be data points directly from the blockchain (on-chain) or external data (off-chain).
Finding the right KPI’s can be confusing at first, so here is a simple exercise to help us overcome inertia.
Gather Our Team:
Bring together our key project members for a brainstorming session.
Use a collaborative tool like Miro for easy idea sharing and discussion.
Idea Generation:
List all potential KPIs that could be relevant to our project. Encourage out-of-the-box thinking in this phase.
Organizing KPIs:
Structure our KPIs in a hierarchy. Link each KPI to another to show cause and effect, using a pyramid structure where lower level KPIs are means to higher KPI’s.
For instance, increased referrals might lead to more new users, which then result in higher daily active users. Here, daily active users would be at the top of our pyramid.
Refinement for Practicality:
Review our KPIs, considering how feasible they are to track and any specific constraints our project might have.
Analyzing the KPI Pyramid:
Study the completed KPI pyramid to pinpoint the key 'driver' KPIs at the top and the supportive ones below. This process helps us understand the direct and indirect factors influencing our core KPIs.
In the realm of system design, there's a common pitfall known as "Seeking the wrong goal." This essentially means that if we optimize our system for the wrong objectives, we’ll end up with results that don't match our intentions. This principle is crucial to keep in mind when selecting KPIs for our token emission controller. The KPIs we choose may become the target our system strives to hit. Therefore, it's vital to pick KPIs that genuinely reflect our business goals to avoid unintended consequences or, as we might say, being left with a problem instead of a solution.
Brainstorming the right KPIs is just the beginning and there are several other factors we must consider. These include potential security risks ('attack vectors'), legal implications concerning the data we utilize, the pros and cons of centralized versus decentralized implementations and more. Let's delve into these complexities.
When incorporating KPIs into our token emission system, attack vectors becomes a crucial concern. For instance, if we choose a metric like Unique Active Wallets to guide our token distribution, we risk what's known as Sybil Attacks. In such a scenario, a single user could create multiple fake accounts to unfairly gain more tokens. This risk escalates with the number of KPIs we include in our system - more KPIs can mean a larger 'attack surface' for potential exploitation. It's essential to adopt a defensive strategy, anticipating and guarding against such vulnerabilities from the outset. For a deeper understanding of this defensive, or 'adversarial', approach, consider exploring further resources on the subject. Here’s an article we’ve co-authored that delves into Adversarial Thinking.
What if we could customize KPI-Based Controllers to meet the unique requirements of different groups within our ecosystem?
Envision a controller that incentivizes investors by aligning their token vesting with market price movements. Now, contrast that with a different controller designed to align community vesting based on the growth of KYC’ed users. This approach begins to further finetune our token distribution by acknowledging and catering to the varied motivations of different participants in the ecosystem.
This concept has the potential to transform how we think about incentives and motivate the behaviour of specific stakeholders in our system. As infrastructure advancements make it easier to develop and implement these tailored systems, this will become a reality.
Legal considerations play a significant role in the implementation of KPI-based token emissions.
Riddle me this? What is the extent of control a company has over the token in a KPI based emissions controller? The short answer is, “it depend.”
Imagine a scenario where a project uses data from its internal database to influence the emissions controller. The company may have significant control over the token vesting stepping into a territory rich in legal nuances.
To navigate this legal labyrinth, strategies like using publicly available blockchain data, mixing different types of KPI sources, and maintaining transparent data records can be helpful. Legal considerations will be integral to our system's design and operation so it’ll be important to get expert legal advice on these matters.
Let's tackle a tricky question: How do we efficiently use data that's already on the blockchain (on-chain data) in our KPI model?
Surprisingly (or not), using on-chain data isn't as straightforward as it seems. The blockchain is not inherently easy to read and pull data from. Third party data providers like Dune, Flipside, Token Terminal, Artemis and more have tackled this problem by providing UIs and API’s for organized on-chain information. However this data is now off-chain and if we wanted to use it to update the state of a KPI based Emissions Controller we would need to push that “on-chain” data back on-chain.
Exceptions exist such as Uniswap Time Weighted Oracles. When we launch a uniswap pool, we decide the length of the array that will store its price action within the smart contract of the pool. This creates a built-in oracle for each uniswap pool that could be called to update a KPI Based Emission Controller.
So how do we use on-chain data, from an on-chain source? The answer is embed it within the smart contract as a callable variable from the outset. Sophistication does come at a price, literally, as enhanced data complexity in a smart contract means higher computational demands and costs but what other options do we have? We’ll say hello to my little friend ORACLES.
Oracles play a unique and critical role in the Web3 ecosystem, acting as a bridge for on-chain or off-chain data.
The design of an Oracle – whether it's centralized or decentralized – hinges on who holds the authority to update it. Decentralized Oracles, offered by services like Chainlink, Gelato, UMA, and Keepers Network, are managed by multiple participants, which can add a layer of security and trust. In contrast, a centralized Oracle is under the control of a single authority, which might simplify operations but can also introduce central points of failure.
Oracles will moost likely be responsible relaying the vital KPI data to your controller. So you want to understand your options and their trade-offs. .
What should we consider when deciding whether to opt for a decentralized or centralized approach to our KPI-based emission system?
A system's level of decentralization is only as strong as its most centralized point, specifically the cost to attack that point. If our project is already built on a centralized platform, decentralizing our KPI Based Emissions controller may not necessarily bring additional value. If we’re using a centrally managed KPI within a system that also employs decentralized elements, like oracles, the central component could undermine the overall decentralization.
Take, for instance, a Web3 game developed on centralized infrastructure like AWS servers and Unity. Here, a centralized KPI controller could be more efficient, processing data off-chain in a secure server environment before updating the blockchain via a centralized oracle.
On the flip side, if the benefits of decentralization or trustlessness aligns with our project's goals and architecture, embedding the controller's logic directly onto the blockchain as a smart contract might be the way to go. This approach makes the KPI business logic transparent and verifiable by anyone. So what’s the answer? Well “it depends.” Each project will have to find the right balance that aligns with their project's objectives, technical architecture, community sentiment and the legal guidance they receive.
The Inverter Network is at the forefront of simplifying the implementation of KPI-based reward systems. Their modular approach allows for the creation of customizable processes. They’ve recently built the oStake module. This module is an innovative solution that employs an oracle-based contract to dynamically adjust staking rewards according to specific KPIs. These KPIs can be updated regularly, facilitating a responsive system that evolves with user behavior. The Inverter Network's platform is particularly exciting as it offers a streamlined and cost-effective solution for integrating complex KPI-based systems, which could otherwise be daunting for individual projects to develop independently.
To better understand how KPI-based emission controllers are applied in real-world scenarios, examining existing projects that have successfully deployed them can be immensely insightful. Here are some notable examples:
RAI: Employed a PI controller.
Algorand: Has implemented a controller using token price as the primary KPI.
Filecoin: Combines time-based and network capacity indicators for their FIL token emissions. More details can be found in their Baseline Minting explanation.
Clip Finance: Link their token emissions to achieving certain milestones in Total Value Locked (TVL).
Security Measures:
Integrate strong limits within the system to prevent misuse and have a plan to quickly shut down the system in case of a security breach.
Architectural Choices:
Decide whether a centralized or decentralized approach is more suitable for your project, weighing the costs and benefits of each. Start with flexible, upgradable smart contracts that can be refined over time with human intervention and consider transitioning to fixed contracts after thorough battlefield testing.
Vesting Control:
Determine the custodian of the vesting contracts. One solution is to use a 3rd party provider (like Liquifi), who vests the the tokens to a seperate smart contract that the controller is in charge of. This would prevent the vesting contract that that is controlled by the controller from being a FAT target for hackers. In this case the majority of tokens will be held within a vetted contract and intermittently send the tokens to another contract that is managed by the controller.
Selecting the Right KPIs:
Choose KPIs that accurately reflect the activity and demand on your platform, and be mindful of how they might be manipulated.
Adversarial Thinking:
Any exploitable loophole will be targeted if its profitable. Be aware of the potential for exploitation in the competitive blockchain space and prepare accordingly.
Testing and Modeling:
Thoroughly test and model our system before launch using tools like Machinations, cadCAD, or radCAD.
Legal Aspects:
Understand the legal implications of how we set up our KPI system, especially regarding control over tokens.
Blockscience has a great article that discusses controllers briefly **Engineering Economic Systems.**
Jack Chong of Oxford, released a paper The Three Tokenomics Problems and a Productivity-Linked Tokenomics Design, which provides an iteresting implementation of a KPI based controller.
Erman Gültekin has recently released on article Dynamic Token Distribution in Web3 Game Ecosystems.
Outlier Ventures released a foundational article on the matter in Adoption Adjusted Vesting supported by a great video between Kris P of TE Labs & Achim Struve.
If you’re looking for help designing your Token System, you can reach out to us @HLV_xyz
A big shout out to all of the individuals who shared their insights during the creation of this article. Achim Struve of Outlier Ventures, Mr. Octopus my dear friend, Daniel Gretzke of Polygon Labs, Ataberk Casur from Inverter, Marco Germanier , Roderick McKinley, Maurizio Binello of HLV, Don & Allan of Nueva.Tech. As well as the many other people i am constantly learning from.
None of this is financial or legal advice. These opinions are purely the opinion of Curious Rabbit. This is all just my curious ramblings as i learn out loud along my journey to build the next operating system for the world.
In the words of Charlie Munger, "Show me the incentive and I'll show you the outcome." This insight is particularly relevant in the world of blockchain and Web3, where we're exploring novel ways to motivate and direct human behavior by using digital tokens as tools to create, capture and share value. Many projects in this space rely on straightforward, fixed plans for how these tokens are 'emitted' however this lack of flexibility can lead to unsustainable economics in the face of fluctuating adoption and market conditions. To promote longevity of these new digital ecosystems, it's becoming clear that we need to refine how these tokens are distributed. A key part of this solution lies in dynamic, adaptive systems known as KPI-based emission controllers.
The challenge lies in finding the right balance: How can we release enough tokens to keep our digital ecosystem active and incentivized, without issuing so many that they lose their value?
One possible answer is KPI-based emission controllers. Imagine a system where the release of tokens is adjusted in real-time, much like how a thermostat controls a room's temperature. These adjustments are based on Key Performance Indicators (KPIs) - measurable values that reflect how well a project is doing. By aligning token release with these KPIs, we can create a system that responds flexibly to the market's needs, ensuring a healthy balance between supply and demand.
Our strategy for managing token emissions is going to evolve from a 'set and forget' model to a more dynamic and responsive system. Instead of relying on predetermined schedules that dictate when tokens are released, we're moving towards a system that allows for adjustments in real time. This shift aims to achieve several key objectives: improving the efficiency of how tokens are managed, ensuring the long-term sustainability of the token economy, making the system more resilient to market changes, and ultimately, helping maintain a stable and appreciating value for the token.
The real challenge isn't in understanding these concepts but in building and implementing them effectively - that's the 'elephant in the room.' This article is here to tackle that challenge head-on. So, get ready: we're about to embark on a detailed journey into the creation and application of KPI-based token emission controllers.
Before diving deeper, lets define our primary objective: What exactly are we trying to achieve with KPI-based emission controllers?
Success can look different for various projects, but for the purpose of this discussion, let's focus on a universal goal.
Our Mission: To foster ECOSYSTEM GROWTH by developping a KPI-based controller that promotes sustainable price appreciation for our tokens and encourages economic activity.
While this broad goal is a good starting point, it's important to remember that for any project, the definition of success should be clear, specific, and directly linked to the project's overall objectives. Ideally, this should include precise, measurable targets that align with the strategic direction of the project.
Identifying the right Key Performance Indicators (KPIs) is crucial. These are the metrics that act like the heartbeat of our project, indicating its health and progress. KPIs can be data points directly from the blockchain (on-chain) or external data (off-chain).
Finding the right KPI’s can be confusing at first, so here is a simple exercise to help us overcome inertia.
Gather Our Team:
Bring together our key project members for a brainstorming session.
Use a collaborative tool like Miro for easy idea sharing and discussion.
Idea Generation:
List all potential KPIs that could be relevant to our project. Encourage out-of-the-box thinking in this phase.
Organizing KPIs:
Structure our KPIs in a hierarchy. Link each KPI to another to show cause and effect, using a pyramid structure where lower level KPIs are means to higher KPI’s.
For instance, increased referrals might lead to more new users, which then result in higher daily active users. Here, daily active users would be at the top of our pyramid.
Refinement for Practicality:
Review our KPIs, considering how feasible they are to track and any specific constraints our project might have.
Analyzing the KPI Pyramid:
Study the completed KPI pyramid to pinpoint the key 'driver' KPIs at the top and the supportive ones below. This process helps us understand the direct and indirect factors influencing our core KPIs.
In the realm of system design, there's a common pitfall known as "Seeking the wrong goal." This essentially means that if we optimize our system for the wrong objectives, we’ll end up with results that don't match our intentions. This principle is crucial to keep in mind when selecting KPIs for our token emission controller. The KPIs we choose may become the target our system strives to hit. Therefore, it's vital to pick KPIs that genuinely reflect our business goals to avoid unintended consequences or, as we might say, being left with a problem instead of a solution.
Brainstorming the right KPIs is just the beginning and there are several other factors we must consider. These include potential security risks ('attack vectors'), legal implications concerning the data we utilize, the pros and cons of centralized versus decentralized implementations and more. Let's delve into these complexities.
When incorporating KPIs into our token emission system, attack vectors becomes a crucial concern. For instance, if we choose a metric like Unique Active Wallets to guide our token distribution, we risk what's known as Sybil Attacks. In such a scenario, a single user could create multiple fake accounts to unfairly gain more tokens. This risk escalates with the number of KPIs we include in our system - more KPIs can mean a larger 'attack surface' for potential exploitation. It's essential to adopt a defensive strategy, anticipating and guarding against such vulnerabilities from the outset. For a deeper understanding of this defensive, or 'adversarial', approach, consider exploring further resources on the subject. Here’s an article we’ve co-authored that delves into Adversarial Thinking.
What if we could customize KPI-Based Controllers to meet the unique requirements of different groups within our ecosystem?
Envision a controller that incentivizes investors by aligning their token vesting with market price movements. Now, contrast that with a different controller designed to align community vesting based on the growth of KYC’ed users. This approach begins to further finetune our token distribution by acknowledging and catering to the varied motivations of different participants in the ecosystem.
This concept has the potential to transform how we think about incentives and motivate the behaviour of specific stakeholders in our system. As infrastructure advancements make it easier to develop and implement these tailored systems, this will become a reality.
Legal considerations play a significant role in the implementation of KPI-based token emissions.
Riddle me this? What is the extent of control a company has over the token in a KPI based emissions controller? The short answer is, “it depend.”
Imagine a scenario where a project uses data from its internal database to influence the emissions controller. The company may have significant control over the token vesting stepping into a territory rich in legal nuances.
To navigate this legal labyrinth, strategies like using publicly available blockchain data, mixing different types of KPI sources, and maintaining transparent data records can be helpful. Legal considerations will be integral to our system's design and operation so it’ll be important to get expert legal advice on these matters.
Let's tackle a tricky question: How do we efficiently use data that's already on the blockchain (on-chain data) in our KPI model?
Surprisingly (or not), using on-chain data isn't as straightforward as it seems. The blockchain is not inherently easy to read and pull data from. Third party data providers like Dune, Flipside, Token Terminal, Artemis and more have tackled this problem by providing UIs and API’s for organized on-chain information. However this data is now off-chain and if we wanted to use it to update the state of a KPI based Emissions Controller we would need to push that “on-chain” data back on-chain.
Exceptions exist such as Uniswap Time Weighted Oracles. When we launch a uniswap pool, we decide the length of the array that will store its price action within the smart contract of the pool. This creates a built-in oracle for each uniswap pool that could be called to update a KPI Based Emission Controller.
So how do we use on-chain data, from an on-chain source? The answer is embed it within the smart contract as a callable variable from the outset. Sophistication does come at a price, literally, as enhanced data complexity in a smart contract means higher computational demands and costs but what other options do we have? We’ll say hello to my little friend ORACLES.
Oracles play a unique and critical role in the Web3 ecosystem, acting as a bridge for on-chain or off-chain data.
The design of an Oracle – whether it's centralized or decentralized – hinges on who holds the authority to update it. Decentralized Oracles, offered by services like Chainlink, Gelato, UMA, and Keepers Network, are managed by multiple participants, which can add a layer of security and trust. In contrast, a centralized Oracle is under the control of a single authority, which might simplify operations but can also introduce central points of failure.
Oracles will moost likely be responsible relaying the vital KPI data to your controller. So you want to understand your options and their trade-offs. .
What should we consider when deciding whether to opt for a decentralized or centralized approach to our KPI-based emission system?
A system's level of decentralization is only as strong as its most centralized point, specifically the cost to attack that point. If our project is already built on a centralized platform, decentralizing our KPI Based Emissions controller may not necessarily bring additional value. If we’re using a centrally managed KPI within a system that also employs decentralized elements, like oracles, the central component could undermine the overall decentralization.
Take, for instance, a Web3 game developed on centralized infrastructure like AWS servers and Unity. Here, a centralized KPI controller could be more efficient, processing data off-chain in a secure server environment before updating the blockchain via a centralized oracle.
On the flip side, if the benefits of decentralization or trustlessness aligns with our project's goals and architecture, embedding the controller's logic directly onto the blockchain as a smart contract might be the way to go. This approach makes the KPI business logic transparent and verifiable by anyone. So what’s the answer? Well “it depends.” Each project will have to find the right balance that aligns with their project's objectives, technical architecture, community sentiment and the legal guidance they receive.
The Inverter Network is at the forefront of simplifying the implementation of KPI-based reward systems. Their modular approach allows for the creation of customizable processes. They’ve recently built the oStake module. This module is an innovative solution that employs an oracle-based contract to dynamically adjust staking rewards according to specific KPIs. These KPIs can be updated regularly, facilitating a responsive system that evolves with user behavior. The Inverter Network's platform is particularly exciting as it offers a streamlined and cost-effective solution for integrating complex KPI-based systems, which could otherwise be daunting for individual projects to develop independently.
To better understand how KPI-based emission controllers are applied in real-world scenarios, examining existing projects that have successfully deployed them can be immensely insightful. Here are some notable examples:
RAI: Employed a PI controller.
Algorand: Has implemented a controller using token price as the primary KPI.
Filecoin: Combines time-based and network capacity indicators for their FIL token emissions. More details can be found in their Baseline Minting explanation.
Clip Finance: Link their token emissions to achieving certain milestones in Total Value Locked (TVL).
Security Measures:
Integrate strong limits within the system to prevent misuse and have a plan to quickly shut down the system in case of a security breach.
Architectural Choices:
Decide whether a centralized or decentralized approach is more suitable for your project, weighing the costs and benefits of each. Start with flexible, upgradable smart contracts that can be refined over time with human intervention and consider transitioning to fixed contracts after thorough battlefield testing.
Vesting Control:
Determine the custodian of the vesting contracts. One solution is to use a 3rd party provider (like Liquifi), who vests the the tokens to a seperate smart contract that the controller is in charge of. This would prevent the vesting contract that that is controlled by the controller from being a FAT target for hackers. In this case the majority of tokens will be held within a vetted contract and intermittently send the tokens to another contract that is managed by the controller.
Selecting the Right KPIs:
Choose KPIs that accurately reflect the activity and demand on your platform, and be mindful of how they might be manipulated.
Adversarial Thinking:
Any exploitable loophole will be targeted if its profitable. Be aware of the potential for exploitation in the competitive blockchain space and prepare accordingly.
Testing and Modeling:
Thoroughly test and model our system before launch using tools like Machinations, cadCAD, or radCAD.
Legal Aspects:
Understand the legal implications of how we set up our KPI system, especially regarding control over tokens.
Blockscience has a great article that discusses controllers briefly **Engineering Economic Systems.**
Jack Chong of Oxford, released a paper The Three Tokenomics Problems and a Productivity-Linked Tokenomics Design, which provides an iteresting implementation of a KPI based controller.
Erman Gültekin has recently released on article Dynamic Token Distribution in Web3 Game Ecosystems.
Outlier Ventures released a foundational article on the matter in Adoption Adjusted Vesting supported by a great video between Kris P of TE Labs & Achim Struve.
If you’re looking for help designing your Token System, you can reach out to us @HLV_xyz
A big shout out to all of the individuals who shared their insights during the creation of this article. Achim Struve of Outlier Ventures, Mr. Octopus my dear friend, Daniel Gretzke of Polygon Labs, Ataberk Casur from Inverter, Marco Germanier , Roderick McKinley, Maurizio Binello of HLV, Don & Allan of Nueva.Tech. As well as the many other people i am constantly learning from.
None of this is financial or legal advice. These opinions are purely the opinion of Curious Rabbit. This is all just my curious ramblings as i learn out loud along my journey to build the next operating system for the world.
No activity yet