Once a cycle is processed the votes are aggregated in the cycle table and can be removed from RAM.

The frontend (Dashboard) currently assumes this data to be available so had to be adjusted. This info can either be removed from the interface or be served by a backend

Feature

Enable posting of proofs to proposals that indicate that the author has finished the implementation.

Description

At the moment the final state of an accepted proposal is to be executed, which means the funding payment has been made by the DAO. There is no way to communicate on-chain that a proposal has been finished by the author.

Being able to proof finalizing a proposal on-chain is useful for several reasons:

• It signals to all DAO members that you are finished
• There is a proof of date/time and IPFS content hash of when you were finished
• It's an anchor point that can be later used for attesting delivery by the DAO (e.g. for payout on delivery)
• Proposal proofs indicate the track record of a member. Posting consistent and satisfying proofs should make it more easy to get your proposals voted in.

Steps

• Add post_proof action that accepts an IPFS hash
• Implement frontend in https://github.com/effectai/effect-dashboard
• Get approval for deployment with a proposal

This relayer will be an HTTP service that is responsible for several features that require some centralized coordination in the network:

Urgently:

• User onboarding
• Backups of on-chain task results

In the future:

• Encryption proxy
• Data storage
• Become a P2P network

Feature

Given a batchid the corresponding batch needs to be deleted.

Description

What should the limitations be?
Only the owner of the batch should be able to delete the batch.
What should happen with the rest of the efx stored in the batch?

This also raises the question about what to do with the funds in the batch.
What if there are users who have completed tasks in the batch, but have not yet claimed their task reward.
Where will the funds be stored until the user has claimed the task reward?

Or maybe the requester can only pause the batch, until all users have claimed their rewards.

Steps

The implementation should be relatively easy, there should be a couple of other examples where this is already implemented. Look at this one as an example:

There should be a time limit on posting swap transactions so that used RAM can be freed at some point in time.

I think it makes most sense to perform this conversion inside the smart contract. Currently the posttx step is assumed to receive a 1e4 int formatted amount. When it receives a raw NEO amount (1e8) it will have to round it to lower precision.

Feature

Refund deposited EFX when deleting a bach

Description

When removing a batch the EFX currently gets stuck in the force account. It should be possible to get these funds back when removing a batch.

Steps

TBD

Feature

A percentage of the task rewards on the platform should be collected as a network fee.

Description

Effect Network will implement a network fee that is collected by the DAO to sustain the development of the network.

With the mainnet release all the smart contract technology is in place to implement this in a decentralized way. The goal is to have the fees be collected completely autonomous (so it happens automatically, no manual actions) and as real-time as possible.

The fee parameter will be an extremely important parameter for the network - as both workers and requesters will be impacted by the value.

Technical remarks

• Effect Network operates on it's own virtual account system, which means fees are collected in vEFX, and the feepool.efx must have a vaccount to collect funds.
• After a task is completed on the platform there is delay before it can be paid out. This delay gives requesters time to validate a users work. This means that fee collection must also be delayed until the payout of the work
• The percentage of fees collected will be a global configuration that can be set by the DAO with a proposal
• Technically, fees will come from the user end. Example: if a user earned 1,000 EFX in a batch and clicks payout, 900 EFX is sent to the user and 100 EFX is sent to the feepool
  • We could change the user interfaces to account for the fees, so the user won't be surprised
  • We have considered swapping this, and make the requester pay the fee on task creation. But that does not play nicely as requesters should be able to cancel outstanding tasks that have not been completed.

Steps

• Implement a configuration parameter with the global network fee and the network destination vaccount
• In the payout action, split the payout between the worker and the network fee
• Implement a withdraw function in the feepool that will convert the vEFX into real EFX so it gets registered as reward

A recent proposal was accepted to burn a part of the feepool before reward distribution:
https://dashboard.effect.ai/proposals/17

This feature needs to be researched and implemented in the feepool smart contract.

By voting yes on this proposal, you endorse the team establishing a toggleable mechanism in the smart contract that can burn 50% of network fees prior to distribution when enabled (or publishing a proposal on such a thing if this proposal is insufficiently technical). Initially, it will be disabled and another proposal will be required to enable network fee burning.

the current implementation of releasetask makes use of a for loop to get the vaccount id of the campaign owner. This for loop is too excessive logic wise, it should be possible to get the same result with the find method of the multi_index with the second index ("token" on vaccount).

Feature

It should be possible to create campaign with 0 rewards.

