search

67P / kredits-contracts

:warning: [MOVED] Smart contracts and JS API for Kosmos Kredits
https://gitea.kosmos.org/kredits/contracts
4 stars 4 forks source link

Import Operator contract #3

Closed bumi closed 6 years ago

bumi commented 6 years ago

The operator contract so far was managing the proposals.

We could think about refactoring the contract to use a delegatecall concept and to deploy a contract for every proposal.

fsmanuel commented 6 years ago

Is there a kind of list of proposal types? What are the base attributes of a proposal?

bumi commented 6 years ago

There is this schema: https://github.com/67P/kosmos-schemas/blob/master/schemas/contribution.json

raucao commented 6 years ago

That schema is only describing the actual contribution for a contribution proposal. I think the question is, if there are types of proposals that are not about contributions, right? For example a contract upgrade proposal.

fsmanuel commented 6 years ago

@skddc you are right! For example the voting on a new token contract or what ever could be a proposal as well. But without issuing tokens.

Does a contribution equals a proposal?

raucao commented 6 years ago

Yes, at the moment that's how it works. In fact, a proposal is purely a proposal to issue kredits. Everything else is meta data.

I think that's an important thing to keep in mind about blockchain development: we want the most basic data building blocks possible to live on-chain, and everything else should just be implementation details of clients. For example the chain doesn't really have to know why the kredits were issued, it only needs to reference an IPFS object that contains the reason. But the format of that object is entirely up to clients to define and interpret.

fsmanuel commented 6 years ago

I was talking to @bumi about that once. I like that concept and how you use IPFS to store the meta data/informations.

fsmanuel commented 6 years ago

This one is done, right?

bumi commented 6 years ago

yep, this is done.