Giter Club home page Giter Club logo

ds-dach's Introduction

ds-dach

Deployed on mainnet at https://etherscan.io/address/0x64043a98f097fD6ef0D3ad41588a6B0424723b3a#code

The Dai Automated Clearing House can perform the following actions:

  • Clearing of Dai and Chai cheques
  • Clearing of Dai -> Eth or Chai -> Eth uniswap sales
  • Clearing of Chai joins or exits

For example, A Cheque is a signed message containing the following information:

  • sender : address, the author of the cheque
  • receiver : address, the receiver of the funds
  • amount : uint256, a token amount to transfer to the receiver from the sender
  • expiry : uint256, a time after which the cheque can no longer be cleared
  • fee : uint256 a token amount to be transfered from the sender to whoever submits the cheque to the clearing house
  • nonce: uint256, for replay protection
  • relayer : address, the address authorized to clear the transaction

Anyone who obtains such a signed message can clear them, paying the gas cost of the transaction in exchange for the fee.

Signature generation

The contract uses the typed signature format of EIP-712 to provide a nice user interface and separate similar looking Cheques that might be used by other clearing houses.

If you want to try it out, here's a guide that utilizes the api at https://api.stablecoin.services to clear a dai transfer. This requires that you have seth and ethsign installed, and a local wallet with some dai or chai available. To install seth and ethsign, see dapp.tools.

Generating the signed message:

First, generate a dai cheque using the script provided at bin/daiCheque. For example, to generate a cheque of 0.1 Dai to the ethereum foundation multisig at 0xde0b295669a9fd93d5f28d9ec85e40f4cb697bae, paying 0.2 dai in tx fees.

First, set the environment ETH_FROM to whatever account you would like to sign the cheque with:

export ETH_FROM=0xacab #your acc

then generate the cheque and store it in a file we'll call cheque.json:

./bin/daiCheque 0xde0b295669a9fd93d5f28d9ec85e40f4cb697bae $(seth --to-wei 0.1 'ether') $(seth --to-wei 0.2 'ether') > cheque.json

Before clearing the cheque, you need to authorize the dach contract:

seth send 0x6b175474e89094c44da98b954eedeac495271d0f "approve(address,uint256)" 0x64043a98f097fD6ef0D3ad41588a6B0424723b3a $(seth --to-int256 -1)

we can then submit the cheque to be cleared using the stablecoin.services api:

curl -X POST https://api.stablecoin.services/v1/daiCheque -d @cheque.json -H "Content-Type: application/json"

ds-dach's People

Contributors

mrchico avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

ds-dach's Issues

Collecting fee before or after token transfer, does it matters ?

Hi, just wondering about the order of fee collection in case of a revert / not enough fund case scenario:

  • xCheque(...) fn transfer the fee before transfering the amount to the dst contract
  • xChai(...) fn transfer the fee after transfering the amount to the dst contract

Does it technically matters at some point?

+ exitChai() questions

  • The fn collect the fee in chai, why not collecting in dai ? My guess is that It would introduce a SafeMath.sol and it's a burden you want to avoid ?
  • The fn use dai.balanceOf(address(this)) to avoid computing the amount passed in dai but is it safe ? Why not calling chai.dai(sender) beforehand and use chai.draw() instead ?

actual relayer (msg.sender) not asserted, behaving currently as a fee_recipient

Right now Dach's Dai or Chai actions does not

require(relayer == msg.sender, "invalid relayer");

I could understand useful scenario such as a backend relaying meta-tx concurrently from differents EOAs while collecting fee on a specific address. However such implicit behaviour looks kind of "dangerous", given that its implicit. So right now, relayer parameter behave as a fee_recipient and if not asserted then a backend's relayer's EOA could be potentially emptied.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.