Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Generalization #171

Closed
murbard opened this issue Jun 25, 2021 · 1 comment
Closed

Generalization #171

murbard opened this issue Jun 25, 2021 · 1 comment
Labels
design Discussion about the design of a feature enhancement New feature or request

Comments

@murbard
Copy link
Contributor

murbard commented Jun 25, 2021

Minor generalizations of Checker greatly increase its use cases. Broadly speaking, the following aspects should be modular:

  1. allow FA1.2 / FA2 token as collateral for burrows instead of tez only. A single form of collateral is still accepted for a given checker instance, but different instances can have different collateral
  2. the control formula that sets the drift derivative as a function of the target should be pluggable, in some cases, a continuous function might make sense as opposed to a bang-bang control
  3. We can distinguish two big classes of contracts: those that attempt to replicate an index provided by an oracle (index-based), and those that attempt to replicate an existing token on the chain (token-based)
    1. For index-based we use the index, the ctez / tez cfmm price, and the ctez / kit cfmm price, with the ctez / kit cfmm being subsidized by the checker contract.
    2. For token-based, the setup is typically a bit different. Suppose we want to replicate USDS using tzBTC as collateral. In that case, we would want to derive prices from 3 cfmms, USDS / cUSDS, tzBTC / ctez and USDS / ctez, with the USDs / cUSDS pair being subsidized by the checker contract.
@gkaracha gkaracha added design Discussion about the design of a feature enhancement New feature or request labels Jul 15, 2021
@utdemir utdemir mentioned this issue Jul 27, 2021
Closed
gkaracha added a commit that referenced this issue Aug 17, 2021
@gkaracha
Unline tez and ctez scaling factors
d32cdc0 
If we manage to proceed with generalization (#171), token types
and even the indices we get from the oracle might change. These
previously-hardwired constants would thus get out-of-sync, breaking
our calculations.
gkaracha added a commit that referenced this issue Aug 17, 2021
@gkaracha
Scaling factor cleanup
f9f197a 
* Uninline tez_scaling_factor.
  This is needed for #171: if we end up changing the indices and
  they don't refer to tez anymore then the hard-wired scaling
  factor would get out of sync.

* Uninline ctez_scaling factor.
  Also needed for #171. If we change the token used in cfmm from
  ctez to something else (or if ctez changes its scaling factor,
  though this is highly unlikely), the hard-wired scaling factor
  would get out of sync.

* (fixedpoint_to_raw fixedpoint_one) is simply fixedpoint_scaling_factor
@gkaracha gkaracha mentioned this issue Aug 17, 2021
Merged
gkaracha added a commit that referenced this issue Aug 17, 2021
@gkaracha
Scaling factor cleanup (#243)
8633a7b 
* Uninline tez_scaling_factor.
  This is needed for #171: if we end up changing the indices and
  they don't refer to tez anymore then the hard-wired scaling
  factor would get out of sync.

* Uninline ctez_scaling factor.
  Also needed for #171. If we change the token used in cfmm from
  ctez to something else (or if ctez changes its scaling factor,
  though this is highly unlikely), the hard-wired scaling factor
  would get out of sync.

* (fixedpoint_to_raw fixedpoint_one) is simply fixedpoint_scaling_factor
@dorranh dorranh mentioned this issue Sep 23, 2021
Merged
This was referenced Sep 28, 2021
Merged
Closed
Closed
This was referenced Nov 2, 2021
Open
Merged
@gkaracha
Copy link
Contributor

I'm closing this issue, since we've been dealing with each part of it in separate issues (part 1 is tracked in #213, part 2 was discussed in #261 (and finally addressed in #283), and part 3 is tracked in #263).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
design Discussion about the design of a feature enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@murbard @gkaracha