Skip to content

Whitepaper

Introduction

Financial systems have existed since the beginning of civilization. Over time, they have undergone a vast number of transformations, changing the formats and principles of interaction. However, the essence of Financial Systems has always prevailed - helping people realize their needs. Financial systems started as informal savings and lending groups and evolved into co-operatives, mutual insurances, and co-operative banks, which became the commercial and retail banks that we know today through centuries of growth, mergers, and acquisitions. The current legacy system has become opaque, inefficient [1], and too big to fail [2]. The fintech revolution aims to correct these failures by disrupting the financial market and creating new, community-focused models.

Akropolis is a financial protocol for the growing billion-dollar informal economy [3]. Autonomous Financial Organizations have existed for centuries. They are common throughout the world, whether as rotating savings and credit associations (ROSCAs), or co-operatives. Through rigorous research, we have found that Kenyan Chamas –saving circles – are the most profitable informal financial organizations. Chamas register US$4bn in savings annually and the overall informal economy contributes more than 47% of Kenya’s GDP. However, due to the nature of their informality, these organizations are oftentimes subject to fraud, fund mismanagement, and corruption.

We believe that the future of finance belongs to user-owned - but not necessarily user-governed - networks. Our thesis proposes that banks and other financial corporations will be replaced by a federated network of autonomous co-ops, each of which will act in the interests of its owners and interact with other parties in a single digital financial landscape. The Akropolis protocol aims to create this new digital financial landscape by providing a unified program interface for the cooperation and exchange of value of digital financial organizations.

Overview

What is Akropolis?

Akropolis is a domain-specific financial protocol dedicated to the needs of the informal bank-less economy. It can be implemented on any blockchain with a Turing-complete [4] virtual machine. Our proposed initial implementation is on the Ethereum blockchain.

Within Akropolis, users are free to choose decentralized smart contract-based self-custody or nominate a regulated custodian. The protocol or its team do, and will not store user data or engage in regulated activities such as facilitating or promoting investment activities.

What problems does it address?

  • The complexity of starting an autonomous financial organization (AFO)

  • The geographic lottery of financial services availability

  • Allowing trust-minimised exchanges of value between groups (digital co-ops, guilds, mutuals), as social trust is not scalable.

  • Security, reliability and transparency of informal financial organizations

How does it propose to solve them?

  • Quickly set-up, operate and grow informal autonomous financial organisations (AFOs) like digital co-ops, guilds, and mutuals - with no geographical limits

  • Connect AFOs to a previously impossible interoperable scalable network between them and external third parties, whereby value can be exchanged freely in a trust-minimised way (e.g. co-invest, lend/borrow, trade);

  • Reducing instances of fraud and misuse of funds

  • Providing benefits of aggregation to users who would otherwise not be able to afford access to them

Key Features

  • No bank account required

  • DeFi integrations provide for a continuous savings rate

  • No need for long-term lockups to receive interest - continuous interest payment

  • Resistance to fraud or manipulation

  • Provable solvency

  • Ability to receive funds even if the organisation dissolves or fails

  • Scaling potential to co-operative bank model

  • User incentives to grow the network, lower the cost of use and speed up the delivery of services

  • Full funds ownerships in a trustless way: funds are stored in an on-chain ledger where only verified users with permissions have access to them

  • Transparent, real-time, immutable financial record-keeping for every user – solving fraud and minimizing the misuse of funds through multi-signature fund deployment

  • Programmable immutable smart-contracts that allow users to create automated financial algorithms. These algorithms implement the functionality of existing financial instruments and enable the creation of a large array of novel financial tools.

Target Users

  • Unbanked individuals and communities across the globe.

  • Individuals are parties, under-served by the legacy financial system

Network Actors

  • End-users - all network users, participating in at least one AFO.

  • Autonomous Finance Organizations and their associations (Guilds). AFOs can be created as public or private. Each organization can have a legal entity, registered in any jurisdiction, but this is not a barrier of entry.

  • The Guild is an association of AFOs, that is governed by members according to its constitution.

  • Capital providers: this category comprises internal and external capital providers.

  • Network keepers: token holders, participating in staking and governance processes. They are profit-seeking agents rewarded for correct risk assessments by receiving a network stability fee. End-users, capital providers and external individuals can be network keepers.

Each type has a unique set of goals detailed below:

Type of actor Economic objectives Incentives/Interaction with AKT tokens
End-user
  • Save and earn profit using an AFO
  • Have access to cheap loans provided by their AFO
  • Incentivized to commit money into the AFO according to the established plan and to repay loans taken from the AFO budget as a result of internal social pressure.
  • End users don’t generally use the AKT tokens
