encoding.txt

The encoded parameters that will be sent to the scheduler 
smart contract and stored in IPFS looks like this:

```
0x00020000000000000000000000007ed1e469fcb3ee19c0366d829e291451be638e59000000000000000000000000000000000000000000000000000000000000000a0000000000000000000000000000000000000000000000000000000000000014000000000000000000000000000000000000000000000000000000000000001e00000000000000000000000000000000000000000000000000000000000000280000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000003c0000000000000000000000000000000000000000000000000000000000000046
```

The first two bytes are the temporalUnit which must
be either `0001` or `0002` and stands for the unit which 
was used to set the parameters for this transaction. If 
the first two bytes are `0001` then the parameters
will be parsed as _block number_ otherwise if the 
first two bytes are `0002` the parameters will be parsed 
to refer to _unix epoch timestamps_ as they are recorded in 
Ethereum blocks.

Following that the rest of the bytes are simply the 
ABI encoding of the parameters that will be sent, in order.

bytes   1 - 32   -  temporalUnit
bytes  33 - 64   -  recipient
bytes  65 - 96   -  value
bytes  97 - 128  -  callGas
bytes 129 - 160  -  gasPrice
bytes 161 - 192  -  executionWindowStart
bytes 193 - 224  -  executionWindowLength
bytes 225 - 256  -  bounty
bytes 257 - 288  -  fee
bytes 289 - 320  -  conditionDest
bytes 321 - 352  -  callData loc
bytes 353 - 384  -  conditionCallData loc
bytes ... - ...  -  callData
bytes ... - ...  -  conditionCallData