Overview

Introduction

The Kona Protocol is a decentralized lending platform providing funding against short dated credit card receivables, deployed on top of the Polygon and Moonbeam networks.

The system consists of two principal economic actors:

• Liquidity providers (LP) lending capital to the protocol.
• Multiple loan-book originators (Oracles) who draw capital from the protocol.
  In the traditional model, there is a centralised manager who has discretion, control and custody
  over a closed ecosystem and its assets. This is replaced in the Konas protocol where immutable
  smart contracts manage execution and custody and the token model dictates capital allocation
  using a rational incentive scheme that dynamically optimises the portfolio.

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

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

 Process

The Konas model runs on a time-based cycle where capital is invested at the start and perfor-
mance is measured at the end whereupon a new cycle begins. The length of the cycle is 90 days.

 Start cycle: Capital Allocation

• LPs provide brzTokens a brazilian real stablecoins, in return for LPTs. This forms the capital
  for the Portfolio.
• Token holder’s stake and vote for Oracles. The cost of capital for each Oracle is determined through
  a combination of staking ratios and the amount of Stand-by Capital they provide.
• Capital is allocated to Oracles according to the staking weights for the duration of the cycle.

During cycle: Loan Funding

• LPs cannot withdraw capital, although LPTs are transferable and liquid.
• No further capital is introduced.
• Tokens cannot be un-staked nor transferred.
• The Portfolio capital allocation does not change.

End cycle:Maturity

• The performance of the Oracles and the Portfolio are calculated.
• Principal and interest is repaid according to the terms (including any draw-down on Standby
  Capital facilities).
• A decay is applied to Token stakes that supported loss-making Oracles and these Tokens are
  paid to stakes for profitable Oracles.
• Token inflation is allocated.
• Capital inflows and outflows are processed.

(New Cycle begins.)

As a conclusion the protocol runs consecutive cycles. Between two 90-days cycles there is a 2-days period used to distribute excess, reward or damage stakers, enable new Pools (or discard others), new Oracles (or discord others), accept deposit and withdraw requests done by liquidity provider (during the previous cycle), etc. This 2-days period is divided into 4 stages:

• Distribution: During this period the Pool Manager distributes excess and rewards/damage stakers based on their results.
• Join/Leave: During this 1-day period, the Pool Manager accepts requests to:
  • Deposit/withdraw funds for each Pool
  • Enable/disable Pools
  • Enable/disable Oracles
• Voting: During this 1-day period, the Pool Manager accepts votes from stakers.
• Assign Capital: During some hours, the protocol assigns capital to the Oracles based on the voting and gives them time to accept it totally or partially. Idle funds can be redistributed.