AFOs (Borrowers) and their associations (Guilds)
  • Secure access to well-priced and easily available credit
  • Maximise availability of credit and minimise its price
  • Maximise the duration and terms of the credit lines
  • Referral incentives: grow the network through referring other AFOs ( encouraging other AFOs to be moved to or set up on our network). The greater the volume of successfully repaid credit, the greater will be the reputational value of the system, and the lower the cost of credit;
  • Ability to attract a greater volume of credit proportional to the overall value captured in the system. Two mechanisms: maximise through growth in number of AFO members, or association with new AFOs in Guilds. This is important as a fractional-reserve banking approach is not available or applicable to non-bank AFOs.
  • The above increases the volume of staked tokens in the system, thus reducing the token circulating supply
Private AFO
  • To work with savings of members in private mode without interaction with other ecosystem actors
  • Incentivized to run all internal processes properly - otherwise, members can easily leave if they do not have any obligations or debts with the group.
  • Private AFOs do not participate in the network, therefore not requiring tokens
Capital Providers (Lenders)
  • To grant loans with the best risk/profit ratio
  • To be protected from fraud and defaults on debts by AFOs through network mechanisms
  • A token staking mechanism creates a collective scoring system that helps Capital Providers to make correct decisions and decreases credit risk
  • The governance approach allows Capital Providers to affect network variables that are decisive to their profit, such as the stability fee and the intra-network rate (analogous to LIBOR)
Network Keepers [5]
  • Maximise stability fee through correct risk assessments
  • Earn additional rewards in tokens from a Growth Fund
  • Staking and governance functions are enabled by holding the token which provides both an incentive and skin in the game to facilitate sustainable network growth.
  • Network keepers act as underwriters of Guilds’ default risk. They get rewards for correct default risk predictions through a % of the Capital Provider income from a specific Guild. In some cases - additional rewards (AKT tokens from Growth Fund). The idea is to support the network’s bootstrapping at its early stages of operation by awarding additional tokens to the stakers. This approach proved its efficiency to engage token holders to stake their tokens in well-known Livepeer project.
  • Their stake is partially burnt if one Guild member defaults on debt
  • Incentivised to create a public, data-rich reputation or credit scoring system to maximise their return, which can only be done through network growth

The Guild concept

For the informal economy, the cooperation inside an informal group is as important as interactions between groups. Lack of trust between different groups is a large problem in the interactions between and within informal financial institutions. The Guild concept is a historically proven solution to lack of trust. Guilds, Chambers Of Commerce [6], Business associations, and Self-regulated organizations (SROs )[7] play a significant role for both domestic and international commerce. As a company or a professional worker, being a member of a trusted and respectful association significantly decreases risks associated with interacting. In the Akropolis network, Guilds are associations of AFOs that act as self-governed professional associations to grow trust between AFOs and members.

drawing

Technical Architecture

The architecture of our protocol, as a TCP/IP construction, is structured in several layers, each of which is responsible for a separate function:

  • Identity Management module (IM)

  • Accounting module

  • AFO maintenance and Governance Module

  • Network Governance module

  • Payment processing Module (C2FC Framework)

drawing

More details about the functionality of each level will be described in the following sections.

Each level has its own API for interacting with other layers or for interacting with applications built on our protocol and third-party solutions.

Cross-functionality between AFOs will initially be limited to basic exchanges of value.

Identity Management Module

One of the limitations of the current state of Decentralised Autonomous Organisation (DAO) frameworks is the lack of a single entry point for digital ID and membership management through all organizations. Our aim is to build a single entry-point for interaction with all AFOs of which the user is a member. The user profile allows registration for membership in several organizations and functions as a single interface for managing all of them, in the same way that Slack supports participation in different teams. A user in a single interface can view all the AFOs in which they are a member, and manage the permissions and privileges that they have granted to the AFOs.

Identity management (IM) occurs through a generalised approach, based on the Ethereum Naming Service (ENS) [8].

Quote

ENS offers a secure & decentralised way to address resources both on and off the blockchain using simple, human-readable names (e.g. akropolis.eth). ENS is built on smart contracts on the Ethereum blockchain and operates in a distributed fashion for both its infrastructure and governance. [9]

Akropolis uses the same logic to create a single interface for managing all AFOs.

Our IM keeps the following records:

  • Registry of all users of the protocol and links to user’s external personal data providers, for example, a hash with a document copy or IPFS [10] link

  • List of all created Guilds

  • List of all created AFOs

  • List of all AFO members

The IM also provides interfaces for connecting third-party identity systems, both centralized and decentralized. External services can be connected using our API. As such, IM provides a pseudo-anonymous service through a pending robust zkSnark [11]/zkStark [12] implementation.

IM does not store personal data, neither does it deal with KYCs.

drawing

  1. User connects to any application using our protocol.
  2. The application requests information about the user.
  3. The Identity Management Module retrieves a list of AFOs of which the user is a member from the on-chain ledger.
  4. The Identity Management Module sends the user address from its public off-chain data (IPFS / Swarm / Server) alongside the list of AFOs to the application
  5. The app requests off-chain identity-relevant information.

