PoolAccount management with LP tokens

[turadg]

What is the Problem Being Solved?

Fast USDC needs a PoolAccount, funded by multiple Liquidity Providers.

Description of the Design

FUC holds a PoolAccount. (For now an LCA but should work for any ICA)

Public invitations to:

• deposit
  • give: USDC
  • want: PoolShare
• withdraw
  • give: PoolShare
  • want: USDC

Exchange rate between USDC and LP shares is calculated by current size of the pool

• at any time shareWorth is the pool amount divided by outstanding shares
• in a withdraw, shares are burned and USDC provided
• in a deposit new shares are issued

Security Considerations

Scaling Considerations

Test Plan

Unit test of a PoolShare math module.

Contract unit test of deposits and withdrawals.

• offer overestimates value of share
• offer underestimates value of share

Upgrade Considerations

not yet deployed

[dckc]

In my current draft (#10400, 9c389e2), the pool is a ZCF Seat.

Should the pool be an orchestration account, visible at the cosmos level?

? Where to put the pool assets? ZCFSeat or Orc Account?
  : in a ZCFSeat
    + follows the usual Zoe API
    + avoids async flow in deposit / withdraw methods
    ? (How) do clients look up the balance?
      : they don't
        . because they don't need to
      : contract publishes balance to vstorage
  : in an orchestration account
    + cosmos bank module publishes balance
    - goes against "contracts don't handle assets directly" best practice
      . contract has to withdraw from vbank into seat in offer handler

codecider