• For Integrators
  • Sikka's Mechanics

Sikka's Mechanics

The key components of Sikka's functions lie between a set of smart contracts that interact across blockchains and existing contracts. Sikka created its customized smart contracts based on a fork of the MakerDAO smart contract set.

Modules

Sikka consists of 2 main modules:

  • The core module (a MakerDAO fork and Sikka's Interaction contract) — provide collateral, borrow SIKKA, repay SIKKA, withdraw collateral, liquidate collateralized assets.
  • The rewards module — claim rewards in GIKKA.

Fees

Borrowing interest — an interest paid to Sikka for borrowing SIKKA. The rate is a fixed number set by the Sikka governance platform.

Liquidation penalty — a percentage fee added to the user's debt in a Dutch auction during the liquidation process. Fixed by Sikka governance; current value is 13% of the debt.

Ratios

Collateral ratio — a percentage of the user's collateral value ratio that determines the maximum borrowing limit for the user. Different assets will have different collateral ratios dependent on the asset's volatility. The collateral ratio is used as a liquidation bar to decide when a liquidation event should happen.

Rewards

  • The borrowing reward — users get rewards for borrowing SIKKA, in GIKKA — the Sikka governance token. Rewards are calculated dynamically and are the product of the rewards rate and the total user’s debt in SIKKA. The rewards rate is a fixed amount set by Sikka.
  • The auction start reward — anybody who triggers the liquidation event of a CDP, i.e. start of a Dutch auction, receives a flat fee (tip) and a percentage fee (chip) for just initiating the process. The tip and chip are paid by Sikka from the Sikka reserves.
  • The auction restart reward — anybody who restarts the Dutch auction, which is part of the liquidation process, receives a flat fee (tip) and a percentage fee (chip). An EOA can restart the auction when the auction time limit is reached or the price decrease has reached a certain threshold. These two limits are set by the Sikka governance. The tip and chip are paid by Sikka from Sikka reserves.

Liquidation Model

The liquidation model is best described by the following example:

Step/VariableValue
Price of 1 unit of collateral$2
Liquidation ratio75%
Price of collateral with liquidation ratio$1.5
User deposits 10 units of collateral10 * 2 = $20
Borrow limituser_deposit * liquidation_ratio = 20 * 0.75 = $15
User borrows $15 of SIKKA15 SIKKA
Price of 1 unit of collateral decreases and now is$1.8
Collateral unit price, with safety margin_current_price_of_collateral_unit * liquidation_ratio = 1.8 * 0.75 = $1.44
Current worth of collateral, with safety marginprice_of_colatteral_with_safety_margin * amount_of_collateral = 1.44 * 10 = $14.4
Trigger for liquidationborrowed_amount - current_worth_of_colateral = 15 - 14.4 = $0.6, which is >$0
Somebody starts a Dutch auction to liquidate the collateral.
Starter is sent tip + chip as a reward for it, from Sikka reserves
300 + (16.95 * 0.01) = $300.169
User collateral that goes to Dutch auction10 units
Liquidation penalty (fixed by Sikka governance)13% of the debt
Debt to cover in the auctionborrowed_amount * liquidation_penalty = 15 * 1.13 = $16.95
buf (percentage similar to liquidation penalty, fixed by Sikka governance)2%
top (start auction price of 1 unit of collateral)current_price_of_collateral_unit * buf = 1.8 * 1.02 = $1.836
Auction starts and price gradually decreases.
Anybody can come and buy any amount of the liquidated collateral
tau (time in seconds until price is 0; fixed by Sikka governance)21600
dur (time in seconds elapsed since the auction start; fixed by Sikka governance)e.g. 600
Linear decrease of price of 1 unit of collateraltop * ((tau - dur) / tau) = 1.836 * ((21600 - 600) / 21600) = $1.785 after 600s of the auction
Somebody restarts the auction based on:
tail (specific amount of time elapsed; fixed by Sikka governance)
OR
cusp (% of price drop; fixed by Sikka governance)

— 40% of top = 0.40 = $0.7344
tip (flat fee given as a reward to auction starter/restarter; fixed by Sikka governance)$300
chip (dynamic fee given as a reward to auction starter/restarter; fixed by Sikka governance)%0.1 of the amount of debt in the auction
Restarter is sent tip + chip as a reward, from Sikka reserves300 + (16.95 * 0.01) = $300.169

Smart Contracts

The smart contracts that implement Sikka are:

  • MakerDAO set — the Maker Protocol, also known as the Multi-Collateral Dai (MCD) system, allowing users to generate SIKKA by leveraging collateralized assets. SIKKA is a decentralized, unbiased, collateral-backed cryptocurrency soft-pegged to the US Dollar.
    • ABACI — price decrease function for Dutch auctions during the liquidation process of user's assets.
    • CLIP — liquidation v2.0 mechanics.
    • DOG — starts Dutch auctions during the liquidation process of user's assets.
    • JOIN — ERC-20 token adapters.
    • JUG — collects Sikka's borrowing interest for lending SIKKA to the user.
    • SIKKA — stable asset SIKKA users can borrow from Sikka.
    • SikkaJoin — adapter for connecting SIKKA and MakerDAO.
    • SPOT — oracle that fetches the price of aMATICc, which is an intermediate token used during the process of collateralizing user's assets..
    • VAT — сore vault for collateralized debt positions (CDP).
    • VOW — vault balance sheet. Keeps track of debt or surplus of SIKKA.
  • GikkaRewards — rewards distribution, in the GIKKA rewards token.
  • GikkaToken — ERC-20 compatible rewards token GIKKA given to the user for borrowing SIKKA.
  • SikkaOracle — oracle for the SIKKA rewards token.
  • SikkaProvider — wraps MATIC into ceMATICc via cerosRouter.
  • cerosRouter — finds the best way to obtain aMATICc, which is an intermediate token used during the process of collateralizing user's assets.
  • cerosRouterStrategy — deposits and withdraws wMATIC into yeildConverter; generates yield for Sikka.
  • swapPool — swaps wMATIC for aMATICc if this option is cheaper than exchanging on DEX.
  • waitingPool — keeps track of pending MATIC withdraw requests and fulfills them when liquidity becomes available.
  • masterVault — wraps MATIC into wMATIC; mints or burns ceMATIC, which is the underlying collateral token inside MakerDAO.
  • CeVault — stores obtained aMATICc, which is an intermediate token used during the process of collateralizing user's assets.
  • Interaction — proxy for the MakerDAO contracts. Provides deposit, withdraw, borrow, payback, and liquidation functions to the end users.
  • AuctionProxy — entrypoint for Dutch auction methods, which is part of the liquidation process of user's assets. Allow users to start and participate in auctions.
  • aMATICc — liquid yield-bearing token used during the process of collateralizing user's assets.
  • sMATIC — token minted for the user as a deposit receipt for their collateral.

You can go through the smart contract codebase in the smart contracts repo.

Workflow

Here are the main Sikka's operations described in high-level detail.

Collateralize uUser’s Assets to Borrow SIKKA

  1. User transfers MATIC to Sikka via SikkaProvider::provide({value: amount}).
  2. SikkaProvider mints sMATIC for the user as a deposit receipt for their collateral.
  3. SikkaProvider gets ceMATIC, running the following logic inside:
    1. Deposit the user's MATIC to masterVault via masterVault::depositETH({value: amount).
    2. masterVault mints ceMATIC for SikkaProvider.
    3. masterVault wraps MATIC minting wMATIC.
    4. masterVault manager triggers the masterVault::allocate() to deposit the wMATIC to cerosRouterStrategy based on the strategy allocation.
    5. cerosRouterStrategy forwards wMATIC to cerosRouter which exchanges wMATIC for aMATICc through the cheapest swapping option (on DEX or via swapPool), via cerosRouter::depositwMatic(amount).
    6. cerosRouter sends the obtained aMATICc to CeVault for storing, via CeVault::depositFor(msg.sender, amount after exchange). msg.senderSikkaProvider address and amount after exchange — the amount of exchanged aMATICc.
  4. SikkaProvider collateralizes ceMATIC via Interaction::deposit(account, address(ceMATIC), amount). account — user's account address, address(ceMATIC) — address of ceMATIC smart contract, amount — MATIC initially collateralized by the user. Interaction runs the following logic inside:
    1. Transfers ceMATIC, which is an ERC-20 token, to the Interaction smart contract, via the transfer() function of the ERC-20 token smart contract.
    2. Transfers the assets to the MakerDAO vault via gem::join(). For more information, refer to the Join docs.
    3. Makes the VAT smart contract fully trust the Interaction smart contract via VAT::behalf().
    4. Locks the assets inside MakerDAO via VAT::frob(), effectively collateralizing them. For more information, refer to the VAT docs.
    5. Emits a deposit event.

Borrow SIKKA

  1. Borrow SIKKA via Interaction::borrow(). After the transaction is sent, Interaction runs the following logic inside:
    1. Calculate the current SIKKA value inside MakerDAO. While calculating take into consideration the borrowing limit, which is the price of the assets collateralized by the user * collateral ratio (fixed amount set by Sikka governance).
    2. Indebt the user equal to the borrowed SIKKA amount via VAT::frob(). For more information, refer to the VAT docs.
    3. Transfer the borrowed SIKKA via JOIN::exit(). For more information, refer to the Join docs.
    4. Emit a borrow event.

Repay SIKKA

  1. Repay Sikka the borrowed SIKKA via Interaction::payback(). After the transaction is sent, Interaction runs the following logic inside:
    1. Transfer the SIKKA to the Interaction smart contract, via the transfer() function of the ERCs-20 token smart contract.
    2. Transfer the SIKKA to the MakerDAO vault via SikkaJoin::join(). For more information, refer to the Join docs.
    3. Calculate the current SIKKA value inside MakerDAO.
    4. Subtract the repaid SIKKA amount from the user’s debt via VAT::frob(). For more information, refer to the VAT docs.
    5. Emit a payback event.

Withdraw Collateral

  1. User makes a withdraw request via SikkaProvider::release(recipient, amount).
  2. SikkaProvider requests ceMATIC to be sent to masterVault via Interaction::withdraw(account, address(ceMATIC), amount). account — user's account address, address(ceMATIC) — address of ceMATIC smart contract, amount — MATIC initiallly collateralized by the user. Interaction runs the following logic inside:
    1. Unlock the assets via VAT::frob(). For more information, refer to the VAT docs.
    2. Transfer the assets from the CDP engine to the MakerDAO vault via VAT::flux(). For more information, refer to the VAT docs.
    3. Transfer the assets to the user’s wallet via gem::exit(). For more information, refer to the Join docs.
  3. SikkaProvider request MATIC from masterVault.
  4. masterVault checks if the amount is avialable in masterVault contract. If yes, masterVault burns ceMATIC and sends the MATIC to SikkProvider, andSikkProvider burns the sMATIC. I no, masterVault withdraws the MATIC through cerosRouterStrategy , sneds it to SikkaProvider, and SikkaProvider burns the sMATIC; if no liquidity cerosRouterStrategy, masterVault submits the withdraw request to waitingPool, SikkaProvider still burns the sMATIC, and next time anyone deposits MATIC, masteVault fulfills the withdraw request sending MATIC to waitingPool, and waitingPool sends MATIC further to the user.

Claim Rewards

  1. For borrowing SIKKA, claim rewards in GIKKA to the user’s wallet, via GikkaRewards::claim(). After the transaction is sent, GikkaRewards runs the following logic inside:
    1. Update the rewards pool size and rewards rate.
    2. Transfer the pending user rewards to the user’s wallet via GikkaToken::transfer().

Liquidation

  1. When the current worth of collateral with safety margin < borrowed amount of SIKKA, the liquidation process can be triggered by anybody via Interaction::startAuction(token, user, keeper), where token — address of the liquidated assets, user — address of user whose collateral is being liquidated, keeper — address of the user who gets a reward (tip + chip) for starting the auction. Then Interaction runs the following logic inside:
    1. Start a Dutch auction:
      1. Set the starting auction price for the liquidated collateral to be equal (current_collaterral_unit_price * buf).
      2. Let anybody come and buy via buyFromAuction(token, auctionId, collateralAmount, maxPrice, receiverAddress) to buy any amount > than dust (currently 1 USD). token — address of the liquidated assets, auctionId — ID of the auction, collateralAmount — amount to buy, maxPrice — price to pay , receiverAddress — address of the buyer.
      3. If the maxPirce is > current_ auction_collateral_unit_price, sell the requested amount of the user's collateral to the buyer.
      4. Else, incrementally lower the auction price and let anybody buy still. The reason for decreasing from a higher price is because of bots and change of collateral price from oracle to avoid any sudden loss. The auction lasts a fixed amount of time (tau) set by Helio governance. The price is recalculated every second of the auction.
      5. When the auction time limit is reached or the price decrease has reached a certain threshold (the limits are set by Helio governance; currently 40%), let anybody come and restart the auction and get tip+chip for doing it.
    2. Transfer the price paid in 1.3, in SIKKA, from the buyer's wallet to Sikka.
    3. Exchange ceMATIC for aMATICc and send aMATICc to the buyer's wallet. Effectively, buyer buys aMATICc that they can later exchange for MATIC.
    4. Cover debt and keep profit (borrowed amount + (borrowing interest + liquidation penalty)).
    5. Calculate the remainder (price paid - debt - profit). Send the remainder to the user’s wallet.