The Open Rights Exchange (ORE) Whitepaper, Enabling the First API Marketplace on the Blockchain
Authors: Stefan Roever, Marc Blinder, Tray Lewin, Gretchen Fox, R. Alex Stokes, Wayne Chang
APIs, also known as Application Programming Interfaces, are becoming increasingly essential to the success of business operations. As the API ecosystem evolves, more and more software functionality is now accessible in the form of APIs. Some APIs may be free and available for anybody to use, but a growing share of higher value APIs are now offered commercially and require sophisticated access controls as well as some form of payment - the API economy is already estimated to be $2.2 trillion and growing.
Providing commercial APIs can be complex. Managing access control, handling payments and maintaining operational quality is a challenge for many API developers. Oftentimes addressing these issues requires more effort and resources than developing the core API functionality.
As a result, much potential API functionality never makes it to market, limiting developer’s choices. And even if useful APIs are available, integrating them into applications and managing payments is often cumbersome.
AIKON (pronounced “icon”) solves these problems by introducing an API rights protocol called Open Rights Exchange (ORE), which offloads the burden of API access control, API validation, and API payments to a shared infrastructure built on blockchain technology - the ORE network.
The ORE protocol is the underpinning technology for AIKON's end-to-end API marketplace that makes it easy for API providers to sell their APIs and for API consumers to discover, buy, and use them.
Open Rights Exchange
Large Market with Even More Upside
Modern software is almost always developed using software building blocks accessible via application programming interfaces (APIs). Most of these APIs are consumed internally within the enterprise, locked behind walled gardens, yet many of them could provide tremendous value if made available directly to business partners and customers.
In the 21st century, externally available, commercial APIs are playing an increasingly important role in almost all businesses. In fact, 80% of large enterprises are already making over $5 million dollars a year in revenue from APIs. The aggregate value of all transactions processed via APIs is estimated to reach $2.2 trillion in 2018, which is roughly equivalent to the size of the global e-commerce market.
While some APIs may be available for anybody to use, most will require sophisticated access controls. And an increasing share of APIs will be offered commercially and require some form of payment. As friction to provide and consume commercial APIs is reduced, more developers will be able to participate in the API economy. As the number of internet connected devices continues to explode, market forces are driving devices, systems, and commercial assets to become externally accessible via API’s, and increasingly, newly developed functionality will be made available via APIs first.
API Market Obstacles
While the trend towards APIs is strong and growing, numerous organizational barriers and technical complexities remain for those wishing to innovate, collaborate and prosper in the API economy. Commercial API providers in particular need to address complicated issues around managing access control and payments. API consumers in turn need to deal with the resulting interface complexities. Some of these challenges are more difficult for individual developers and start-ups to overcome, others also affect established enterprises. In all cases, productivity is hampered, critical time and resources are wasted, and progress and collaboration on a “flatter planet” are hindered.
API Provider Hurdles
Let’s take the example of a small Mexican university team of software engineers and medical experts who have developed a best-in-class AI for identifying cancer in medical scans, which they want to make available to third-party diagnostic software providers for integration into larger suites of services. Monetization could be on a subscription basis and/or on a pay-per-call basis.
In order to offer this service, the team not only needs to train, deploy and maintain the AI, it needs to also develop an entire business infrastructure (sales portal, billing, reporting, etc.). The API itself needs to have access to tables of user IDs, passwords, access control lists, and transaction records to authenticate the caller, determine whether or not he or she is authorized to make the call and to maintain a transaction log. These requirements alone mean that the API needs to maintain state in a high-availability database, even though the core AI functionality only could likely run statelessly with minimal infrastructure. The team needs to procure high-quality cloud hosting capacity and access to several third-party API services such as payment processing and email delivery. All these services, in turn, need to be paid for via credit card, so a bank account is required and therefore a company needs to be incorporated, lawyers paid and investors found to cover the start-up costs. This list of obstacles could be continued ad nauseam. Individually none of these may be insurmountable, but together they can quickly add up to an unacceptable level of effort, where the commercialization requirements far outweigh the core product complexity. Consequently, our team of Mexican developers and medical experts might well decide that the commercial risks and required efforts are not worth the potential reward.
API Consumer Hurdles
On the flip side, potential API consumers also face significant obstacles. In the above example, a company offering a diagnostic software suite and looking to accelerate product development might benefit from using third-party APIs for multiple elements of the complete solution.
But many of the components that could potentially be integrated via APIs might not even be available due to the difficulties faced by API providers, as described above. So the software company may resort to developing this in-house at a greater expense or not offer the functionality at all. Even if the functionality does exist and is provided via API, questions may remain about the quality of the service, uptime, privacy, security, etc. Finding the right API may already be a challenge, but even once the APIs have been selected, tested, and integrated, managing the commercial aspects of the relationship requires serious efforts. Different accounts need to be maintained and paid for, often with different terms and conditions, payment models, and currencies. This creates similar challenges to those faced by the API provider with respect to currency risks and temporal mismatches between revenue flow and API related payment obligations. Various parts of the consuming software application need to store credentials in multiple locations securely for accessing the APIs. These credentials may need to be updated on a regular basis, as passwords change and contracts are renewed, creating a security and administrative nightmare. These challenges, as well as concerns about API quality and reliability, can often cause a company to fall back on in-house development, leaving opportunities for cost savings and faster time to market unrealized.
To dramatically simplify providing and consuming any kind of API and to allow anyone to participate in the API economy, we introduce the Open Rights Exchange (ORE) protocol.
The ORE protocol specifies how API access control, validation, and payment can be provided by a shared infrastructure, called the ORE network, built on blockchain technology and jointly operated and governed by a community of stakeholders. This allows API providers to focus on building core API functionality instead of spending a lot of effort on the administrative and commercial framework and makes it easy for API consumers to use and pay for APIs. The ORE protocol also defines how the operators of the ORE network, the ORE miners, can be rewarded fairly for the value they provide.
The Open Rights Exchange protocol is an open source project that’s free to use. The latest information and documentation is always available on Github here:
Our goal is to make using the protocol as easy as possible. Please submit questions, feedback or pull requests on Github.
Immutable Rights Objects
The foundational elements of the ORE protocol are immutable rights objects called ORE instruments. They encode the holder’s right to perform some actions subject to some terms and conditions. The generality of this definition captures the breadth of our ambition with respect to what sorts of rights may be described in this framework. A right consists of the ability to make a request to an API endpoint. A typical condition would require payment in some cryptocurrency in order to access an endpoint. ORE instruments are in part named to reflect their similar characteristics to the “bearer-based instruments” commonly found in traditional finance, namely the principle that the rights expressed in the instrument can be exercised by the holder, or “bearer”, on presentation of the instrument without the need to authenticate that individual or entity, so long as the instrument itself is authentic.
ORE instruments are permanently stored on the blockchain in form of smart contracts. For this purpose, the ORE protocol defines a universal registry called ORE rights chain in which ORE instruments are linked to individual holders using standard cryptographic methods. Once issued and written to the ORE rights chain, ORE instruments are immutable. This is important because they represent a promise by the API provider to the API consumer.
Using this approach we now have a way to map any off-chain asset to the blockchain via APIs. An asset can be thought of as the sum of its associated rights. These are expressed in the ORE instrument and represented via performable actions in form of API endpoints (often using an HTTP REST format). For example, if the asset is an Intel share, the rights and actions might be to cast a shareholder vote, to download the annual report and to receive a dividend. Each of these actions can be associated with an API endpoint. If the asset is a particular song, the rights and actions might be to stream the song, to download it in high quality and to view the lyrics. Each of these again corresponds to a specific API endpoint, expressed as a programmatic protocol with an address (e.g. HTTP plus URL or IPFS, etc.).
Unifying On-Chain and Off-Chain Interactions
This is a very powerful model. Any economic interaction can be understood as transactions involving assets and liabilities, and their corresponding rights and obligations. For example, when someone exercises a share option, rights to the underlying assets are exchanged, such as the voting rights and dividend rights associated with the shares. These rights, in turn, correspond to company obligations and associated liabilities.
Our central thesis is that economic activity can be represented in the virtual world as operations on assets and rights associated with API endpoints. Using ORE instruments and the broader ORE protocol, together with new smart contract technology, we can now mirror any of these interactions as operations on the blockchain. ORE instruments act as the key that unlocks the API endpoints for the holder of the instrument.
For example, if an API consumer buys a subscription to some API services, he or she would receive an ORE instrument in the form of an API voucher, which expresses his rights to access the corresponding API endpoints. If an investor bought an Intel share, he or she would receive a different kind of ORE instrument which acts as a digital share certificate. The rights expressed in that instrument would correspond to API endpoints for casting a shareholder vote or downloading the shareholder report. For an online movie purchase, the corresponding ORE instrument would have download and streaming rights, each associated with API endpoints. In this manner, any off-chain asset can be mapped to the blockchain and be stored, traded, or transferred. Each ORE instrument controls access to specific API endpoints that bridge the gap between the on-chain and off-chain world.
Capabilities-based Security Model
The ORE protocol uses a distributed capability-based access control paradigm, where every API consumer holds its own access rights (or capabilities) rather than the traditional model of using access control lists managed by the API provider.
This decentralized approach to implementing access control is not new. It has on previous occasions been proposed in the literature by multiple groups to standardize access negotiation . As a result, users enjoy dramatically improved security as the API providers do not need to maintain records of user IDs, passwords, and access control lists, so there are fewer attack vectors when compared to traditional web applications. It also has numerous other advantages over traditional authorization models, including better traceability, better support for delegation and simpler management. However, it has been difficult to implement. The emergence and adoption of decentralized blockchain technology now reduce costs enough for Open Rights Exchange to support this superior security model.
Participants in the ORE network need to be able to exchange value. As explained, the ORE protocol makes it easy to transfer any asset, including for payment in fiat and cryptocurrencies. However, existing currencies suffer from several shortcomings. Many currencies experience high volatility, making it difficult to correctly price offerings, especially those dependent on other services as input. With currency risk, providers are more likely to involuntarily overcharge and risk the loss of business, or undercharge and lose money on every transaction. Fiat currencies, on the other hand, suffer from their own problems, which include cumbersome regulatory requirements as well as the need for bank accounts, credit cards, merchant accounts, etc., access to which may be out of reach for many market participants. These are not just hypothetical issues - software companies in developing countries often have a very hard time accessing commercial APIs hosted in the US or Europe, severely undercutting their competitive edge.
Given the broad applicability of Open Rights Exchange to any type of commercial transaction, we have an opportunity to establish a completely new payment instrument as part of the ORE protocol. We do this in form of a stable coin called CPU, or Cloud Processing Unit. It’s a currency backed by cloud compute processing power, meaning that every unit of CPU entitles the holder to a specific amount of compute power. The required compute reserves are provided to the network by a loose association of hosting partners. The ORE protocol provides an incentive scheme for hosting partners to act as decentralized reserve providers. The net effect of this is that we can establish a low volatility payment instrument in the market, backed by a resource (compute power) that every market participant needs.
Rights Management and Asset Monetization
Open Rights Exchange is a network that allows participants to offload the burden of managing access rights to assets and handling the associated payments to a decentralized infrastructure, operated and governed by the ORE community. To meet these objectives, we require a core set of network features.
Open Rights Exchange provides a universal, decentralized registry called the ORE rights chain in which ORE instruments are permanently stored and linked to individual holders using Ethereum as a trust anchor.
The ORE rights chain acts as an optimization layer on top of Ethereum that allows ORE instruments to be stored as detailed, specialized smart contracts while minimizing gas costs. Holders of ORE instruments can optionally retrieve a copy from the ORE rights chain when needed, by using their public key, or they can maintain their own copies. ORE instruments can be stored openly on the ORE rights chain, available for anyone to read, or in secretly hashed form.
This model of maintaining access control information is fundamentally different from the traditional model of having every API provider maintain their own records of user IDs, passwords, and access control lists. Because the ORE protocol is bearer-based, there is no need at all to store user IDs and passwords on any server. The multitude of separate access control lists are replaced with the ORE rights chain as a shared universal registry, creating huge economies of scale.
Whenever an ORE instrument holder wants to exercise any access right to an asset, Open Rights Exchange acts as a trusted arbiter, backed by the ORE network community, and verifies that the caller is indeed entitled to make the call by comparing the requested call to the rights specified in the instrument.
If the desired call and the expressed rights match up, a temporary cryptographic access token is issued, which the client then presents to the API endpoint that corresponds to the right. All the API provider needs to do then is validate the access token and process the call.
Assets are only as valuable as the rights associated with them are reliable. This is true for, say, a media asset, where one wants to know that a movie will be available for fast and high-quality streaming whenever desired. It’s also true for general API access, where one wants to be sure that the API functions will be delivered with low latency, high availability and high accuracy.
To help address API consumers’ concerns about quality and reliability, the Open Rights Exchange network can continuously monitor the API endpoints associated with the rights expressed in the ORE instruments and provides information about their availability, latency, etc.
API providers can additionally provide test suites for the Open Rights Exchange to run against the endpoints. These test suites and the corresponding test results provide a protocol level form of quality control of API endpoints on the Open Rights Exchange. They also effectively act as advertising for the APIs. The more competitive the market for any API category is, the more incentive an issuer will have to provide extensive test suites. If the asset is API access for example, then those APIs that have the highest test coverage and best results will be the most attractive to API consumers.
Over time we expect third-parties to provide additional quality assessments of APIs, for example regarding test coverage and quality of the results. In the Token Economics section of this paper, we discuss incentive structures to promote this behavior.
The ORE protocol enables flexible monetization models for APIs.
One approach is to sell API vouchers providing access to APIs using any conventional payment mechanism, such as credit card or cryptocurrencies. AIKON will be providing ORE-enabled API interfaces to third-party payment gateways on the API marketplace to facilitate these transactions.
The ORE protocol also provides an option to require additional payment every time a right is exercised. This enables pay-per-call models. This feature is built deep into the ORE protocol. API consumers can establish payment channels with ORE nodes that are used to transfer a small amount of CPU as payment every time an access token is requested. The API provider can collect the CPU payment from the ORE network whenever enough value has been accumulated to make a transfer worthwhile.
By providing CPU as a core feature of the ORE protocol, we have the opportunity to establish CPU as the de-facto clearing currency for micro-payments in the digital economy. Its decentral nature allows it to assume this integral function in the digital economy without AIKON or any other entity acting as a central bank. CPU’s high degree of fungibility, combined with low volatility, makes it ideal for pay-per-call transactions, for example when selling APIs.
The Open Rights Exchange network is decentralized, jointly operated and governed by the community. For some elements of its functionality, it relies on existing blockchain infrastructure, such as Ethereum which is used as a “trust anchor” for tracking possession of the tokens used by the ORE protocol.
For other functions, such as storing ORE instruments, the network relies on a loose association of independent ORE miners to operate ORE nodes by running the requisite software. ORE nodes communicate with each other and with the users of Open Rights Exchange via the open source ORE protocol. Together these nodes form the decentralized ORE network.
ORE instruments are the basic objects on the Open Rights Exchange. They are used to represent API vouchers as well as any other API accessible asset, such as financial instruments, like bonds or shares, digital media, electronic records, control of IoT devices, etc.
Assets are modeled as a collection of rights, bundled together in ORE instruments. Each right is linked to an API endpoint. Examples of rights and their corresponding APIS are “cast shareholder vote”, “download song”, “view patient file”, “turn up thermostat”, or “perform facial recognition”.
Blockchain technology is used to track possession of ORE instruments. Once on the blockchain, ORE instruments can be easily traded or transferred using standard blockchain tools such as public/private keys, cryptocurrencies or smart contracts.
ORE instruments are digital bearer instruments, meaning that they entitle the holder to exercise the rights expressed in them. The right is exercised by calling the associated API endpoint. They are stored permanently on the ORE rights chain and represent an immutable promise by the instrument issuer to the instrument holder.
The API provider only needs to verify that the ORE instrument is valid, a task which is performed with help of the ORE network. There is no need to authenticate the user, verify his or her password or maintain access control lists. This is called a capabilities-based security model. Because no database with user IDs and passwords and no access control lists are required, it’s very safe and easy to implement ORE enabled services. These services are inherently more secure than traditional services because no security information is stored, which produces fewer possible attack vectors.
API endpoints are the programmatic representation of rights. Typically they are implemented by combining a protocol with an address, such as an HTTP endpoint like
They are maintained and operated by the API provider. Consuming an asset by exercising a right associated with it always involves calling an API endpoint.
API endpoints are unlocked using access tokens obtained by the API consumer from the ORE network. This requires verification of the desired call against the rights expressed in the ORE instrument held by the caller. Sometimes, in pay-per-call scenarios, additional payment may be required to obtain the access token.
Dual Token Model
Open Rights Exchange utilizes a dual-token economic model - the ORE token is used to incentivize network participants to perform essential network functions, such as storing the ORE instruments on the ORE rights chain and verifying them before each use. ORE is also used to reward miners for validating that API endpoints perform as advertised. AIKON’s stable currency CPU, on the other hand, is intended to be used to pay for assets and designed for ease of use and minimal volatility. CPU helps reduce friction and risk for both API consumers and API providers, while ORE brings governance and network quality.
CPU is intended to become the de facto clearing currency for all API transactions. The token is designed to be highly fungible yet stable and is tied to the market price of cloud computing processing power. For API consumers, CPU is the only coin that they need to use. CPU is expected to grow slowly and predictably cheaper, as Bezos’s Law states that computing power will become less and less expensive over time. CPU is designed to allow API consumers and API providers to safely participate in the system without requiring an understanding of cryptocurrency or blockchain.
ORE is a token that ensures network quality by rewarding third-party miners for the storage, verification, and validation of the instruments used to operate the protocol. Unlike typical mining schemes which operate on a Proof-of-Work model, ORE miners check latency, availability and perform unit testing of API endpoints. We call this Proof-of-Function. There is a fixed amount of ORE created at the launch of the network. Its price is likely to change over time based on network usage. API consumers don’t need to understand or use ORE, however, API providers who want to use the Open Rights Exchange for making their assets available need to pay in ORE for rights storage, verification, and any desired validation of their offering to ensure the overall quality of the network.
The API Marketplace
Decentralized API Marketplace
Open Rights Exchange makes it very easy to create software building blocks and offer them for third-party consumption. On the API marketplace any API consumer will have a way to easily discover, assess, purchase, and access any ORE-enabled software building blocks. Conversely, API providers will be able to make their services visible and available to a broad audience, and can readily demonstrate the quality and reliability of their APIs.
The API marketplace acts as an interface to the decentralized ORE network, publishing information about APIs available on the network. API providers can engage with the API marketplace to create a commercial interface to their APIs, for example by setting prices and by advertising their APIs on the marketplace. API consumers can discover APIs, asses them and buy access via the marketplace. Most importantly, API developers benefit from a marketplace where all APIs will interoperate for easy API chaining and the creation of more complex applications.
While AIKON will offer the first API marketplace for ORE-enabled software building blocks, we may not be the exclusive provider of marketplace services. Open Rights Exchange is available to anybody, and competing API marketplaces, maybe for specialty domains such as economic modeling via AI or virtual biology, may well emerge on the network.
In a decentralized context, no single entity can act as a gatekeeper for the entry or usage of APIs in this new economy. Using the Open Rights Exchange, a multitude of microservices can be made available commercially via APIs. These, in turn, can be combined to deliver high-level functionality, which itself can be made available using the ORE protocol to form ever higher complexity services. Sophisticated applications are quickly developed and launched by chaining together APIs provided by many different participants at multiple levels in this ecosystem. Value is decentrally created and distributed instantaneously across the participating parties using CPU. This type of effortless API interaction would quickly yield novel emergent functionality, but real-world adoption has until recently impractical due to technical, organizational, legal and economic complexities.
Real World Example
Consider the case of a prediction engine for prices of liquified natural gas (LNG). This model might be accessible via API and charge its consumers a set fee per price prediction for a given time in the future. To produce these predictions, the model might use AI and deep learning, as well as proprietary algorithms and external data feeds, such as commodity prices, again provided via API. The model might also use APIs to consume input from third-party models, such as refinery utilization models, LNG carrier tracking services, storage facility and inventory models, consumer demand prediction models, etc. Some of these models, such as the demand model, might, in turn, need input from other services, such as weather models, maps, and traffic prediction models.
Once the LNG price prediction service is mature, it might itself be used as input to a higher level service, such as a stock recommendation engine for energy hedge funds. In theory, there is no limit to how many APIs can be chained together over many levels, often provided by different commercial entities.
While Open Rights Exchange’s shared ORE rights chain and real-time CPU payments help solve many of the technical and commercial complexities, some questions and open issues remain. Will all APIs be available when needed? Will they respond in a timely manner? How accurate is the information provided? These issues are harder to deal with when the overall system is assembled from multiple component services offered by different API providers, some of which may be pseudonymous and only identifiable via their cryptographic addresses.
To be successful the API marketplace must therefore not only address the issues of API access control and payment, but also deal with the curation of critical API attributes such as quality, service levels, response times, privacy etc.
Listing and Discovery
The API marketplace’s primary function is to act as an online portal where API providers can list their APIs and where API consumers can easily find them. The marketplace will provide the usual search functionality across multiple API attributes, as well as the ability to rate APIs.
API providers will be able to stake tokens to have their APIs featured more prominently.
API providers can use the API marketplace storefront functionality to sell API access in the form of API vouchers. Via a simple web interface, they can price their APIs using a variety of payment models, such as subscriptions, pre-pay, post-pay or pay-per-call. The storefront supports a broad range of payment mechanisms, such as credit card, bank transfers, payment using CPU, and other cryptocurrencies such as Bitcoin or ETH.
It is important to note that the API marketplace storefront and the actual API endpoints are very loosely coupled. The only connection between the two is via API vouchers on the Open Rights Exchange. API providers can, therefore, sell access to their APIs anywhere in the form of API vouchers, whether it is on API marketplace’s storefront, their own storefront or using a third-party seller.
The API marketplace will enable curation of quality APIs in multiple ways:
- The simplest and most familiar of these will be a rating and review system for APIs.
- Additionally, we can rely on the validation feature of the Open Rights Exchange Protocol, such as the work miners do to check up-time and latency of API endpoints. Also, Open Rights Exchange rewards miners for running test suites supplied by the API provider. Results are reported back and logged on the ORE rights chain, available for anyone to see.
- Finally, we expect further API assessment work to be performed by third-parties. These assessments could range from evaluating test coverage, checking APIs for accuracy, certifying privacy compliance like HIPAA, etc. The API marketplace needs to provide mechanisms and incentive schemes to allow this to happen, as explained further below in the Token Economics section of this white paper.
Developer Software Building Blocks
AIKON will provide its own suite of APIs to make foundational software building blocks available to developers, such as hosting, streaming, transcoding, etc.
These services will be available for sale on the API marketplace and will be accessible using the ORE protocol. Payment commonly will be on a per-call basis using CPU.
The purpose is to make it easier for developers to build applications and their own APIs on Open Rights Exchange, as well as to seed the market with popular APIs. By making these tools available via the ORE Protocol and using CPU, they can easily be chained together in accordance with our vision.
We will constantly monitor the marketplace for opportunities to create new APIs. Over time we expect some of the lower-level services to become commoditized and offered by third-parties, but there will always be a new need for higher value services at the top of the software stack.
Benefits to API Providers
- Simple API Monetization: The API marketplace makes it easy for API providers to sell access to their APIs, using flexible payment options including credit cards, cryptocurrencies or most conveniently, CPU.
- Access to New Markets: The global API marketplace and CPU allows API sales to developers everywhere with low fees.
- Blockchain Security: Remove pain of managing (and risk of exposing) client secrets and access control lists. The ORE protocol automatically maps blockchain ID accounts to API vouchers so developers can focus on their code, not security.
- Stable Payment: Set it and forget it. CPU protects developers from the volatility of global currencies, providing API buyers and sellers with a stable coin for secure transactions that are instant and transparent.
- API Chaining: APIs can be chained together without needing to translate different access control models and payment mechanisms at every level. Developers are compensated instantly and fairly at every level.
- Reduce Startup Costs: No attorneys, no accountants and no sales team necessary. The ORE protocol and the API marketplace provides all developers need to go from code to revenue with less overhead.
Benefits to API Consumers
- Standardization: Ensures APIs are compatible and interoperable, making implementation much easier.
- Discoverability: Find missing components. A single marketplace with user reviews and third-party assessments replaces time searching the web for each piece of technology needed.
- Quality Tested: Rest assured. APIs are tested and verified by the decentralized ORE network.
- Reduce Cost: Removing middlemen means APIs are built more easily so end cost to the consumer can be much lower.
- No Credit Card Required: Access new markets. Not all countries commonly use credit cards, CPU is available to anyone.
Make APIs available for third-party consumption. Sell API access, typically for CPU. Issue API vouchers and other ORE instruments to provide access to the APIs. Operate the API endpoints and provide test cases to the network for validation.
Use APIs to develop applications or other APIs. Hold the corresponding API vouchers and use them to access the APIs. Pay for API consumption, typically using CPU. API consumer can be people, companies, devices, software processes or objects, etc. Possession of the API vouchers is tracked in the ORE rights chain.
ORE miners serve two key roles in the ecosystem - storage and verification of Instruments, and validation and testing of APIs. In order to provide an early incentive for miners to participate in the network, a portion of tokens will be dedicated to mining rewards.
ORE Incentive Mechanisms
Need for Economic Incentives
Given the broad categories of functions required for the proper functioning of the ORE network and our interest in facilitating these functions in the form a decentralized network, we come upon a tension analogous to the “tragedy of the commons” problem in economics. If we already had a community of users who were tasked with providing the network services and maintaining the quality of the network, new users would be more motivated to use the ORE protocol.
However, the work involved to store and verify the ORE instruments and to vet the quality of the corresponding APIs is non-trivial, requiring scarce computational resources to evaluate a suite of characteristics like average latency, uptime, and unit test conformance. Without strong economic incentive, it will be hard to find enough people willing to do this work.
Luckily, we can turn to existing crypto-economic solutions to look for help. Following the intuition behind the proof-of-work systems popularized by Bitcoin and similar cryptocurrencies,
we anticipate a decentralized network of ORE miners who will perform the various network functions such as storing and verifying ORE instruments and validating the quality of the associated APIs. We attach an eponymous token to the ORE protocol which is used to reward miners for their effort. The ORE token thus becomes critical to the function of the network: ORE miners are paid with ORE as compensation for their efforts by API providers who need ORE to submit ORE instruments to the Open Rights Exchange. ORE miners additionally require the token as compensation for their API validation efforts. In this system, instead of searching for valid block hashes, the miners prove or disprove assertions about the ORE instruments - “Proof-of-Function”.
Along with acting as a fee token to avoid abuse of the network’s resources by users, we require miners to stake some
amount of ORE so that we have a mechanism to levy penalties against miners who are abusing the unique privileges they have on the network. Having an in-protocol mechanism to offer penalties along with rewards allows the overall network to be more robust as the individual incentives across users can be more closely aligned. Astute readers will ask why we don’t use an existing token such as ETH for our fees and staking system? Our choice to implement this function with ORE is designed to deal with the implicit incentives built into the protocol. By using a separate token, the incentives to be a miner are not impacted by either the price level or popular opinion of some other token. By using the ORE token, the incentives to be a miner are tied directly to the value of the network as it shrinks and grows, allowing independent actors to make rational decisions as to what extent they wish to contribute their hardware and time to maintaining a high-quality network.
Specific ORE Network Incentives
Storing ORE Instruments
Miners will receive ORE from API providers for accepting API vouchers and other ORE instruments, syntactically checking the instruments and then storing them for permanent record on the ORE rights chain.
Verifying Access Rights
Miners are also compensated for verifying API consumer requests to access API endpoints and for issuing the required access tokens.
API providers can prepay miners for providing this service using ORE, or miners can charge API consumers a small CPU fee. Prepayment by API providers for verification can involve a staking mechanism, where all or part of the stake is returned based on actual API usage
API providers compensate miners in ORE for running automated tests against the API endpoints associated with an asset, for example against general APIs that can be accessed with an API voucher.
These tests can be fairly simple health checks to determine latency and availability, or they can be in the form of more sophisticated test suites made available by the API provider.
Results are published to the ORE rights chain, available for anyone to see.
Miners get to keep a small transaction fee in CPU for every payment they process in connection with accessing an API endpoint.
Tunable Rewards System
Bootstrapping the ORE network
Many blockchain projects use additional rewards to bootstrap an ecosystem. For the ORE network, we will create a mining rewards contract that provides shared rewards for all mining nodes on the network. In the early days of the network, these rewards are expected to be more lucrative than the fees API providers pay for the storage, verification, and validation of ORE instruments, but they’re expected to become less important over time as the network grows.
Additional rewards can also be paid to early adopters, such as to API providers for making popular APIs available.
Rewards System Management
This rewards function will be tunable and is governed by a governing body made up of ORE Holders.
The primary goal of this system of governance is ensuring that miners only receive rewards for honestly participating in the ORE network and that there are enough miners at all times to maintain the network. The mining rewards will be distributed over a period of years to ensure that the ORE network has plenty of time to grow into a thriving ecosystem.
A secondary goal of the rewards system is to drive early adoption by API providers. What type of API providers will be rewarded is continuously evaluated based on the pace of adoption.
CPU - A Stable coin for Machine to Machine Transactions
Clearing Currency for Transactions
CPU is a token designed to be exchanged between API consumers and API providers to access their services. It is the default clearing currency for transactions under the Open Rights Exchange Protocol and works anywhere on the globe. Unlike other cryptocurrencies it has a ‘gold standard’ to reduce volatility - it can be exchanged for cloud processing power.
“Gold” Standard of the Internet
- CPU is tied to a fixed amount of cloud processing power
- CPU is underwritten by a loose association of hosting providers
- No central bank is required. The market for CPU is managed as a digital autonomous organization via smart contracts.
- This single clearing currency directly relates to the core cost of producing API services, allowing multiple APIs to be chained together while paying for their work at each step of the way.
- Unlike BTC, ETH or other currencies that are volatile, developers can set a price for their APIs and look away for weeks, months or years and maintain profitability.
- CPU transactions are written to the Ethereum blockchain.
Fixed Work Pricing
CPU are issued on demand. They correspond to a certain amount of cloud processing power that is fixed. Therefore the price of each CPU is set at the time it’s purchased, and they slowly lose value over time if they’re not used. Holders may also return CPU for ETH.
Hosting Partner Economics
CPU hosting partners act as underwriters for CPU and make money by receiving a market price for CPU at issuance, but only needing to redeem CPU at a later point, when the costs for providing cloud computing services will have already declined.
ORE Network Governance
Stakeholders in the Open Rights Exchange, such API providers, API consumers, ORE miners, as well as other ORE holders all will have a say in how the network is governed. Votes will be distributed in relation to the amount of ORE held by each party. Some parties will hold ORE because they received it at launch or bought it, others, like ORE miners, will have earned it by performing key network services. We also plan to reward participants on an as-needed basis with ORE for contributing to the network in other ways, say by becoming an early adopter. The net effect is that most stakeholders will have voting power that is commensurate with their interest in and contribution to the network.
Given that there is an actual cost associated with ORE, we don’t expect Sybil Attacks to be financially feasible. A network run by those actively using it should prosper in the long run at the short-term expense of opportunistic speculators. Proposals will require a TBD supermajority vote to be adopted.
Votes are expected on a variety of topics:
- Tuning the rewards model: as the ecosystem develops the rewards model may need to be adjusted to ensure that ORE miners receive fair compensation for their work
- Adding new payment protocol options: at launch, the ORE network will only support CPU for pay-per-call monetization, but other currencies could be added by vote.
- Improving automated tests: since API validation is one of the primary roles for ORE miners, we expect additional automated tests to be added to the network over time
- General Governance: changes to the network node software and adding or removing features from the protocol will be decided democratically by the ORE network participants
Future Work - Token-Curated Registries
As the Open Rights Exchange becomes more widely adopted, there will be a natural demand for third-party services that enhance discoverability and ensure reliability in the market. Much of this work will be done manually through lists or registries that have been curated for meeting specific criteria or quality standards.
AIKON will provide an open-source framework for the creation of Token-Curated registries. At launch, we will provide, at a minimum, the first registry which is a manually curated list of APIs that we have certified as high quality. We will also open source the rules and smart contract code for creating new registries to make it easy for token holders to create and profit from their own registry enterprises.
In the long-run, many different registries will provide a broad range of domain-specific assessments, eg.:
- HIPAA compliant
- Privacy rules compliant
- Rating of medical tests accuracy
- Historical forecast accuracy of pricing models
Governance and Incentives
Testing will be managed by the governing body of a given registry. The creators of the registry will create systems for updating their requirements over time to ensure that they have a useful assessment regime for the public.
API providers will stake ORE tokens to be certified for a given registry and the certifiers will be paid for their work. Certifiers will also be given voting rights within their registry to govern ongoing changes to their rules or standards.
Enabling Decentralized Commerce
There is a worldwide movement in the blockchain community to create a shared vision of decentralized digital commerce. AIKON is committed to doing its part, working to deliver critical missing elements for a truly decentralized economy, where everyone can contribute and innovation is propelled on a global scale.
To this end, AIKON has created the Open Rights Exchange protocol for connecting API providers and consumers. We will provide ORE node software for miners to download and run the first nodes on the ORE network. We are issuing a token called ORE to access network services and to align incentives of the network participants. We will also enable the creation of a pegged currency called CPU to facilitate payments with low volatility. We are launching the first API marketplace on the blockchain for developers to collaborate, innovate and monetize their APIs via Open Rights Exchange.
These tools are being built to provide world-class capabilities to developers everywhere, to allow anyone with great code to easily monetize their work and to ensure that the value created by the decentralized economy is accrued by the people doing the work. This is the promise of decentralization and AIKON is committed to making that vision a reality.
Nothing herein constitutes an offer to sell, or the solicitation of an offer to buy, any tokens, nor shall there be any offer, solicitation or sale of ORE or CPU tokens in any jurisdiction in which such offer, solicitation or sale would be unlawful. You should carefully read and fully understand this whitepaper and any updates. Every potential token purchaser will be required to undergo an onboarding process that includes identity verification and certain other documentation, which you should read carefully and understand fully because you will be legally bound. Please make sure to consult with appropriate advisors and others.
This white paper describes our current vision for the AIKON platform. While we intend to attempt to realize this vision, please recognize that it is dependent on quite a number of factors and subject to quite a number of risks. It is entirely possible that the AIKON platform will never be implemented or adopted, or that only a portion of our vision will be realized. We do not guarantee, represent or warrant any of the statements in this white paper because they are based on our current beliefs, expectations, and assumptions, about which there can be no assurance due to various anticipated and unanticipated events that may occur.
Please know that we plan to work hard in seeking to achieve the vision laid out in this white paper, but that you cannot rely on any of it coming true. Blockchain, cryptocurrencies and other aspects of our technology and these markets are in their infancy and will be subject to many challenges, competition, and a changing environment. We will try to update our community as things grow and change but undertake no obligation to do so.
Copyright © 2018 AIKON