DAI stable coin for share&charge on the Energy Web Chain

One of the biggest challenges at the interface of crypto-world and real life applications is the neat solution of payment with “stable coins” to avoid volatility for end users. In our Share&Charge solution this would make charging of electric vehicles tremendously easier compared to the status quo with different settlement or ad-hoc payment methods. As laid out in one of our earlier posts, we work with three different stable coin implementations.

The “Escrow concept”, the “Bookkeeping concept” and now “Dai”. In the first all tokens are backed up by one central FIAT currency escrow account whilst in the second all the companies participating in the network back the tokens themselves with an off-chain value settlement. Dai from Maker DAO would allow us the integration of a a decentralized-collateralization (more information can be found here: https://medium.com/makerdao/stablecoins-collateralization-types-2a860624dcd3) and instantaneous value transfer which very much fits also to our vision of decentralization of EV charging infrastructure payment. This is why we’ve integrated them into our solution. Stay tuned to learn about our progress.

Development Partners

Special thanks to eth.events for helping us with the observation of the blockchain and the triggering of the transactions. We’ve had our challenges with Ethereum events in the past and eth.events makes it a lot more reliable.

The first problem we are tackling is:

We’re building the charging settlement process on the Energy Web Chain (EWC) and Dai only exist on the Ethereum main chain.

Chain hopping

Getting Dai from the Ethereum main chain to EWC is not as trivial as one might think. There is no way to send a transaction to a different chain. We built the oracle and smart-contracts and enlisted the help of eth.events for the creation of the workers.

Basics

The elements of the atomic-swap (that’s the name for sending tokens between chains) are two bridge contracts and two tokens. Here is how sending a token from the parent (ETH main chain) to the child (EWC) chain goes:

It is visible in this diagram, that the process has 6 steps:

1. 1. The token holder transfers the Dai to the bridge contract on the parent chain
   2. The event emitted by the transfer transaction is picked up by a worker process
   3. The worker requests a signed approval from the oracle by sending it the transaction hash. The oracle has no need to trust the worker
   4. The oracle reads the transfer information from the blockchain and if it is correct, it generates an approved (signed) transfer request that is sent back to the worker
   5. The worker forwards the signed approval message to the child bridge to trigger the minting of the coins on the child chain
   6. The child bridge contract mints the same amount of tokens on the child chain as were sent to the parent bridge on the parent chain

In order to get the Dai back on the parent chain the process more or less goes into reverse:

1. 1. The token holder transfers the Dai to the bridge contract on the child chain this time
   2. The event emitted by the transfer transaction is picked up by a worker process
   3. The worker requests a signed approval from the oracle by sending it the transaction hash. The oracle has no need to trust the worker
   4. The oracel reads the transfer information from the blockchain and if it is correct it generates an approved (signed) transfer request and burn request that are sent back to the worker
   5. The worker forwards the signed burn message to the child bridge to trigger the burning of the coins on the child chain
   6. The child bridge executes the burn transaction to get rid of its tokens
   7. The worker sends the signed transfer request to the parent bridge
   8. The parent bridge transfers the tokens to the token holder

Requirements

In order for this to work we considered the following basic requirements:

• No token creation — the amount of Dai available to token holders must never be greater than the Dai held in the parent bridge
• No token loss — all the Dai in the parent bridge can be accessed on the child chain

• No bottleneck — if 100 token holders transfer their Dai in the same block, the oracle should be able to transfer them as quickly as possible

Implementation choices

With the above requirements in mind we built a system that complies in the following ways:

No token creation

As long as the oracle is not compromised, this construct ensures that it is not possible to create more Dai on the child chain than are held in the parent bridge contract. The fact that the oracle can be triggered by an external worker helps in ensuring a transaction can be retried.

The system is idempotent in that the state will stay identical if it is called multiple times with the same transaction hash. The bridge contracts store the hash of every transaction that is executed and will not execute it a second time. The oracle will create the exact same signed message every time if provided with an identical transaction hash.

No token loss

For the time being it is not possible to transfer Dai held by a smart-contract. The reason is that we can not be sure that the address on the child-chain exists. In a future version it will be possible to create address pairs in order to setup token transfers from an address on the parent to a different address on the child chain.

No bottleneck

The fact that the oracle does not publish transactions to the blockchain allows to decouple the authorization from execution and enables any number of addresses to execute the transactions. The oracle is not the bottleneck and does not require complicated logic or the use of an address pool.

Try it out

The test oracle has been setup to allow transfers between Kovan and Tobalaba and back. As these are both test-chains, no real security has been put in place, so please don’t attack the oracle, it is vulnerable and no point can be proven so far.

On the other hand, if you want to review the smart-contracts you’re more than welcome to submit issues if you discover any. The repo is public: https://bitbucket.org/shareandcharge/atomic-swap/src/master/

Steps to send tokens from Kovan to Tobalaba and back

The oracle has been deployed on https://atomic-swap.test.shareandcharge.com

The parent token on Kovan is 0x8896c05D26CfE637D50F72a72aa1aF4903745B07

The child token on Tobalaba is 0x60b543BBF57F6005502bf6F5d1cE65eACEF2b7a8

A public tobalaba node can be reached on http://35.178.213.209:8545 You can use this to configure the custom RPC end point in MetaMask

you can see the transfers on Etherscan by clicking on the above links

• get some Kovan ETH if you have none.
• get some tokens on Kovan by calling the faucet: /faucet/:your-kovan-address
• transfer tokens to the parent bridge on kovan (using metamask or the like) at 0x433BD07c82824EfdAD28a24C084d119Fc89479Eb

• you have three choices at this point

1. 1. do nothing and let eth.events do the work for you. You’ll have to wait for 10 block confirmations. Please note that eth.events is still testing the alerting system and that this might fail. If it fails to work for you, revert to choices 2 or 3.
   2. if you’re the impatient kind or just like to play around, you can trigger the minting of the coins on tobalaba by calling /incoming/kovan/:txHash
   3. if you would like to see what is hidden behind the scenes, get the signed transfer and call the child bridge contract yourself by calling /get/incoming/kovan/:txHash There is an example on how to use the return JSON in the tests

To get your tokens from Tobalaba back to Kovan

• transfer tokens to the child bridge on Tobalaba at 0x7fe40c087342e249ee0dc0cdc352e4bce0012299

• you have again the three options

1. 1. do nothing and let eth.events do the work for you. You’ll have to wait for 10 block confirmations. Again, this might fail so revert to the other two in that case.
   2. have the service make the calls for you by calling /outgoing/tobalaba/:txHash
   3. get the signed transfer and call the contracts yourself by calling /get/incoming/kovan/:txHash There is an example on how to use the returned JSON in the tests

Click below to watch our Atomic Swap Demo