The following are a list of suggested practices for collaborative coding through Git + GitHub.
Put all code in branches. Branches are a non-destructive, "it doesn't really matter what you do in here," "completely isolated from everyone else's code" way to contribute changes to a project. Once your code on a branch "works," we can consider merging into main (formerly master) via pull requests as described in the next step.
Open pull requests to merge code into main. Ultimately, we want our "Definitely Works + Has Been Reviewed/Approved By Others + Can Be Considered Correct and Basically Forgotten About" code in the main branch. The pull request (PR) feature is an interface on which to collaboratively review, discuss, and iterate on code changes (w.r.t. the branch into which you're merging, often main). These changes are colloquially referred to as the "diff." On GitHub, this "diff" appears in nice green (for code you've added) and red (for code you've deleted) lines.
Keep pull requests relatively small. <= ~100 lines of "diff" is ideal. In simple terms, the smaller the diff, the easier it is to review.
Always request a "reviewer" for your code. While this "locally" slows us down, it often "globally" speeds us up, by reducing the number of bugs that a "fresh set of eyes" can help to catch.
bsci-sifchain
@bsci-sifchain
BSci Internal sifchain specs, docs
Public team
Joined on Sep 9, 2021
- "Keeping your DEX's liquidity in good hands!" Motivation Rational actors may choose to buy and hold Rowan indefinitely to access Sifchain's world class cryptoeconomic value generators, but they will also want to occasionally take profit to pay operational costs and rebalance to mitigate risk. Such rational actors will be open to coordinating any profit taking or rebalancing with their fellow Rowan holders so to maintain the usability of the DEX's liquidity for all Rowan holders. Liquidity protection is the mechanism by which they coordinate. It is an on-chain maximum amount of non-Rowan liquidity (aka "external liquidity") on Sifchain that can be bought at any given time duration. Variable Definitions Chain State The chain state is the set of information from the consensus protocol. This is exogenous to the model of the liquidity pool in that blocks are validated without feedback loop that prevents the operation of the protocol. The variables specified below are the state of the chain necessary to be read by the LPD monetary policy.
mbarlin changed 3 years agoView mode
- For the moment, this is a one-stop shop for all documentation, specifications, and thought collection generated as part of BlockScience's work with the Sifchain protocol. Blockscience Specifications - Margin Trading P1: Concept Math Spec Not maintained P2: Preliminary Math Spec Maintained P2: Mechanisms Spec (part of Prelim Math Spec) Maintained P2a: Short and Double Swap Notes Maintained
- Previous Version At the epoch level, as interest liabilities accumulate, $mtp$ health deteriorates. $$ h(x) = \frac{x_A}{x_A + x_L}$$ The decline in $h(x)$ affects the steady state interest rate $\beta^*$ as $$ \beta^{\star} = \frac{K_h}{h(x)} \cdot \frac{K_H}{H(X,Y)}$$ Thus, within an epoch, $\beta^{\star}$ is an attractor. In the above equation, the $\frac{K_h}{h(x)}$ term is $mtp$ specific and forms a local attractor. Whereas the term $\frac{K_H}{H(X,Y)}$ is akin to a base rate applied to all $mtps$ in the pool and forms a global attractor. The local attractor term $\frac{K_h}{h(x)}$ includes interest liabilities $x^I_L$ as $$ h(x) = \frac{x_A}{x_A + x_L}$$ and $$x_L = x^P_L + x^I_L$$
- Links Sifchain Event Schema ETL Repo Bootstrap [ ] How to integrate sif-etl? Parse actions from events
Itamar Reif changed 3 years agoView mode
