🏗️Transaction Building

Web3 reliability, web2 speed

While we are strong believers in the unrivaled capacity of on-chain accounting to provide security and transparency, we also recognize that the vast majority of AI users and developers do not want to deal with cumbersome blockchain payment mechanisms at every step of their respective processes. For this reason, KIP Protocol proposes a secure on-chain framework for recording and tracking interactions between model, data and app providers.

In this context, on-chain data indexed using The Graph serves as the single source of truth for the entire system, with internal transactions being structured by a set of KIP protocol smart contracts and the blockchain serving as both an accounting record and a control system for the web2 APIs that provide the user services.

These web2 APIs also provide a “fiat wrapper” for users who prefer not to interact directly with the on-chain elements, while also offering Web2 speed to all users

The core problem we faced in designing our systems was that blockchain provides the best and most convenient proof of rights and transactions for those who wish to verify them, but it is slow, cumbersome and unfamiliar for the majority of casual users. In other words, we had to find a way for users to interact with the protocol with the same ease as they have come to expect from Web2 SaaS, while still ensuring that data exchanges would be recorded on chain.

This immediately runs into a time problem: if users have to validate every interaction with a chatbot, this renders the conversation unacceptably slow and cumbersome, but if they are permitted to interact before the block record has updated there is the potential that they will receive the information purchased and then either cancel the transaction or withdraw the relevant funds from their wallet – either way, the seller loses.

For this reason, we propose a Web2.5 interface in which the blockchain serves as a single source of truth for internal accounting and permissions, with users having the option to interact with it via either a Web3 or a Web2 interface.

How will this work in practice?

1. When a user signs in (whether via email or by connecting his wallet), he either connects his own non-custodial wallet or buys a certain number of platform credits ($KIP) using fiat. The credits are then stored in an account abstraction wallet that is owned by the user but integrated with the KIP Protocol in such a way as to allow topped-up funds to be withdrawn to the revenue pool automatically.

2. Users are free to transact with each other as long as they: a) Currently have enough credit in their account to cover the transaction and, b) Do not have pending transactions totaling more than the value of the transaction they wish to execute.

The wallet abstraction contract records the amount of the top-up received, and will automatically validate app interactions up to that amount. If the user requests transactions beyond this, they are asked to first top up their wallet. The transactions are batch-processed once each day, thereby reducing gas costs and allowing users to interact at regular speed without any risk of over-spending.

To implement this, we use the Particle Network account abstraction system, a more detailed description of which can be found here.

This means that the Web2 front end and the Web3 back end can both work at their own natural speed and the platform does not suffer from double-spending vulnerabilities or slow response times. Users receive responses at Web2 speed with Web3 transactions being processed at network speed by network of ERC-3525 tokens that constitutes the internal accounting system. Counterparties can transact with confidence knowing that no user can accumulate more pending transactions than their wallet can sustain.