Introduce concept of financial contributions #25

New Issue

raucao · 2018-04-11T21:01:03Z

raucao commented

2018-04-11 21:01:03 +00:00

(Migrated from github.com)

I was thinking about how to best handle financial contributions, both in terms of potential voting rights and kredits issued. So far, I have come to the conclusion that they probably should not get any voting rights, because otherwise you can just straight-up buy influence. On the other hand, as a company you don't really want to sponsor things very much, if you get nothing in return.

I think we should give financial contributors some kind of visibility in return (optional, just if they so wish), similar to how e.g. OpenCollective shows sponsors on a project page. Other projects used additions to commit messages in the past, and I'm sure there are plenty of other options we can come up with.

But in general, this would mean not just issuing normal kredits for financial contributions, but somehow treating them different. Otherwise the eventual voting rights would be granted as well, because any such contracts cannot access the contribution kind in the IPFS doc from their code.

I was thinking about how to best handle financial contributions, both in terms of potential voting rights and kredits issued. So far, I have come to the conclusion that they probably should not get any voting rights, because otherwise you can just straight-up buy influence. On the other hand, as a company you don't really want to sponsor things very much, if you get nothing in return. I think we should give financial contributors some kind of visibility in return (optional, just if they so wish), similar to how e.g. OpenCollective shows sponsors on a project page. Other projects used additions to commit messages in the past, and I'm sure there are plenty of other options we can come up with. But in general, this would mean not just issuing normal kredits for financial contributions, but somehow treating them different. Otherwise the eventual voting rights would be granted as well, because any such contracts cannot access the contribution kind in the IPFS doc from their code.

raucao commented

2018-07-20 12:40:05 +00:00

(Migrated from github.com)

With the new design, this can now be implemented by minting ERC20 kredits and selling them for ETH, while contributions and voting weight is based on the ERC721 contribution token.

bumi commented

2019-04-01 08:47:42 +00:00

(Migrated from github.com)

Yes, with the new design ERC20 Kredits can be minted and sold; And contributions are real project contributions.
Though we need to think about the process:
Currently a the mintFor function also requires a contributionId (can be e.g. 0) that gets logged.
The main question is: who is allowed to call the mint function. Right now it is the Contribution contract and the deployment account. The deployment account should get that right removed at some point).
We could imagine an additional contract or some voting contract that would be used to issue tokens without a contribution. Or we could write a crowd sell contract that has the right to mint tokens and people can just send money to that contract and get kredits in return.

Yes, with the new design ERC20 Kredits can be minted and sold; And contributions are real project contributions. Though we need to think about the process: Currently a the `mintFor` function also requires a contributionId (can be e.g. 0) that gets logged. The main question is: who is allowed to call the mint function. Right now it is the Contribution contract and the deployment account. The deployment account should get that right removed at some point). We could imagine an additional contract or some voting contract that would be used to issue tokens without a contribution. Or we could write a crowd sell contract that has the right to mint tokens and people can just send money to that contract and get kredits in return.

raucao added the

idea

label 2022-07-16 15:17:49 +00:00

Sign in to join this conversation.