Building reputation systems using Akropolis protocol

We envision a scenario where the network participants can provide and request user identification and personal data collection services (using IPFS / nuCypher [13] or centralized servers), combine them with financial transactions that are stored on-chain, and provide AFO risk assessment services to third parties.

We do not centrally store protocol user data or provide scoring and risk assessment within the protocol. All financial transactions of agents are stored on-chain.

We provide an API to get data on all issued loans on the protocol and its repayments. Any third-party can access pseudo-anonymised transactions on-chain and assess the risk on their own, or use third-parties to assess the risk. AFOs may choose to shared off-chain information in order to get access to competitively-priced credit from external capital providers. As a result, a third-party can combine various data sources to create a credit scoring system.

As noted above, pending an effective anonymisation and gas-effective zkSNARKs solution for Ethereum, our restrictions will be limited to those of the native chain.

drawing

  1. User provides KYC and other data to Reputation Service, which is necessary to estimate their risk score.
  2. The Reputation Service gets the links to the user’s external personal data providers from the from Identity Management Module
  3. The Reputation Service gets user data from external data providers
  4. The Reputation Service gets data on user financial operations in the Akropolis protocol (loans received and payments on them, savings) from the on-chain ledger
  5. The Reputation Service calculates the score and provides it to the Network Keeper

Payment processing kernel – C2FC Framework

The Akropolis protocol has created a specialized financial primitive – Commitments to Future Cash Flows (C2FC), which allows us to transform any financial interaction into an exchange of tokenised cash flows.

C2FC (Commitments to Future Cash Flows) is a financial primitive designed to enable seamless transfer, exchange, batching or trading of cash flows, linked to and issued by any party, be it a human, a corporate, a DAO, or a machine.

The C2FC framework serves to simplify transactional and payments functionality by reducing all exchanges of value to claims on cash flows.

C2FC is responsible for routing all payments in the protocol. Any interaction within the financial ecosystem (be it legacy or crypto) can be presented as an exchange of cash flows between two parties: the provider of capital (user or lender) and the utiliser of capital (service provider or borrower).

C2FC acts as an automatically executed right to claim a defined part of future cash flows that arrive at the issuer’s address within a given timeframe. C2FC issuance allows present-value future cash flows of any business or individual to be stored as a single token; and be easily exchanged, traded or used as collateral. This primitive simplifies workflows and widens the potential for new DeFi instruments and interactions.

The C2FC token acts as a transmitter that forwards cash flow from the issuer (borrower) to the C2FC token holder (lender) under initially pre-defined conditions.

C2FC Implementation

C2FC is currently implemented as a non-fungible token, that operates a set of smart contracts deployed on the Ethereum network. Every token is unique and contains the following data:

  • Address of payer
  • C2FC agreement parameters:
    • Payment periodicity
    • Payment currency, abstracted as a token address
    • Number of payments

Generalized loan model

The Akropolis protocol uses a generalized credit model for the implementation of credit products using C2FC, which specifies how the regular payments amount is calculated.

Installment is the amount of regular repayment of the loan, and Interest Rate p.a. is the interest rate per annum. Installments are distributed and, in sum, repay the loan principal (Loan Principal) and loan interest (Interest).

There are two types of loans accessible in our protocol - Annuity and differentiated payments.

An annuity payment remains unchanged for the duration of the loan agreement. Every month, the user will pay for the loan in equal installments, consisting of accrued interest on the loan and the part charged to the principal. In the case of differentiated payments, a user’s payment will decrease with each passing month because the debt will be extinguished in equal shares, and interest will be charged monthly on the balance of the debt.

Annuity model

Installment = K * Original Loan Amount

i = Interest Rate p.a. / 12

K = i * (1+i)^{Number of installments}/((1+i)^{Number of installments}-1)

Interest = Remaining Loan Amount * i

Loan Principal = Installment - Interest

Remaining Loan Amount_{t+1} = Remaining Loan Amount_{t} - Loan Principal_{t},

Where Remaining Loan Amount is the amount of debt after t-th Installment has been paid.

Reducing balance model

Loan Principal = Original Loan Amount / Number of Installments

Interest = Remaining Loan Amount * Interest Rate p.a / 12.

Remaining Loan Amount_{t+1} = Remaining Loan Amount_{t} - Loan Principal_{t}

Installment = Loan Principal + Interest

Ethereum Implementation

C2FC has already been implemented on the Ethereum mainnet and we are working on the C2FC financial primitive implementation on Polkadot. C2FC is materially different to the current implementations of ERC948 (EIP 1337) [14] and EIP1620 [15]. The following features are improved:

  • Direct debit initialisation by the sender

  • Ability to realize escrow logic for payments receiver

  • Ability to transfer ownership to receive recurring payments: transferred to another person

  • Tokens are composable and can be grouped into a portfolio according to predefined characteristics

