Load contributions from Contribution contract/storage #20

New Issue

2017-06-10T17:37:59Z

raucao commented

2017-06-10 17:37:59 +00:00

(Migrated from github.com)

~~As we'll lose the proposals themselves every time we update the Kredits contract, we need to show recent/past contributions from the Token contract data instead.~~

@bumi I'm not quite sure how we can implement this. Could you provide a rough outline of we'd have to change?

Update: we're in the process of implementing ERC721 tokens for contributions, so all data will move to a Contribution contract/storage. See https://github.com/67P/kredits-contracts/issues/52

<del>As we'll lose the proposals themselves every time we update the Kredits contract, we need to show recent/past contributions from the Token contract data instead. @bumi I'm not quite sure how we can implement this. Could you provide a rough outline of we'd have to change?</del> Update: we're in the process of implementing ERC721 tokens for contributions, so all data will move to a Contribution contract/storage. See https://github.com/67P/kredits-contracts/issues/52

raucao commented

2017-07-05 14:50:36 +00:00

(Migrated from github.com)

Note: we need to use the Token contract events for this.

raucao commented

2018-04-16 11:35:12 +00:00

(Migrated from github.com)

@fsmanuel @bumi Is this already solved with your changes by any chance?

bumi commented

2018-04-16 15:01:48 +00:00

(Migrated from github.com)

nope, not yet.

fyi. was also thinking about looking into the ERC721 non-fungible token standard to see if that could be helpful for our case... which would mean one gets one fungible ERC20 token that can be transferred and one erc721 non-fungible token that represents the contribution.
But even though this might be a bit more flexible and a bit more the ethereum-way of doing it, it might be more complicated.

nope, not yet. fyi. was also thinking about looking into the [ERC721](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-721.md) non-fungible token standard to see if that could be helpful for our case... which would mean one gets one fungible ERC20 token that can be transferred and one erc721 non-fungible token that represents the contribution. But even though this might be a bit more flexible and a bit more the ethereum-way of doing it, it might be more complicated.

raucao commented

2018-04-16 15:31:19 +00:00

(Migrated from github.com)

was also thinking about looking into the ERC721 non-fungible token standard to see if that could be helpful for our case... which would mean one gets one fungible ERC20 token that can be transferred and one erc721 non-fungible token that represents the contribution.

From what I see from their doc, those are also transferable though.

In any case, this issue was about the contribution history, not the leaderboard. But yer, for the leaderboard we need to show the tokens issued instead of the tokens currently held.

> was also thinking about looking into the ERC721 non-fungible token standard to see if that could be helpful for our case... which would mean one gets one fungible ERC20 token that can be transferred and one erc721 non-fungible token that represents the contribution. From what I see from their doc, those are also transferable though. In any case, this issue was about the contribution history, not the leaderboard. But yer, for the leaderboard we need to show the tokens issued instead of the tokens currently held.

raucao commented

2018-06-07 14:48:43 +00:00

(Migrated from github.com)

The situation here might have changed, because the proposals are not destroyed anymore. Correct, @bumi?

Edit: but also, the contract itself needs to have access to who received which amount (i.e. who contributed how much) during a given time frame. Not sure the contract can look at events for that.

The situation here might have changed, because the proposals are not destroyed anymore. Correct, @bumi? Edit: but also, the contract itself needs to have access to who received which amount (i.e. who contributed how much) during a given time frame. Not sure the contract can look at events for that.

raucao commented

2018-07-20 12:26:12 +00:00

(Migrated from github.com)

Now that we have a whole new design, with contributions as ERC721 tokens, which store the kredits amount that can be withdrawn as ERC20 token, this issue has changed somewhat. Updating the title and original description to reflect the new adaptations to be implemented once the contracts are ready.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: kredits/kredits-web#20