Manage Your CDP with the Ethereum Alarm Clock
The Ethereum Alarm Clock is a scheduling protocol on Ethereum which enables trustless scheduled smart contract execution.
One of the most exciting things about the Ethereum Alarm Clock (EAC for short) is the interoperability between projects. Since everything on the blockchain is transparent, we as developers can connect protocols together to create cool systems on top of the base layer foundations.
Recently, the ChronoLogic team hosted a joint livestream with Sean Brennan from MakerDAO. MakerDAO is the company behind the Dai Stablecoin system, the most widely used decentralized and stable cryptocurrency. There is over 62 million Dai in existence — each one pegged to 1 USD. The Dai stablecoin is run completely on Ethereum with smart contracts.
During the livestream we discussed some possible ways the EAC and MakerDAO’s Dai stablecoin system could work together on a smart contract level. It was agreed on that we needed to write more about these examples and show some code snippets for how exactly something like this could work.
We will explore two use cases which use the scheduling feature of the EAC to interact with the MakerDAO CDP (the collateralized debt position) in order to manage the debt in the system in a more autonomous way.
The first example will show how one can set up a routine collateral check which will check your CDP for you and send some extra collateral if it registers as in danger.
The second example will show off a rudimentary instance of a recurring transaction which will repay a Dai debt to a CDP every week.
These examples are NOT production ready but we intend them to be springboards for developers to build their own ideas which make use of features found in these two ecosystems.
Use Case #1 —Schedule Dai repayments
Scenario: You have an open CDP and you want to make routine payments of Dai to it until you have no more debt left.
To accomplish this we will need to deploy a custom smart contract which wraps over the scheduling functionality of the EAC and allows for the Scheduled Transactions to be whitelisted. This contract provides the glue between the MakerDAO Dai system and the scheduling functionality of the EAC. You can also think of this contract as a multi-signature wallet with the ability for schedule transactions to become one-off executive signers.
Here is an overview of the contract that will be used. If it’s overwhelming for now, don’t worry we’ll break it down piece by piece.
The first core pieces that we will need are the address of the MakerDAO Tub (this is the name of the CDP smart contract), the address of the EAC Scheduler, and the Id of your CDP. You can find the right address for the EAC Scheduler (there are two: one using blocks as units and the other using timestamps) here. For the address of the MakerDAO contracts, find them here. Using these addresses you can deploy a contract like this one to the Ethereum Kovan test network or even the main chain, since both of these systems are in production.
Protip: MakerDAO has a unique naming convention which assigns one-syllable words to most of the fields and functions. These words are sometimes intuitive, other times take time to understand. For more information on the jargon see the Purple Paper.
You will probably begin by creating a CDP from an external account (let’s say using your Ledger Nano S hardware device for instance). The first hurdle we face is that the contract for managing your CDP must be the owner of that CDP in order to do any interesting stuff with it. After deploying the contract above, make sure to call tub.give(_cdpId, _mgmtContract) to transfer the ownership of the CDP.
After deploying the contract and transferring ownership of your CDP you will initiate the recurring check with the newSchedule() function. One caveat to using the EAC in this way is that you must make sure that the contract has enough Ether funded into it to allow for these smart contract calls to take place. It’s estimated that each call will be less than a 1 USD each but it’s a good idea to space the calls far enough apart where it’s not racking up a huge amount of costs. (We are working on conditional scheduling in Chronos which will be better suited for this type of conditional executions)
Let’s take a close look at newSchedule():
function newSchedule() public returns (address) {
require(msg.sender == futureTx || msg.sender == owner);
uint256 scheduleFor = now + 7 days;
futureTx = SchedulerInterface(clock).schedule(
address(this), // to
new bytes(0), // callData
[ //
1000000, // callGas
0, // value
2500, // executionWindow
scheduleFor, // executionStart
5 * gwei, // gasPrice
0, // fee
12500, // bounty
12500 // deposit
] //
);
return futureTx;
}Here we use the SchedulerInterface which exposes the schedule function for the EAC Scheduler contract that we want to use. This function takes the arguments that we want to schedule for a future call and deploys a new smart contract that will be executed at a later time.
For this example, we are scheduling a future call to this same contract (hence why we use address(this) as the to parameter. And since we’re going to trigger the fallback function we do not need to pass any callData so just pass an empty bytes array. The rest of the parameters are more or less tweakable and if you’re interested you can get started by looking at the EAC documentation.
The important thing to note is that what this function does is schedule a call to this contract for 7 days in the future. Next, we will explore what that call will do when it is executed by looking at the fallback function on this contract.
Protip: The fallback function on a smart contract is the code that is executed when the data does not match any on the method signatures. In Solidity we write the fallback function with nameless parentheses like so:
function () public {}.
function () public {
require(msg.sender == futureTx, "Scheduled Transaction must be the one calling this contract.");
tub.wipe(cdpId, payAmt);
uint256 tab = tub.tab(cdpId)
if (tab > 0) {
if (tab < payAmt) {
payAmt = tab;
}
newSchedule();
}
}What we’re essentially doing here is “wiping” or paying back the payAmt of Dai debt back into the CDP, then checking how much debt is left and if there is still outstanding debt, we schedule a new transaction by again calling the original newSchedule() function. The contract will keep recursively calling itself in this way every 7 days until it runs out of enough ether to cover gas costs of scheduling new transaction or when the debt is completely paid off.
Notably, this contract only needs the funds (Ether and Dai) at the moment the fallback function is triggered, so if you’re using this as a recurring payment method, you just need to make sure it’s funded before the trigger happens, and at other times it can be kept empty.
Use Case #2 — Schedule a routine collateral check
Scenario: You have an open CDP and you want to make sure that it remains safely collateralized as the price of Ether fluctuates.
Using the Ethereum Alarm Clock, we will set up a trustless and autonomous way to have a routine collateral check. We will go through this one a bit more quickly than the last example, but if you want to just skip to the code please scroll to the link at the bottom.
The contract to do this check looks pretty similar to the previous one, with the major difference being in the fallback function, where the actual execution logic lays.
function () public {
require(msg.sender == futureTx, "Scheduled Transaction must be the one calling this contract.");
if (!ITub(tub).safe(cdpId)) {
ITub(tub).lock(cdpId, 1 ether);
} else {
newSchedule();
}
}The major difference here is that we are checking if the CDP returns true or false from the safe() function. If it returns true, we reset the timer by scheduling a new transaction. If it returns false, we lock one Ether into the contract to provide more collateral for Dai.
Conclusion
I hope this blog post provides some context to using the EAC alongside the MakerDAO Dai system on the Ethereum blockchain. There is a huge amount of potential for developers to adopt this pattern to create complex contracts which will have logic that builds on other contracts to accomplish some neat functionality. We hope to see DApp ideas emerge from this blog post.
