I don’t have any specific preference.
Cycle 0: everything before Block 7512392 (confirmed < 7512392)
Bumi: 58500
Rau Cao: 187000
Manuel: 4500
galfert: 75000
Greg: 125500
Nick: 40500
haythem96: 13000
myamy: 500
Bilal Ghalib: 500
KaleabMezgebu: 500
Jon Stever: 1000
velasquez: 500
Ben Kero: 1500
hcs0: 500
Total: 509000
Cycle 1: Between Block 7512392 and 7684672 (confirmed >= 7512392 && confirmed <= 7684672)
Bumi: 201500
Rau Cao: 221500
Manuel: 200000
galfert: 202000
Greg: 206000
Nick: 210500
Total: 1241500
Cycle 2: Between Block 7684673 and 7859131 (confirmed >= 7684673 && confirmed <= 7859131)
Bumi: 500
Rau Cao: 19000
galfert: 1500
Greg: 8000
Nick: 5000
Total: 34000
I think either way there is a chance for confusion.
using the blocks from that months make it a bit easier to calculate imo.
Either way in the end would be fine with me, but I kind of agree that it would be more clear to think that if you get something merged in the evening of the 31st that it is included in that months calculations. However, that also brings up the question - is it possible that something that was picked up on the 1st of the next month might end up in the previous months calculations?
if we do that we just have to make sure that we wait at least a week (40320 blocks) to run the numbers for a cycle.
This is inevitable, as there is no date/time on a blockchain. You can only use block height for calculations, so the cycles will inevitably not exactly match dates in a Gregorian calendar.
How much exactly it shifts and how that feels like in practice is one of the things our experiment attempts to find out.
I have added all the numbers, added the 2nd cycle, and also edited some of the cells to calculate more numbers automatically. The only new data we have to enter for a new cycle now are the kredits confirmed within the cycle, as well as the new last block number.
I have also made sure that all manually added numbers are marked in purple, so it’s easy to see what’s what.
Here’s the source file for you to review:
contributor-grants.ods (22.6 KB)
And here’s an HTML export for your convenience:
https://ipfs.kosmos.org/ipfs/QmSySJNNKqwx5PTejo7eLgssptyZNZWCfxaGWhFsUUSeq4
1 Like
This is inevitable, as there is no date/time on a blockchain. You can only use block height for calculations, so the cycles will inevitably not exactly match dates in a Gregorian calendar.
Right. That’s kind of the point. In that we are just defining start and end points of blocks, so appending a set number of blocks after the last block of the month seems even more arbitrary than just saying the block that crosses 00:00 is the final block. But again, I would be fine with either way as long as it’s super clear what to expect.
EDIT: On second thought the same logic could be applied in reverse, so maybe there’s actually no point at all 
The point of the manual trial is to simulate what would happen in an actual DAO, in which this is not possible to program. Which is why I think that we definitely need to have one cycle be the same length as the previous one from now on.
I double checked the values going backward, summing contributors BTC values which matches up against the cycle grant budget, and also going down from the initial 0.3 BTC amount.
I found it a little overly complicate that we’re calculating the server fees for 6 months separately subtracted from the 6 month balance total, before we calculate amount that we use for the contribution payouts. What about treating the operations costs as just another entity in the payout list that is paid based on a fixed amount rather than kredits?
It would make the left side of the spreadsheet much more simplified. During each payout calculation we just determine the operations payout based on the fiat value per month at the current BTC rate.
0.3 / 6 = 0.5 each grant cycle
And the payout summary would include Operations at the top, with a fixed BTC amount based on the current value of (in this case) 200 EUR.
Not only would it simplify the left side, but also clearly define all outgoing transactions on the right side.
1 Like
The future expenses are only calculated once at the beginning, because in a real DAO there is no way to change that value monthly based on fiat exchange rates. It’s basically just giving a reasonable padding to always be able to pay for the actual reimbursements being submitted. But it’s only being done once to calculate the initial budget, because in a real DAO it would have to be adjusted from time to time based on voting I guess, and you wouldn’t want to have voting on something like that every month.
Transactions are waiting for review by two more signers in the co-signing pool:
Cycle #1: txid ad8568429402860ed6f1e71d7ef490d64b76008f989b6df203044e46a23fdf1d
Cycle #2: txid 2ce1a9d4ff47c9f60dc9f693fa33ccb2a92f608d0a761d476bf104b9ff927175
/cc @Core