At the moment this is not possible (there is a silent failure in the UI, with an error printed to the console related to "transfer positive quantity)"

This is most likely because the smart contract tries to send a 10% fee (which amounts to 0). The fee should be skipped for free campaigns.

So, I've created a campaign with a batch of 4 tasks.

r = campaign.create_batch(
e,
0, # campaign id = 0
[
{ 'image': 'https://ipfs.effect.ai/ipfs/QmVuSBpoSEUdHmB2owcbAQnModzfcbEme6w6nCkJDDJcy4'},
{ 'image': 'https://upload.wikimedia.org/wikipedia/commons/thumb/8/89/Attentive_%2815531899006%29.jpg/1920px-Attentive_%2815531899006%29.jpg' },
{ 'image': 'https://upload.wikimedia.org/wikipedia/commons/thumb/4/40/Comparison_carbon_dioxide_water_phase_diagrams.svg/1024px-Comparison_carbon_dioxide_water_phase_diagrams.svg.png' },
{ 'image': 'https://upload.wikimedia.org/wikipedia/commons/5/54/Borphase.jpg' }
],
'300.0904 EFX', # reward, thus => tasks * reps * 24.4242 EFX = reward
2, # reps
)

But as I go through it, at the end, I still get a reservation with a task_idx === 4

{
"id": 4,
"task_idx": 4,
"account_id": 3,
"batch_id": 0,
"reserved_on": "2023-10-11T12:37:05",
"campaign_id": 0
}

So, I think it gets incremented by 1 too many at the end.

Feature

BSC users should pay an extra fee when receiving a payout for their work.
This fee is to cover the use of the relayer.

Description

This covers the following DAO proposal: https://dao.effect.network/proposals/141

Steps

• Wait for the DAO proposal to work out the details

Feature

Automate the processing of a finished cycle in 1 action, including the creation of a new cycle, execution of recycle strategy, and vote counting.

Description

Rounding up a cycle in EffectDAO is currently a bit involved as it requires 4 actions: a new cycle must be created, the recycle strategy must be executed, the proposals have to be processed, and the active cycle must be updated.

This process can be done in 1 action handled mostly by the smart contract. This will reduce potential mistakes and cycle delays, while sacrificing a bit of flexibility. After 11 cycles the flexibility of executing the steps by hand is no longer needed.

Steps

• Implement the recycle strategy in the daoproposals contract
• Automatically create new cycles and fill in the start date and budget (budget can be added to the config)
• Execute the 4 steps in processcycle

Feature

Users should be able to select multiple tokens as payment for their proposal, like NFX or EOS, instead of just EFX.

Description

Effect DAO currently supports 1 currency as payment for a proposal. The smart contract design already supports multiple tokens but for simplicity this has been disabled. In recent DAO calls we discussed the need to allow NFX and EOS to be paid as rewards.

This proposals smart contract will need a small update to enable support for multiple tokens.

A side note on security: it should not cause much problems to allow arbitrary currencies. If someone adds currencies the DAO does not own this should be detected by the UI so people won't vote on it, and the proposal will not be able to execute anyways. There is a small risk of the spent map of the cycle to consume a lot of RAM, but this only gets populated for approved proposals anyways.

Steps

• Uncomment, finish, and thoroughly test multi-currency support in processcycle:
  https://github.com/effectai/effect-network/blob/master/contracts/proposals/proposals.cpp#L176

• Add e2e tests with multiple pays

• Implement frontend feature in effect-dao repo

Embeds don't look nice, would be nice to have opengraph metadata available on all the dashboard pages and proposal pages so things look nice when posting a link in social media.

This is the implementation of Proposal-22: https://dashboard.effect.ai/proposals/22

The goal is to create a dynamic vote weight system where your vote weight is determined by EFX Power and staked NFX. Ranks will be removed from EffectDAO and the minimum entry for voting will be lower.

The vote weight formula will become:

vote_weight = min(staked_nfx, efx_power / 20)

A quick overview of the changes that are needed:

• Update get_vote_power in effect-dao-shared.hpp and remove references to ranks.
• Updates to the EffectDAO frontend:
  • Replace ranks with the new formula.
  • Solve inefficiencies with fetching votes and calculating results.
  • The frontend will require quite a few layout changes.
• Compile and deploy effect-proposal and effect-dao contracts.
• effect-proposals::processcycle will have to be tested and redesigned to support a large number of voters.

New vote distribution

This proposal will make a lot more DAO member eligible to vote but also makes it easier for large token holders to accumulate more vote weight. A quick analysis of the vote distribution looks healthy but we should keep paying attention to keeping the system fair. A quick reference to the current and new vote distributions:

• Chart of current vote distribution
• Chart of vote distribution after this proposal

Check method to process cycles

With the new distribution there will be a lot more users in the DAO. It can also grow quicker because of the low entry barrier. The theoretical maximum number of Guardians right now is 1,000 (with a practical limit of around 400). With the new system there can be over a million Guardians.

The process cycle action has to become scalable. We can start by processing each proposal independently in an action, which will make process cycle trivial. Secondly the new process proposal action should be able to work in batches so it can run over several actions.

Testing

The most important component to test is the correctness of fee distribution. This update should be accompanied by extensive e2e tests for a range of scenarios.

After an unstake action, the contract can send a deferred refund transaction after the unstaking time. Then users don't have to manually trigger a refund. A manual refund will still be possible in case the deferred transaction gets dropped.

We're currently compiling with cdt 1.5

Probably there'll be quite some changes: https://github.com/EOSIO/eosio.cdt/releases/tag/v1.6.0

The data field of the submission struct in force.hpp should be optional. At the moment there is no way to make a distinction between a reserved task and an empty submission.

If you click on 'Edit this page in GitHub' link at the bottom of this page: (and a few others) https://docs.effect.network/Effect-Network/about.html , it gives you this 404 error: The 'effectai/effect-network' repository doesn't contain the 'docs/Effect-Network/dapp-ecosystem.md' path in 'master'.

Feature

It should be possible to change to owner of a campaign

Description

This action should only be callable by the current campaign owner.

A use case is to delegate your campaign to the task proxy temporarily. This is an important feature for allowing anyone to post batches.

Steps

• Implement setowner action (or add this as a parameter to update)

https://dashboard.effect.ai/proposals/20

Feature

Figure out how to add a method to the sdk that will let users easily add their campaign to efxtaskproxy.

Either it is a checkbox in the campaign creation form, or programmatically in the sdk.

Probably an action needs to be created to adjust the permissions on eosio.

An alternative is to let the owner of the campaign transfer their ownership of the campaign to Effect Network's efxtaskproxy.

The problem here is that they will not be able to edit their campaigns anymore.

This feature needs to be thought out further to make sure that it is a solid process that users and devs can rely on.

Description

Steps

Feature

As a user I want to get back the RAM for old submissions

Description

Submissions for batches that are no longer active should be removed the the EOS table to clear RAM

The token contract and symbol are now passed as an argument to issue during swap.

This is not save. For a more general purpose contract the symbol and token contract should be linked to the asset id of the transaction. We have to be careful with validating the symbol precision if we allow for dynamic tokens.

A more straightforward solution for now is to hardcode the EFX token for the current swap

Currently, to post NEO transactions in posttx, the active permission of the swap account is required.

It's probably more convenient if we allow different, assigned, accounts to use posttx

We should either disable pausing batches or disable the batching fuding check if one is being resumed

Feature

The unstake_delay in the staking contract should be adjustable

Description

With this action the DAO could adjust the unstake time of EFX and NFX through an ATP.

Steps

• Similar to the update action but to update the stats table of a token

Effect Force Smart Contract Action payout action.
In the effect force payout action, currently it payouts for one payment at a time, is it better to calculate the amount and send it in one vtransfer.

void force::payout(uint32_t account_id,
                   std::optional<eosio::signature> sig) {
  payment_table payment_tbl(_self, _self.value);
  payout_params params = {13, account_id};
  require_vaccount(account_id, pack(params), sig);

  auto payment_idx = payment_tbl.get_index<"acc"_n>();
  auto itr_start = payment_idx.lower_bound(account_id);
  auto itr_end = payment_idx.upper_bound(account_id);
  uint64_t amount = 0;
  static bool got_sym;
  eosio::extended_symbol sym;

  for (; itr_start != itr_end;) {
    auto& payment = *itr_start;
    bool time_is_after_period = compare_time(payment.last_submission_time.sec_since_epoch(), date_in_sec);

    if(!got_sym) {
      got_sym = true;
      eosio::check(payment.pending.get_extended_symbol().get_symbol().is_valid(), "symbol is not valid.");
      sym = payment.pending.get_extended_symbol();
    }
    if (time_is_after_period == true) {
      amount += payment.pending.quantity.amount;
      itr_start = payment_idx.erase(itr_start);
    }
  }
  eosio::check(amount != 0, "amount is zero.");
  eosio::extended_asset payment_asset = eosio::extended_asset(
    amount,
    sym
  );
  eosio::check(payment_asset.get_extended_symbol().get_symbol().is_valid(), "symbol is not valid.");
  action(
    permission_level{_self, "active"_n},
    _config.get().vaccount_contract,
    "vtransfer"_n,
    std::make_tuple((uint64_t)_config.get().force_vaccount_id, (uint64_t)account_id, payment_asset, std::string(""), NULL, NULL))
  .send();
}

Currently the stake contract pays all RAM for stakes. By having users open a 0 balance entry before they can stake they can pay the RAM for their own stakes

Feature

A DAO proposal should be able to execute a user defined EOS transaction.

Description

If a proposal passes it should be possible to execute an eosio.msig transaction owned by the DAO. This transaction will bear the [email protected] permission, which will allow the DAO to make restricted transaction like updating code or modifying network parameters.

[To be refined]