CIPs
CIPs copied to clipboard
cip: Conviction Voting Template
cip: <to be assigned>
title: Conviction Voting Template
author: Joel Thorstensson (@oed)
discussions-to: <URL of the Github issue for this CIP (if this is a PR)>
status: Idea
category: Standards
type: RFC
created: 2021-02-28
This is still a work in progress. Will add more context to these schemas!
Simple Summary
This CIP describes a template that can be used to create off-chain conviction voting dapps.
Abstract
Abstract goes here.
Motivation
Fix me :)
Specification
Definition content
Deployment: Deploy your own.
{
"name": "Conviction Voting Dapp",
"description": "Voting data for my dapp",
"schema": "<convictions-schema-docid>",
"config": {
"context": "<caip19-asset-id>"
}
}
Proposal Schema
Deployment: <proposal-schema-docid>
{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"title": "Convictions",
"properties": {
"context": {
"type": "string"
},
"title": {
"type": "string"
},
"currency": {
"type": "string"
},
"amount": {
"type": "number"
},
"beneficiary": {
"type": "string"
},
"description": {
"type": "string"
},
"url": {
"type": "string"
}
},
"additionalProperties": false,
"required": [
"context",
"title",
"currency",
"amount",
"beneficiary",
"url"
]
}
Convictions Schema
Deployment: <convictions-schema-docid>
{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"title": "Convictions",
"properties": {
"context": {
"type": "string"
},
"supply": {
"type": "number"
},
"proposals": {
"type": "array",
"items": {
"$ref": "#/definitions/proposals"
}
},
"convictions": {
"type": "array",
"items": {
"$ref": "#/definitions/convictions"
}
}
},
"additionalProperties": false,
"required": [
"context",
"proposals",
"convictions"
],
"definitions": {
"proposals": {
"type": "string",
"$id": "ceramic://doc",
"$ceramicSchema": "<proposal-schema-docid>",
"maxLength": 150
},
"convictions": {
"type": "object",
"properties": {
"proposal": {
"type": "string",
"$id": "ceramic://doc",
"$ceramicSchema": "<proposal-schema-docid>",
"maxLength": 150
},
"allocation": {
"type": "number"
}
},
"required": [
"proposal",
"allocation"
]
}
}
}
Conviction State Schema
Deployment: <convictions-state-schema-docid>
{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"title": "ConvictionState",
"properties": {
"context": {
"type": "string"
},
"blockHeight": {
"type": "number"
},
"supply": {
"type": "number"
},
"participants": {
"type": "array",
"items": {
"$ref": "#/definitions/participants"
}
},
"proposals": {
"type": "array",
"items": {
"$ref": "#/definitions/proposals"
}
}
},
"additionalProperties": false,
"required": [
"context",
"supply",
"participants",
"proposals"
],
"definitions": {
"participants": {
"type": "object",
"properties": {
"account": {
"type": "string"
},
"balance": {
"type": "number"
},
"convictions": {
"type": "string",
"$id": "ceramic://doc",
"$ceramicSchema": "<convictions-schema-docid>",
"maxLength": 150
}
},
"required": [
"account",
"balance",
"convictions"
]
},
"proposals": {
"type": "object",
"properties": {
"proposal": {
"type": "string",
"$id": "ceramic://doc",
"$ceramicSchema": "<proposal-schema-docid>",
"maxLength": 150
},
"totalConviction": {
"type": "number"
},
"triggered": {
"type": "boolean"
}
},
"required": [
"proposal",
"totalConviction",
"triggered"
]
}
}
}
Rationale
Fix me :)
Backwards Compatibility
N/A
Implementation
Fix me :)
Security Considerations
Security considerations go here.
Copyright
Copyright and related rights waived via CC0.
Check out the thoughts here, and in the other issues... lots of good debates around UX
https://github.com/1Hive/conviction-voting-app/issues/52
Awesome that you are pushing the UX work needed to make CV usable @GriffGreen 🙌
This CIP is mostly aimed at creating a solid data data layer for CV. If we manage to do this there could potentially be multiple different frontends that display the CV data in different ways based on preference / usability considerations.
@oed what do you think about adding a blockNumber
or blockHeight
parameter to the root of the state document? I think it'd be a great way to make all the data in state completely verifiable, since one could then verify all the other data at the prescribed block height.
"blockHeight": {
"type": "number"
}
@topocount Yeah, that's a good addition. You could a rough idea of when the snapshot was made from the subsequent anchor commit, but it wouldn't be precise. Updating the first post!
@oed what do you think about adding a
blockNumber
orblockHeight
parameter to the root of the state document? I think it'd be a great way to make all the data in state completely verifiable, since one could then verify all the other data at the prescribed block height."blockHeight": { "type": "number" }
@oed Could this cause any issues like we've been seeing with the blockNumber in anchor commits, where it could diverge from the on-chain state if there's a block reorg?
@stbrody no this is more about when the conviction computation service sampled the data from the blockchain. Which is mostly independent from anchor commits.
Currently there is a beneficiary
and amount
which indicates there is a transfer function call to a contract from the Oracle.
Why not use an array of actions for all the contract methods to be triggered if the proposal succeeds?
actions: [{
contract: "contract-address",
method: "mint",
args: ["to-address", "amount"]
}, {
contract: "another-address",
method: "transfer",
args: ["to-address", "amount"]
}]