You can check the deployed smart contracts for C2FC and source code here:

  • Code
# Mainnet address
0x98466a02404b939c5ee34030c3aab8a47aab80ab

# Kovan Address
0xb272fa8bd66fbd310165d322febd5e275081f886

Practical example:

Alice wants to borrow $1000 for 12 months with an interest rate of 10% per annum. Bob agrees to provide her with funds on these terms.

In the traditional banking system, Alice and Bob will have to sign a contract in which all the conditions will be written out and which will serve as a basis for dispute resolution. In the Akropolis protocol Alice releases a C2FC token in which it registers repayments parameters and sells this token to Bob. The C2FC token stores all information on the credit parameters and its return in the blockchain in an immutable form. Consider how it looks from a technical point of view.

To create cashflow Alice can call the existing C2FC implementation or re-write her own implementation (or use somebody’s else).

The C2FC contract should adhere to the interface of C2FCPayments, which inherits the IC2FC interface.

Main interface description as implemented in C2FC:

  • Function createCashflow

This function registers the cash flow in the system, captures the cash flow parameters and creates a token corresponding to this cash flow. This token can be transferred or sold to any ethereum address owner.

    /**
     * @dev @dev Function for create Cashflow
     * @param name string name of Cashflow
     * @param value uint256 maximum value for Cashflow
     * @param commit uin256 unit for payment in period (default, month)
     * @param interestRate uin256 size of interest above value
     * @param duration uint256 period of Cashflow
     */

    function createCashFlow(
        string memory name, 
        uint256 value, 
        uint256 commit, 
        uint256 interestRate, 
        uint256 duration,
        uint256 stackingTokens
        ) 
        public returns (bool);
  • Function executePayment

This function creates a new payment order. If the cash flow creator has enough funds to redeem the payment order, the funds from his wallet are automatically debited to the account of the owner of the token. The amount charged is stored on the C2FC smart contract and is available for withdrawal only by the owner of the token. If there are not enough funds in the cash flow creator’s wallet, the payment order is stored in the system with the status active.

    /**
     * @dev Execute payment order
     * @param tokenId uint256 ID of the token (base token, for example, ERC721)
     * @param tokenAmount uint256 value for payment
     * @return true or false operation
     */

    function executePayment(
        uint256 tokenId,
        uint256 tokenAmount //the token amount paid to the publisher
    ) public
        returns (bool success);
  • Function withdrawPayments

Funds withdrawn from the token issuer’s wallet are recorded and stored in a smart contract. The owner of the token can, at any time, call the function withdrawPayments and withdraw the funds to his wallet.

    /**
     * @dev Withdraw payments from Cashflow
     * @param tokenId uint256 ID of the token (base token, for example, ERC721)
     * @param amount uint256 value for withdraw
     * @return true or false operation
     */

    function withdrawPayments(
        uint256 tokenId, 
        uint256 amount
    ) 
    public 
        returns (bool success);

In our example, Alice creates a cash flow by calling the createCashflow function and selling the token to Bob. Bob receives the obligations of Alice: the loan, which she will have to repay according to the conditions specified in the tokenized cash flow. Then, Bob periodically calls the executePayment function (or, more likely, Bob will use some existing dApp to automate the process, for example, CashflowRelay.com) and receives regular payments from Alice to his account. Upon completion of the loan repayment, Bob withdraws funds from the smart contract by calling the withdrawFunds function.

Network Governance Module

The governance framework allows decision-making within AFOs. Autonomous financial institutions are completely digital objects that can make their own financial decisions, accumulate funds, provide accumulated funds for a long time, take loans and pay them off.

These AFO decisions are made by way of token holder voting in accordance with the chosen governance model. The Governance layer provides AFOs with high-level decision-making mechanisms, and “delegates” these decisions to the low-level transaction layer.

The governance framework will initially enable the following functionality, supported by the API:

  • Registration of a financial organization

  • Making changes to the constitution

  • Adding a new user

  • Excluding a user from an organization

  • Profit distribution

  • Buying or selling assets

  • Lend money to another AFO

  • Borrow money from another AFO

drawing

  1. A borrower issues a C2FC token for getting a loan and puts an order on the C2FC exchange.
  2. A member of an AFO suggests filing existing loan applications in order to get the loan interest.
  3. Voting system created. All co-op members can vote.
  4. According to the result of voting, if passed, the relevant finances are withdrawn from the co-op’s account.
  5. AFO/Co-op funds are used to purchase a C2FC token.
  6. Co-op’s account gets the C2FC token.
  7. Borrower pays for their C2FC obligations. The payments are routed to the Co-op account.

Network Governance

All network actors holding tokens can participate in the governance process of the overall network, and vote on ecosystem variables such as the stability fee, penalty fee, governance fee and the intra-network loan rate, modelled on LIBOR [16] or DIPOR [17].

