eosdac / daccustodian Goto Github PK

This line:

Should be amended to: action(permission_level{_self, N(xfer)},

The account (configurable) dacauthority on jungle needs to have its permissions updated when an election is complete.

dacauthority has a permission called election which has action permissions for setauth, this should allow the code at dacelections to update the authority

assert when voting for non existing candidates and inactive candidates.
or at least don't store them in the vote array

Possible issue is failing a duplication check. If we add the payid into the memo, would that work?

Once we're ready to open up custodian voting (we talked on our call about allow for two weeks for custodians to register), we can deploy and updated contract that removes the return false.

We discussed in the future possibly having value with a boolean for disabling voting, but since this isn't yet defined in the constitution, we'll leave things as is for now.

It says in the Readme that the hash of the bio is on the candidates table but it is not there. It doesn't seem like it's actually part of the struct and the updatebio action doesn't actually emplace anything onto the table.

Also handle different token than the system token for payments

This and firecand is implemented and looks like it should work but seems to fail from cleos. Need to explore why.

I recently requested to become a custodian on the jungle testnet and I put in 260EOS and it was successfully submitted to the network. In the constitution, the current limit is 250 EOS unless it is changed in the voting directive.

Leave the owner permissions as is for now (i.e. Michael, Rob, Luke) until the elected Custodians are completely confident with the functioning of the DAC, then they can create a worker proposal to modify the code to include owner permission changing also. This bit of centralization in the beginning makes sense to protect the DAC and was discussed in the all-hands meeting and dev meeting on Sep 24th.

The code does some replaceVars stuff in the UI which seems to look for specific patterns.

For now this would just take pending pay actions from the pendingpay table based on the claimer but could be extended to included time delays on transactions and/or approval checks.

These should be configurable but will be set to a percentage of tokens having voted as well as there being >= 12 candidates with votes

This avoids some current limitations with the compiler and Scatter integrations.

Both this:

eosio-abigen daccustodian.hpp -contract lukedaccusto -output output/jungle/daccustodian/daccustodian.abi 

and this:

eosio-cpp -DTOKENCONTRACT='"lukedactoken"' -DTRANSFER_DELAY=20 -o output/jungle/daccustodian/daccustodian.wasm daccustodian.cpp -abigen

create an abi file which is basically empty. Any idea what I'm doing wrong?

Thanks!

I'm working to get an example DAC up and running on Jungle and I noticed I can't call the updateconfig method because it uses the defaults which are set as dacauthority. I talked it through with michael and this seems like the best place to make an improvement: https://github.com/eosdac/daccustodian/blob/master/config.cpp#L4

Something like:

if (...config has been updated, config table isn't empty, etc...) {
require_auth(configs().authaccount);
} else {
require_auth(_self);
}

As it is now, I have to manually adjust the hpp file to change the default to my own dac authority account in order to update the config.

Tested votecust and it doesn't seem like the candidates table gets updated. The votes table does get updated though. Is this normal?