ðģSettlement Layer
How we ensure revenues are fairly shared between AI value creators
The use of the ERC-3525 standard enables the easy sharing of revenue from AI products between everyone involved in providing the overall solution: the AI model creator, the data providers, and the app designer, as well as the fractionalisation and trading of each component.
This is crucial for the construction and development of a transparent and modular on-chain AI service accounting system, given that the core cost of provision in this sector lies in the processing power, and thus pay-per-query charging models are standard.
Generative AI and Retrieval-Augmented Generation
The core challenge for anyone aiming to process AI transactions in a decentralised manner lies in the nature of the pay-per-query system used by AI apps and models. This results in the creation of multiple very small transactions. Even when providers charge a standard monthly fee, this is nevertheless based on and rate-limited via the careful tracking of average API usage by each customer, allowing providers to work out how much capacity to provide in order to retain their margins in light of the fluctuating cost of compute.
The difficulty lies in processing many small-scale interactions on-chain, in an environment where transactions generally require signatures and take a comparatively long time to resolve.
We solve this problem via a bifurcated process.
KIP solves this problem using two core technologies:
Account abstraction. This allows users to top up an account and use it to automatically connect and engage with a multitude of apps without needing to sign each transaction. This not only allows users to transact seamlessly in an OpenAI-style manner, but also allows every interaction to be recorded on-chain via a simple emit, with the transactions being settled later.
The ERC-3525 semi-fungible token. This not only allows app, model and data owners to token-gate access to their work, but also serves a core role in reconciling the financial aspects of the transactions.
This means that under the KIP Protocol framework, the app serves to hold the system together and create a single source of truth. As soon as an app, model or dataset is deployed, it is tokenised in the form of an ERC-3525 SFT, which is then used to record and settle the transactions between users and the owners of the tokens relating to each element he interacts with. While users interact only with the app, the fact that this interaction is recorded on-chain, as are the models and datasets used by each app, the system can then settle the transactions at its own pace.
In the example given above, the app consists of a meta-prompt or set of chain-of-thought prompts, as well as various other settings (such as model temperature, top-P etc.) and the price settings selected by the designer. This can then be connected to a model (whether open or closed source) and/or a data source (whether hosted by Kipley, IPFS or another service). These may all be owned by a single user or by different users in each case. The possibility of containerizing, encrypting and even token-gating each element means that it is possible, for example, for User A to pay for the right to augment his model with User B's data, without User B having to hand the data over to User A - only the model itself gets access for the purpose of retrieval or retraining.
In practice, this process works as follows in the event of a typical generation request:
An app owner builds and deploys his app and the relevant APIs he needs to connect to the models and datasets he would like to use.
He then tokenises his app, including in the data of the ERC-3525 token minted the price and the url of the app.
When a user connects to the app, the connection is recorded on-chain as well as being indexed using The Graph, and the account frozen for the duration of the connection in order to prevent double-spending.
When a user asks a question, this prompt, along with the user wallet address the app's SFT ID, and the return endpoint for the answer is sent to the model API endpoint using the KIP standard API format.
The model owner's server checks that: a) the user exists, b) the user has enough money to pay for the request he is about to make, c) the app exists at the address it is supposed to, and d) the user is connected to the app.
If any of the information passed by the API does not correspond to that indexed by The Graph, the model server refuses to respond. If the information does correspond to that indexed, the model inferences the query and returns it to the specified endpoint.
When the user disconnects, the account abstraction system batches the payments for all of the queries conducted, which is then unfrozen. The payments are sent to the revenue pool.
The owners of the SFTs representing the app, model and dataset can then retrieve a share of the revenue from the pool corresponding to the price-per-query they originally set for their asset.
The result is that on-chain data can be used in place of an API key in off-chain contexts as well as to settle on-chain transactions without slowing down off-chain processes.
It is also important to note that KIP favourises the implementation of dynamic metadata in its ERC-3525 tokens. This allows each token to continuously update and thereby display the income that the underlying asset has generated, which in turn represents drawing rights upon a shared revenue pool.
Under the KIP system, each model and dataset provider is free to set his own price-per-query, while the app owner must charge a price that factors in these two supplier costs plus his own margins. A high-quality app, model or dataset will be able to charge more than their lower-quality equivalents. Thus, for example, if a user spends $KIP 10 on a query to an app which is connected to a model charging $KIP 2 per query and a dataset charging $KIP 3 per query, the full sum of $10 KIP is initially transferred to the revenue pool, and the drawing rights metadata of the three SFTs are updated, with the app designer now having $KIP 5 in drawing rights, the model provider $KIP 2 and the data provider $KIP 3, which they can excercise whenever they choose, using the SFT to withdraw from the shared pool.
An app owner may choose to count on users already possessing a KIP-standard account abstraction wallet, generate account abstraction wallets on their behalf, or even use a single account abstraction wallet to process all transactions that pass via the app. In the latter two cases, it is even possible for the user to pay the app in fiat and have the app top up a wallet with $KIP on their behalf in order to settle transactions. As long as the topped-up $KIP are not withdrawable, this is an easy way to facilitate onboarding for non-web3 native users without needing to exchange or swap currencies.
Model Training (up-coming feature)
In the event that the user wishes to train a model on training datasets provided by other users, the flow is slightly different.
In this case the user conducting the training makes payment to his chosen training data provider(s). The payment having been received, the model's SFT grants it access to the relevant datasets, with the SFT serving as a key within a token-gated data access system. The model owner can then encrypt and containerise his model and pass it to the data server. The model can then proceed to do multiple training runs on the data without any human external to the data-owner's organisation having access to the data, and without any human external to the model owner's organisation having access to the model weights. Upon completion of the training process, the model owner retrieves the updated model files.
Last updated