The governance of the network is executed by token holders – it is a collective establishment of critically important variables. The governance mechanism helps balance the interests of all actors and allows a decentralized determination of crucial parameters.

Our system design does not require an internal stabilisation mechanism, but rather seeks to establish a balance of internal (intra-network) lending rate.

The main variables to govern are listed below:

  • Stability fee, staker’s reward

  • Penalty fee, the penalty applied to a stake in case of dishonest behaviour of a Guild Intra-network interest rate, the maximum interest rate that can be applied to a loan in the network

  • Governance fee, which is charged in AKT tokens from every successfully repaid loan and burned, initially established as zero

Actors incentivization

The network keepers are interested in high stability fees (giving them higher profits) and low penalty fees (which would reduce their risk). The Guilds (AFOs) are interested mostly in low-interest rates, but also high stability fees and low penalty fees, as in this case, if they stake tokens in favor of themselves, they receive a significant discount on an interest rate of a loan at low risk. (. The capital providers are interested in low stability fees (as this leads to higher profits) and high penalty fees (as this would incentivize an increase in the quality of AFO selection by token holders). Thus, these three main network actors have at least two opposite sides in terms of values within the ecosystem variables. Because of their opposing views, all three types of agents in the network have a strong incentive to participate in governance and attempt to influence network parameters in their favor. They can be assured that other agents will act against their interests if they do not.

The different stakeholders have the following incentives for network parameters:

Stakeholder Stability fees Penalty fees Interest rates, controlled through infra-network rate
Network keepers High, for higher profits Low, for lower risk Medium - to prevent under incentivization or default
AFOs and Guilds High, for discount on loan repayments when staking for own loans Low, for low risk when staking for own loans Low, for cheaper loans
Capital providers Low, for higher profits High, because that would incentivize more rigorous risk assessments High, for higher profits

Additionally, Guilds are incentivized to attract reliable members that repay debts adequately, as timely repayments lead to a better reputation and higher level of community trust. Higher community trust, expressed in stakes for the Guild, therefore decreases the cost to access new capital for the Guild. Along with this, Guilds are interested in holding tokens and staking them in favor of themselves to receive an additional deduction from the interest rate of a loan, and in participation in governance to have an influence on network parameters.

Meanwhile, Network Keepers are incentivized to participate in honest Guild selection as it leads to receiving profits and to make the best assessment of the Guilds’ credibility as possible. Besides this, they have to hold as many tokens as they can to have a voice in the governance process, because the stability and penalty fee values are critical for their business.

The capital providers are incentivized to provide loans to the most trusted Guilds in the network. Guilds gain reputation and trust when they pay back their debt diligently, thus community trust signifies a lower risk of default, and, therefore, a better risk/reward ratio for capital providers. Capital providers are highly motivated to hold tokens as participation in governance and influence on stability and penalty fee values, as well as the infra-network interest rate, is critical for their business. Further, capital providers are interested in network growth as it opens the lending market for them. Therefore, capital providers may also stake in favor of trusted Guilds, becoming network keepers, and work towards accelerated network growth.

Our incentive analysis demonstrates that all main actors presented in the ecosystem are motivated to hold tokens and participate in the governance process as it is critical for their business inside the network. The “community trust” staking mechanism in conjunction with the decentralized governance approach builds a game of incentives that can balance the aims of all actors.

This model was inspired by the MakerDAO (MKR) token model [18].

Network Internal Economy

Staking Mechanism

The mechanics of a staking process are described below. We used the approach developed by Livepeer [19] that comes down to using “rounds” as the definition of time in a staking process. We named the “rounds” “standard periods” within our model:

  • The timeline of the ecosystem is quantized by standard periods. It means that loans and repayment terms are tied to periods. For example, if a loan is for 4 standard periods, and the period is one week, the loan has a 4-week duration.

  • All stakes from token holders are accepted for a certain period, during which they are frozen and cannot be withdrawn, acting as skin in the “Community trust” game. This period is countable in standard periods. Example: if the token holders stake their tokens in favor of a specific Guild, they define the staking period as M standard periods, where M is a natural number.

  • The bid/ask orders are sent by lenders/borrowers during the standard period and executed before the new one starts. We are considering both algorithmic liquidity pooling (an example is Compound) and trading with discrete peers (an example is Dharma), following this classification [20].

  • Each Guild cannot borrow more funds than defined by its share in community trust (staking). A Guild cannot borrow a higher share of the funds from the overall supply in recent N periods than its staking share. This principle works according to this formula:

So, If the possibility of taking a loan worth Δ for i-th Guild is under consideration, the staking system verifies that if a loan is taken, the equation will be true, meaning that a share of this Guild in a loan-taking process is not exceeding its staking share. The ΣL is referred to all loans during the N periods, including partially or completely repaid ones.

This rule is applied only if N periods have passed. If the system is just launched and N periods have not yet passed, the system will wait for a collection of loan-related statistics, and only after this, the application the mentioned limitation will occur. During the initial period, the lenders have to take into account not only the tokens staked in favor of each Guild, but also the Guild’s reputation and payment history as the leading indicators for their decision-making.

  • As all community stakes – including stakes from AFOs that are members of a specific Guild – are placed for a defined period, it is easy to create a graph for every Guild that will indicate a number of staked tokens vs. time in periods. This is important as loans are processes spread over time, so the lender needs to see how many tokens will still be staked for a Guild after some time because it is the Guild’s reliability indicator.

  • In case of default on debt, the stake in favor of the Guild is penalized according to the established penalty fee.

Collective determination of trustworthy AFOs

The first token function is a collective selection of trustworthy AFOs via staking in favor of AFO associations, Guilds. An AFOs within-network debt creation is based on the C2FC concept that was described above. The issuance of C2FCs by AFOs is initially limited and depends only on community trust (or number of tokens, staked in favor of their Guild).

Any AKT token holder can stake his tokens on behalf of any Guild they trust, for example, as a result of a careful examination of a Guild’s financial flows and history. The amount of debt that can be issued by a Guild is limited by its share in overall staked tokens, which are equivalent to its community trust. The possibility to work with loans attracted by the Guild is managed inside it, the most obvious approach being to select AFOs by their stakes in favor of this Guild and taking into account its financial history. Whichever method of internal loan management they choose, the responsibility for loan repayment pertains to the Guild as a collective.

Token Model (AKT)

Token Type Network token
Token Use Governance and Work Token
Comparable token models MKR[21]*, Livepeer[22]*
Value creation and value capture Curated supply of community-vetted borrowers and incentivized external lenders balanced out by network keepers who are incentivized to maintain sustainable network growth. Network adoption is driven by lack of adequate banking alternatives; adoption will drive the demand for the network token, whilst staking and burning reduces its supply.

*We are using a similar governance approach.

** We don’t have token inflation as in the Livepeer protocol, but we have similar mechanics to delegate stakes in favor of network actors and allow them to perform actions in the network. Our actors are rewarded in AKT for their staking activity from the Growth Fund.

Token Design Principles

The main issue that prevents the informal economy from scaling is the fact that AFOs are economically isolated from each other due to a lack of trust. The AKT token design was introduced with the purpose to solve this problem and establish a trusted network amongst potentially adversarial parties.

The AKT token was designed to solve the problem of network trust and enable network governance. At its core, it involves two processes: Community Trust –staking in favor of Guilds – and the Governance process.

The problem of mistrust is solved by using special staking mechanisms (Community trust). The staking process is designed to make fraudulent activity unprofitable and reward honest and reliable participants. The governance process is modelled largely on MakerDAO and designed to balance the interests of various actors in the network.

Utility

Using the OutlierVentures classification [23], the Akropolis token can be classified as a Network Token, combining the Work and Governance functionality. It provides the right to contribute work to a network and participate in the governance process. Its utility is derived from the decentralized coordination of token holders, as with Augur (REP) [24], MakerDAO (MKR), Numeraire (NMR) [25], and Livepeer (LPT). Our token has been modeled referencing MKR and LPT in particular as the network objectives are highly comparable.

Role and purpose: what is the token role?

Our token is classified as a Network Token, combining the Work and Governance functionalities. It provides functionality within the Akropolis network, and can be used to control the access to liquidity, provide governance functionality, and/or contribute capital to the network.

As such, the AKT token is an essential element of the protocol internal economy and cannot be replaced by an external stablecoin. The token staking and governance approach requires a token whose value is connected to the current network and not tied to other projects and networks.

Other examples of network tokens with aligned objectives are those of Ocean Protocol [26], Fetch [27], and Ethereum.

The loans will be provided in known and reliable stablecoins, which will be further used to repay such loans and interest. AKT will not be used for this purpose. AKT tokens only serve to create an incentivization scheme for the interaction of different AFOs with each other. The implementation of this mechanism will be within the interoperability layer of our protocol. The interoperability layer’s main purpose is to enable AFOs to seamlessly and cheaply exchange value and data.

Value Proposition

The network’s raison-d’etre is to create value for its participants and to either (a) meet a current need, or (b) enable a novel, previously inconceivable or impossible value-accretive functionality. Our value proposition addresses existing roadblocks to growth and scalability of AFOs and offers novel ways of interaction, governance and value exchange. The Network’s benefits to users and token holders are:

  • Substantial cost reduction, ease of set-up and low cost of maintenance;

  • Reduction of perceived and real transactional risks;

  • Network growth in terms of volume of transactions parsed through it and number of users;

  • Scalability across geographies.

Underlying value

The value of the Akropolis token is tied to the key interactions between network participants, the possibility to receive profit by providing work for the network and to participate in the governance process. It should be noted that the token holder does not receive any profits by simply holding the token. The value is exchanged over the network, similar to Ethereum, Ocean, and Fetch.

The Akropolis Network token does not grant the right to receive any profits, income, payments, returns, or dividends from Akropolis or any entity from its group of companies, nor is it intended to be a security, commodity, bond, debt instrument or any kind of financial instrument or investment carrying equivalent rights.

Token Functionality and Use by Stakeholder Type

The token functionality and use is modeled using the Livepeer and MakerDAO frameworks and is designed to ensure that all participants, acting in their own self-interests, are motivated to (a) maximize the value captured through and by the network; and (b) maintain sustainable network growth. Please note that a party may combine roles for a greater impact within the network.

(See Table on Page 5 for details on the interaction and uses of the token according to each network actor)

Revenue model

Funding mechanisms of open source networks are still subject to research and experimentation, with two notable examples from the commercial world.

We anticipate various potential sources of revenue. All of the below have been validated with our partners and product specialists with reference:

  • % of the spread charged by external capital providers

  • % of the spread from the financial services and products

  • % of the remittances providers fees

Go-to-Market Strategy

Our generalised approach will initially focus on informal co-operatives and diaspora cooperatives with a strong remittances component. These groups are most likely to have an ability to bring in external capital and incentivise organic network growth without reliance on excessive debt.

  • Digital natives

  • Emerging markets: rotating savings and credit associations (roscas), inKenya, Ghana, Uganda, and some other African countries

  • Europe: Broodfonds (Netherlands) [28]

  • Europe; Mutual credit networks (Italy, UK, Switzerland) [29], Sardex (Italy) [30] and Wir (Switzerland) [31]

  • Europe and emerging markets: community cooperative banks

Risks and Limitations

General risks

  • Attacks against the decentralized components (smart contracts etc.)

  • Failure of centralized infrastructures such as crypto-fiat conversion apps or native mobile apps.

  • Competition with other credit services and organizations, especially informal ones in the areas of operation

  • Complexity of product usage for ordinary users in target countries

Risks, connected with implementation of the AKT token model

  • The collection of a majority of tokens by one of the three stakeholder groups (Guilds/AFOs, Network Keepers, Capital Providers), which will lead to a non-balanced governance strategy

  • High risks of fraudulent behavior by Guilds/AFOs at the initial stage of network growth, connected to the low volume of stakes and reputation

  • The complexity of buying tokens within AFOs to pay the governance fee. However, we assume that in the majority of cases, some Guild members will have staked tokens for the loan, so these can be automatically used to pay the governance fee)

  • In the case of apathy of voters [32] (low level of participation in voting), the narrow group of token holders can change fundamental economic parameters of the network according to their own strategy

  • An apathy of staking - where a majority of token holders avoid participation in staking, consequently exposing lenders to more significant risks. This can result in a deficit of lenders in the network. This problem is present primarily at the initial stage of network growth. We propose certain mechanisms, in some cases similar to those used by Livepeer, to incentivise participation in the staking process.

  • The values of and ratios between the stability fee, penalty fee, and infra-network rate may not be adequately established, resulting in system imbalance (which means that at least one of the groups of network participants will be not satisfied by these variables). In such a case, the network growth will be seriously limited.

