1. Introduction

Kona is building a decentralized lending platform providing funding against short dated credit card receivables. The system consists of two principal economic actors:

In the traditional model, there is a centralized manager who has discretion, control and custody over a closed ecosystem and its assets. This is replaced in the Kona protocol where immutable smart contracts manage execution and custody and the token model dictates capital allocation using a rational incentive scheme that dynamically optimizes the portfolio.

This paper deals specifically with the economic and commercial rationale of the Kona token model and not the technical aspects of the protocol. Technical implementation can be found here:

Kona Protocol

2. Structure

2.1 Portfolios

The system consists of Portfolios that allocates capital to eligible Oracles.

Figure 1: Single Portfolio Structure

Figure 1: Single Portfolio Structure

Oracles manage their loan-books within the system mandate but at their discretion. They naturally wish to be eligible for a capital allocation and would model their risk profile accordingly.

Figure 1 shows a single Portfolio construction. However due to Investor risk preferences, the system comprises of multiple Portfolios who in turn allocate to Oracles that are eligible for capital. This enables Oracles to specialize in specific capital areas or to generalize by running capital for multiple Portfolios.

2.2 Token Taxonomy

This is a two token system comprising Utility Tokens (KONA) that are staked to Oracle pools and LP Tokens (LPT) (although identity related NFTs can also be implemented).

LPTs are minted and burnt per capital inflows and outflows. Utility Tokens are issued over time following a dynamic inflation curve with a fixed maximum supply.

2.3 Stakeholders

There are three core stakeholders.

Hereafter, Tokens refers to the system Utility Token, unless specified otherwise

2.4 Multi-Vote Utility

The specific utility of the Token is to vote for Oracles to receive capital from Portfolios. However, since Oracles can appear in multiple Portfolios, and have varying specific contributory factors for each Portfolio, and since there are differing sample sets of Oracles for each Portfolio, a simple vote per Oracle will not suffice.