note that it's possible to do this today by investing 1:2:1 in USDC:ETH:DAI! just have to find someone willing to hedge your ETH position (maybe collateralized by your liquidity shares??) 😉
— Noah Zinsmeister 🦄 (@NoahZinsmeister) April 19, 2019
WARNING: Using cryptocurrencies means accepting the risk that your funds can be irrevocably lost or stolen. Use best practices when managing your private keys! There is no substitute for knowledge and proper precautions.
This guide will walk you through converting ether into DAI stabletokens using a decentralized exchange. This guide assumes you have metamask installed as a browser extension and that you have ether in your metamask wallet that you’d like to convert (minus an additional gas fee) into the DAI stabletoken. You can add funds to your wallet using an exchange such as coinbase. Completing this tutorial on Ethereum mainnet will require converting at least $30 plus a fee into 30 DAI stabletokens.
What is DAI?
DAI is an ethereum stabletoken. Unlike other stabletokens (e.g. Tether, USDC), DAI does not use fiat as collateral. Instead DAI uses a dynamically allocated pool of ether to maintain the value of DAI.
DAI is a “soft” peg to the US dollar. As of this writing the maximum and minimum values of DAI were $1.06 and $0.97 respectively. The token usually trades within a cent or two of $1. DAI has maintained its peg of $1 USD since it’s inception on December 18th 2017. This gives the DAI stabletoken the distinction that it has weathered the erosion of value of ethereum and other cryptocurrencies relative to the US dollar experienced since their peak in January 2018.
Stablecoins are useful because they enable the exchange of goods and services using a cryptocurrency while keeping the price denominated in a global reserve currency (in this case the US dollar). Stabletokens are also useful as a hedge against the excessive volatility of cryptocurrencies, effectively allowing users to increase their ethereum holdings if they can correctly anticipate a reduction in the eth -> usd exchange rate. Stablecoins could potentially serve as means to stabilize local economies that suffer from corruption or high inflation (e.g. Venezuela, Zimbabwe. See step 3).
How does it work?
While most users will only use DAI as a medium of exchange, there is a complex credit market operating in the background. This is what actually maintains the stabletoken peg. Note that it isn’t necessary to understand this part of DAI to use it as if it were USD. Regular users will not create DAI, they’ll simply exchange their ether for it at a decentralized exchange.
The DAI peg is maintained using a game where borrowers act selfishly, and in doing so maintain the peg. In this economic game, the supply of DAI is regulated in response to demand for the stabletoken. If the peg slides too far in either direction of $1, borrowers can get “free money” from an exchange, which in turns causes the price to go in the other direction. If the demand for DAI stabletoken goes up, borrowers are incentivized to create more DAI. If the falling demand for DAI pushes down the peg, borrowers are incentivized to reduce its supply. Meanwhile, bots known as “keepers” ensure there is sufficient collateral in the system. Keepers are free to liquidate insolvent loans once they fall below a global threshold (150% collateral). Borrowers can prevent being declared insolvent by ensuring that there is sufficient collateral backing their loan.
The stabletoken protocol is implemented using a two types of erc20 tokens: MKR and DAI. DAI is the actual stable token, MKR is a governance token that is used to create loans and allow users to participate in the governance process.
The lender(s) of last resort:
Every store of value includes some level of risk. DAI is not FDIC insured. Instead it uses market mechanisms to ensure that DAI is safe to hold. In this system, the lender of last resort is not a single entity (the Fed), instead it is the total pool of DAI collateral.
Excluding systemic risk to the DAI stabletoken system itself, the risk in the DAI stabletoken system is assumed by MKR holders, i.e. users who create DAI by taking out a loan on their ethereum holdings and receiving DAI in return. These users take responsibility and are potentially rewarded for the task of regulating the amount of DAI stabletoken in existence.
Users who merely exchange DAI for goods and services can safely assume that their tokens have stable value in the short to medium term. The DAI peg could fail in a “black-swan” event or a financial attack where the markets for MKR or Ether collapse to a very small value. Presumably the decentralized nature of these markets makes them resistant to these types of collapses, however these markets are still quite young, so proceed with due diligence and care!
Step 1: Add DAI ERC20 token to metamask ethereum client
Follow these directions to configure your metamask wallet to store DAI stabletokens:
– Adding tokens to metamask
– How To Add A Custom Token In MetaMask
– Dai token on etherscan
Step 2: Use oasis.direct to convert ethereum in your wallet to DAI stabletoken
Oasis direct is an open-source, decentralized eth to dai exchange. There are no fees other than the gas fees required to execute the smart-contract. NOTE: This step will be updated soon
Step 3 (optional): Donate your DAI to Venezuelans
– oasis.direct github
– Maker DAI Dashboard
– DAI token contract
– FAQ: Possibly everything you ever wanted to know about Liquidation
– MakerDao Docs on Keeper Bots
– Helpful medium post explaining CDP market dynamics
“It is fine if you do not understand everything right now, we will go into more detail later.”
Step 1: Modify jenkins sshd server
This will additionally run a bash shell
Turn on jenkins sshd server and set port.
// Activate sshd server // "Manage Jenkins" // -> // "Configure Global Security" // then copy/paste this into script console import jenkins.model.*; import org.apache.sshd.server.shell.*; def inst = Jenkins.getInstance() def sshDesc = inst.getDescriptor( "org.jenkinsci.main.modules.sshd.SSHD") sshDesc.sshd.setShellFactory( InteractiveProcessShellFactory.INSTANCE) println 'Done with step 1!'
Step 2: get sh shell
ssh -p <jenkins-sshd-port> <jenkins-fqdn>
Step 3: get python shell
Step 4: spawn pty bash shell
>>> import pty >>> pty.spawn("/bin/bash")
NOTE: bash shell has a weird double echo effect
This is a brilliant talk. That is all.
“Anyone moderately familiar with the rigours of composition will not need to be told the story in detail; how he wrote and it seemed good; read and it seemed vile; corrected and tore up; cut out; put in; was in ecstasy; in despair; had his good nights and bad mornings; snatched at ideas and lost them; saw his book plain before him and it vanished…”
– Virginia Woolf
Good code is easy to understand. In a good codebase, changes to code are easy to understand. This requirement is fundamentally at odds with the messy, organic way that code emerges from the mind of the developer. Thankfully, git comes bundled with tools to help developers mold their changes into a concise, logical structure.
This is the first in a series of blog posts on crafting good commits. In future posts, we’ll explore 3 options to basic git commands that can help us make good commits:
git add --patch,
git merge --squash, and
git rebase --interactive.
But first: what is a commit and what makes it good?
Understanding the past:
Software development is a team effort and code itself changes constantly. Most authors write for the general public, whereas code’s authors and audience are usually one and the same. While prose can be considered finished (or perhaps merely abandoned) at the time of publication, software must be supported. Older versions must be patched; breaking changes reverted. These facets of software development have led to an engineering standard: code repositories must have logically coherent history of changes. These changes come in discrete steps, or commits. Commits are comprised of a diff, as well as some metadata, usually in the form of a commit message. Commits form the basic, atomic units of change in a codebase. In git and other distributed version control systems, commits are nodes in a directed acyclic graph.
The rigours of composition:
At odds with the need for a logically coherent history of a piece of software is the way it is created. Crafting good commits is usually an afterthought to the initial work of writing code. Inspiration is fleeting; better to get your ideas down before they’re gone forever. However, a few sketches of code can quickly turn a working tree into a tangled mess of disparate, disconnected changes.
Good commits have some useful properties.
Commits should comprise a single logical change. Good commits are cohesive and self-contained. They encapsulate a single, logical change to the codebase. Commits to master or stable branches should have the added property that they result in a passing build.
Good commits can be reverted. If a new feature has a bug or introduces a regression, it should be possible to revert a commit or series of commits to rollback to a previous good state.
Good commits are portable. It should be possible to port a commit or series of commits from one branch to another. For example, if a feature needs to be backported to a previous release, it should be clear which commits correspond to the feature, and it should be possible to apply these commit(s) to the release branch (say using
Now that we understand a bit more about commit is, what makes a commit good, and useful, we can start exploring some tools that can help ease the tension between turning ideas into code, and making good commits. Stay tuned.
In this infoq talk, Mitchell Hashimoto gives an overview of Terraform and Consul: what they actually do, and how you might use them to solve specific problems. The best thing about this talk is the chance to see how Hashimoto envisions some of these problems that are common to almost all large scale distributed software systems, and how his vision shapes the tools that come out of Hashicorp.
Many great points made in this talk, but if you were to pull away one key point form this talk, it’d be this: containers are probably here to stay, but they aren’t the entire story when it comes to running distributed systems. In the midst of the overwhelming (and justified) hype surrounding Docker and its burgeoning software ecosystem, it’s important to note that a lot of problems in the datacenter are orthogonal to containers and the problems they aim to solve.
While containers do solve a lot of problems, and people are quick to adopt them because of their advantages, we all realize very quickly that their are a lot of other pieces to this puzzle that containers just don’t address at all