Sybil attacks [33]

  • Malefactors could create fraudulent AFOs and Guilds. These structures can act to undertake activities such as intentional loan default. The Community trust staking mechanics is one of the main protection measures for such attacks.

  • Spam attacks - the creation of a lot of AFOs/Guilds for malicious means. One of the solutions is to freeze a certain amount on tokens for AFO/Guild creation and prevent their withdrawal until the created organization is recognized as honest according to the specific criteria of their members’ activity.

51% attack

  • In the Akropolis ecosystem, the term “51% attack” refers to an attack on governance processes by a conspiracy of >50% of active token holders (or the collection of this number of tokens by one small group). In this case, the attackers can establish variables of economic parameters serving only their own interests, which could destroy sustainable network operation. There are two protection measures:

    • The economic rationality of the attackers - if they destroy the network, they will ultimately lose the value of the tokens
    • Initial token distribution to stakeholders that are interested in network growth. The more significant Akropolis’ capitalization becomes, the more complex and expensive such an attack will be.

Roadmap

drawing

Glossary

Term Definition
AFO (Autonomous financial organisations) Autonomous financial organisations are self-sovereign digital member-owned organisations that provide financial services such as co-savings and co-investing, access to credit on flexible terms, and a basic form of insurance.
C2FC (Commitments to Future Cash Flows) [34] A financial primitive that represents the digital right to operate with future cash flows expected to arrive in any form to any Ethereum address (this could be implemented in any blockchain) within a given time frame. Simply put, it looks like a relay: a C2FC issuer must receive payment within this specified period, but those payments are fully or partially forwarded to the C2FC token holder’s address. Therefore, the future cash flows of any individual, company or service take the form of a measurable digital unit that can be easily exchanged, traded or used as collateral.
Governance Framework Autonomous financial organisations work as decentralised autonomous organisations. The governance inside each AFO is different from protocol governance: only AFO members are able to make decisions. There is no need for every autonomous financial organisation to have a token of its own.
The Governance Framework provides decision-making support for Autonomous Financial Organisations. The core Governance API supports a number of base level commands, like the registration of a new Autonomous Financial Organisation, making changes to its constitution, or allowing new members in.
IM (Identity Management) The IM is analogous to the Ethereum Naming Service, which keeps the following records:
  • Registry of all users of the protocol and links to user’s external personal data providers, e.g. hash with a document copy or IPFS link
  • List of all created AFOs
  • List of all AFO members
