<aside> 📖 Contents

</aside>

Collateral for Nibiru

Implementation

Impl 1: Naive Implementation:

Contract A: Public interface for depositing assets + Mint and Burn NUSD

• If I want to change the algorithm, I'd need to upgrade the contract and use a migration entrypoint. -> Problem: I have to consider future designs in the initial iteration.

Impl 2: Easy Migration Implementation:

Note that the main difference between Impl1 and Impl2 is making one part more modular by placing it in a second contract. This would make the public interface (ContractBank) rigid while leaving us open to use future, unforeseen designs.

ContractBankRuleset:

• I determine the conversion of assets (nobleUSDC, axlUSDC) to a message call to mint/redeem NUSD.

ContractBank: Can mint, burn.

• Public interface for depositing assets.
• I hold in state the address for the contract that can call me. Now, if I want to change the algorithm or scheme for the public interface, I can write a new Contract A' and point B -> A'.

Pseudo Code:

enum ContractBank::ExecuteMsg {
  Mint { tokens: Vec<Coin>, }
         // User calls this with input of external stable(s)
         // -> Retrieve conversion rules from ContractBankRuleset
         // -> Create an ExecuteMsg::ContractMint
         // -> User receives NUSD
  Redeem { tokens: Vec<>  , all: Option<bool> } // Reverse process of Mint.
  ContractMint   // the msg called by ContractBankRuleset to mint NUSD
  ContractRedeem // the msg called """""""""""""""""""""" to redeem "".
}

#[entrypoint]
fn sudo/migrate {
  SudoMsg::ChangeRuleset { ruleset_contract: String, checksum: Bytes }
    // Should fail if the contract doesn't exist (not stored and instantiated).
}

ContractBank::State {
  ruleset_contract: String/Addr // address for ContractBankRuleset, which should methods
}

ContractBank::QueryMsg {
  AllowedDenoms { } -> Vec<String>   // Query state from ContractBankRuleset
  MintCalc {}
  RedeemCalc {}
  TotalSupply {} ->  // Stargate Query on x/bank module
}