dapphub / ds-pause

Schedule function calls that can only be executed once some delay has elapsed

ds-pause

delegatecall based proxy with an enforced delay

ds-pause allows authorized users to schedule function calls that can only be executed once some predetermined waiting period has elapsed. The configurable delay attribute sets the minimum wait time.

ds-pause is designed to be used as a component in a governance system, to give affected parties time to respond to decisions. If those affected by governance decisions have e.g. exit or veto rights, then the pause can serve as an effective check on governance power.

Plans

A plan describes a single delegatecall operation and a unix timestamp eta before which it cannot be executed.

A plan consists of:

• usr: address to delegatecall into
• tag: the expected codehash of usr
• fax: calldata to use
• eta: first possible time of execution (as seconds since unix epoch)

Each plan has a unique id, defined as keccack256(abi.encode(usr, tag, fax, eta))

Operations

Plans can be manipulated in the following ways:

• plot: schedule a plan
• exec: execute a plan
• drop: cancel a plan

Invariants

A break of any of the following would be classified as a critical issue. Please submit bug reports to [email protected].

high level

• There is no way to bypass the delay
• The code executed by the delegatecall cannot directly modify storage on the pause
• The pause will always retain ownership of it's proxy

admin

• authority, owner, and delay can only be changed if an authorized user plots a plan to do so

plot

• A plan can only be plotted if its eta is after block.timestamp + delay
• A plan can only be plotted by authorized users

exec

• A plan can only be executed if it has previously been plotted
• A plan can only be executed once it's eta has passed
• A plan can only be executed if its tag matches extcodehash(usr)
• A plan can only be executed once
• A plan can be executed by anyone

drop

• A plan can only be dropped by authorized users

Identity & Trust

In order to protect the internal storage of the pause from malicious writes during plan execution, we perform the actual delegatecall operation in a seperate contract with an isolated storage context (DSPauseProxy). Each pause has it's own individual proxy.

This means that plan's are executed with the identity of the proxy, and when integrating the pause into some auth scheme, you probably want to trust the pause's proxy and not the pause itself.

Example Usage

// construct the pause

uint delay            = 2 days;
address owner         = address(0);
DSAuthority authority = new DSAuthority();

DSPause pause = new DSPause(delay, owner, authority);

// plot the plan

address      usr = address(0x0);
bytes32      tag;  assembly { tag := extcodehash(usr) }
bytes memory fax = abi.encodeWithSignature("sig()");
uint         eta = now + delay;

pause.plot(usr, tag, fax, eta);

// wait until block.timestamp is at least now + delay...
// and then execute the plan

bytes memory out = pause.exec(usr, tag, fax, eta);

Tests

• pause.t.sol: unit tests
• integration.t.sol: usage examples / integation tests

ds-pause's Issues

Don't store execution data

see: 56a2517#r31903481

Changing delay

Changing the value of delay is not currently supported.

i assume this is a design decision based on the fact that it would be difficult to deal with the already scheduled proposals. If that's the case, maybe it's worth mentioning this in the README.

Have you considered allowing changes that strictly increase the delay? One benefit could be that, in cases when governance decides that all proposals in a ds-pause should be evaluated for longer, changing delay has less overhead than canceling each proposal and voting it back in on a different ds-pause.

execute should not be payable

I don't think the payable modifier should be in a function that can be called by anyone.
It's like leaving that door open to the public to add a custom value to the proposal elected. I know in most of cases will be just a waste of ETH value, but there might be actions tight to what is received in msg.value.
I think there shouldn't be a value at all or the value should be defined and saved at the moment the execution is scheduled by the owner. So basically the msg.value is part of the execution scheduled.

Code reuse

Any particular reason this code is copy/pasted instead of inheriting from DSProxy? We are going to give DSProxy some love soon and I see potential trouble if we make separate changes

ds-pause/src/pause.sol

Line 97 in 4f4086b

// delegatecall implementation from ds-proxy