Guilds (Association of AFOs) [35] [36] Guilds are self-governing structures formed by AFOs as members. Within the Akropolis network, Guilds can be described as something similar to Chambers Of Trade, Business associations or Self-regulated organizations.
Basic network variables and definitions Stability fee - a reward for Network Keepers for staking in favor of "honest" Guilds (whose members repay debts diligently). This reward is charged as part of the interest rate of a loan.
Penalty fee - a penalty, applied in situations of debt default of at least one Guild member to the stakes in their favor. All stakes are equally penalized for a certain percentage of tokens for every default event.
Infra-network interest rate [37] - the maximum value of an interest rate that can be applied to a loan.
Governance fee - the percentage of a debt that is required to be paid in AKT tokens which are burned thereafter. Similar to MKR in MakerDAO.
Staking - AKT tokens placed as a risky deposit (commonly known as skin in the game) on a specific smart contract with purpose to perform the “selection” of honest Guilds by collective risk assessment. If the Guild members repay their debt diligently, the person who made a stake receives a reward in the form of a stability fee and, during the growth process additional rewards in AKT tokens.
Growth Fund - storage (smart-contract) for AKT tokens that are used for rewarding Network Keepers during the network bootstrapping process


References

[1] TresuaryDirect. The data on total public debt outstanding 1993-2019.

