LogoLogo
  • 01 ReSource Finance
    • Glossary
    • Executive Summary
  • 02 Mutual Credit
    • 2.1 Definitions and Rationale
    • 2.2 History
    • 2.3 WIR Bank
    • 2.3.1 Modern Multilateral Barter Networks
    • 2.4 Mutual Credit on the Blockchain
    • 2.5 The Basic Economic Questions for DLT-based Mutual Credit Systems
  • 03 The ReSource Protocol
    • 3.1 Introduction
    • 3.2 Distributed debt collection and obligation enforcement
    • 3.3 Distributed risk management
    • 3.4 Underwriting and risk assumption
    • 3.5 The Underwriting process - a breakdown
    • 3.6 Ambassadors and network administration
  • 04 Monetary Flow, Reserves, Default Insurance
    • 4.1 Introduction
    • 4.2 Default Insurance
    • 4.3 RSD Savings Accounts
    • 4.4 RSD Autonomous stability and relation to the US Dollar
    • 4.4.1 RSD/USD Soft Peg
    • 4.4.2 RSD on the Open Market
    • 4.5 SOURCE Token Dynamics
    • 4.6 Monetary Buffering
  • 05 Protocol and Network Governance
    • 5.1 Introduction
    • 5.2 Reputation
    • 5.3 SOURCE Governance Token
    • 5.4 Initial SOURCE Allocation and Distribution
  • 06 Application Layer
    • 6.1 Introduction
    • 6.2 The Underwriting dApp
    • 6.3 The Ambassador dApp
    • 6.3 The Pool Aggregator
    • 6.4 The ReSource Marketplace
  • 07 TECHNOLOGY
    • 07 Overview
    • 7.1 Negative Balances & CIP36
    • 7.2 Non-custodial Key Management
    • 7.3 The Marketplace
    • 7.4 Distributed Underwriting and Data Aggregation
    • 7.5 Financial Data & Data Providers
    • 7.6 ReSource Credit Risk Analysis Algorithm
    • 7.7 “Pay with ReSource"
    • 7.8 Cross-network liquidity pools for interoperability
  • 08 Future Industrial Use Cases for the ReSource Protocol
    • 08 Overview
    • 8.1 Telecommunication
    • 8.2 Complex Supply Chain Financing
Powered by GitBook
On this page

Was this helpful?

Export as PDF
  1. 07 TECHNOLOGY

7.1 Negative Balances & CIP36

Previous07 OverviewNext7.2 Non-custodial Key Management

Last updated 2 years ago

Was this helpful?

Traditional trade or IOU systems typically allow for a 1 to 1 trade where each side of the transaction must agree that their goods or services are of equal value to the other party's goods or services and if so the transaction can take place.

Examples of this include Facebook marketplace, Craigslist, Offerup, etc. - traditional peer to peer marketplaces. Mutual credit only requires one party to agree that the purchase of a good or service is less than or equal in value to the amount of work done in the network required to payback the purchase.

The selling party can then take the proceeds of the sale and form the same conclusion with any other participant in the network. In order to keep a record of each individual's balance within the network we need a unit of account that could accommodate a negative balance. Traditionally, account balances in decentralized systems only maintained positive balances, thus we created RSD and CIP36

At the core of the protocol lies (Celo Improvement Plan) which is a fungible token standard designed to implement and abide by the but behave like a mutual credit currency.

The key differences in CIP36 vs. ERC20 are:

  • The total supply of a CIP36 token is equal to the total amount of outstanding debt on the network. Therefore, the total supply will expand and contract as credit is utilized, but will never exceed the total amount of credit issued.

  • CIP36 has a list of members - represented as addresses/accounts. Members are assigned a credit line by a party assuming responsibility for overall network solvency (the "issuer").

  • Accounts with a credit line may spend into being some amount of the mutual credit currency (e.g., RSD) to other wallets/accounts that are within the particular network.

  • When an account having a negative balance receives a payment, the credit balance is repaid for that amount. If it is fully repaid, the balance rises into the positive.

  • Both positive and credit balances implement the ERC20 specification and may be transferred at will. The only stipulation with the credit balance is that it does not exceed the members defined credit limit such that a member with a credit limit of R$100 cannot send another member R$150 unless they have a positive balance of at least R$50.

Example:

  1. There are two accounts - A & B.

  2. Account A has a positive balance of R$500 with a credit limit of R$1000.

  3. Account B has a negative balance of R$500 with a credit limit of R$1000.

  4. Account A transfers R$1500 to account B.

  5. This consists of a $R500 RSD token burn and a $R1000 RSD token transfer

  6. Account A now has a negative R$1000 and can spend a total of R$0

  7. Account B now has a positive R$1500 and can spend a total of R$2500

CIP36
ERC20 standard