[2] The coming pension crisis. Citi GPS: Global Perspectives & Solutions, 2016

[3] FinAccess Household Survey, 2016

[4] https://en.wikipedia.org/wiki/Turing_completeness

[5] Eden Dhaliwal & Geoff Lefevre. Incentive Analysis: Arbitrage & Market Maker Keepers in MakerDAO, 2018

[6] https://en.wikipedia.org/wiki/Chamber_of_commerce

[7] FINMA Switzerland. Self-regulatory organisations (SROs)

[8] Ethereum Name Service. ENS Documentation

[9] Ethereum Name Service website

[10] InterPlanetary File System. IPFS Documentation

[11] Z-Cash. What are zk-SNARKs?

[12] Eli Ben-Sasson, Iddo Bentov, Yinon Horesh, Michael Riabzev. Scalable, transparent, and post-quantum secure computational integrity, 2018.

[13] NuCypher. Whitepaper, 2018

[14] Gitcoin. ERC 948, EIP 1337 - Subscriptions on the blockchain

[15] Paul Berg. ERC-1620 Money Streaming

[16] Julia Kagan. LIBOR review, 2019

[17] Matteo Leibowitz. Introducing DIPOR: LIBOR for Open Finance, 2019

[18] MakerDAO. The Dai Stablecoin System, 2017

[19] Eric Tang. Livepeer Delegating, 2018

[20] Alex Evans. DeFi Liquidity Models, 2019

[21] Joel Monegro, Chris Burniske. Maker Investment Thesis, 2019

[22] Jake Brukhman, Devin Walsh. Livepeer cryptoeconomics as a case study of active participation in decentralized networks, 2018

[23] Geoff Lefevre. Designing for user focused incentives using a Token utility canvas, 2019

[24] Augur Protocol. Whitepaper, 2018

[25] Richard Craib, Geoffrey Bradway, Xander Dunn, Joey Krug. Numeraire: A Cryptographic Token for Coordinating Machine Intelligence and Preventing Overfitting, 2017

[26] Ocean Protocol. Whitepaper, 2019

[27] Fetch. Whitepaper, 2019

[29] https://en.wikipedia.org/wiki/Broodfonds

[30] Open Co-op, UK Mutual Credit Network

[31] Sardex

[32] WIR Bank

[33] https://en.wikipedia.org/wiki/Voter_apathy

[34] https://en.wikipedia.org/wiki/Sybil_attack

[35] Akropolis. C2FC

[36] https://en.wikipedia.org/wiki/Guild

[37] Sheilagh Ogilvie. The Economics of Guilds, 2014

[38] https://en.wikipedia.org/wiki/Libor