Add token vote interfaces

This commit is contained in:
lash 2023-05-07 19:01:06 +01:00
parent c2c9581dab
commit 2eba8c6254
Signed by: lash
GPG Key ID: 21D2E7BB88C2A746
7 changed files with 156 additions and 5 deletions

View File

@ -8,9 +8,12 @@
CIC smart contracts are implemented using the @emph{solidity} programming language for the (Ethereum Virtual Machine (EVM). CIC smart contracts are implemented using the @emph{solidity} programming language for the (Ethereum Virtual Machine (EVM).
@section Inherited ERC definitions @section Adopted standards
@subsection Direct use @subsection Signing
@subsection ERC - Direct use
The following well-known solidity interfaces are used directly. The following well-known solidity interfaces are used directly.
@ -23,6 +26,10 @@ The following well-known solidity interfaces are used directly.
@item @item
@uref{https://eips.ethereum.org/EIPS/eip-173, ERC173 - Contract Ownership Standard} @uref{https://eips.ethereum.org/EIPS/eip-173, ERC173 - Contract Ownership Standard}
@item @item
@uref{https://eips.ethereum.org/EIPS/eip-191, ERC191 - Signed Data Standard}
@item
@uref{https://eips.ethereum.org/EIPS/eip-712, ERC712 - Typed structured data hashing and signing}
@item
@uref{https://eips.ethereum.org/EIPS/eip-721, ERC721 - Non-Fungible Token Standard} @uref{https://eips.ethereum.org/EIPS/eip-721, ERC721 - Non-Fungible Token Standard}
@item @item
@uref{https://eips.ethereum.org/EIPS/eip-5007, ERC5007 - Time NFT (EIP-721 Time Extension)} @uref{https://eips.ethereum.org/EIPS/eip-5007, ERC5007 - Time NFT (EIP-721 Time Extension)}
@ -31,10 +38,11 @@ The following well-known solidity interfaces are used directly.
@end itemize @end itemize
@subsection Partial use @subsection ERCs Partial use
The following well-known solidity interfaces are partially implemented in CIC native interfaces. The following well-known solidity interfaces are partially implemented in CIC native interfaces.
@itemize @dfn @itemize @dfn
@item @item
@uref{https://eips.ethereum.org/EIPS/eip-5679, ERC5679 - Token Minting and Burning} (See @code{Minter}, @code{Burner}) @uref{https://eips.ethereum.org/EIPS/eip-5679, ERC5679 - Token Minting and Burning} (See @code{Minter}, @code{Burner})
@end itemize @end itemize
@ -66,4 +74,8 @@ The following well-known solidity interfaces are partially implemented in CIC na
@include seal.sol.texi @include seal.sol.texi
@include tokenvend.sol.texi
@include tokenvote.sol.texi
@include writer.sol.texi @include writer.sol.texi

View File

@ -0,0 +1,21 @@
@subsection TokenVend
This interface defines the mechanism for which a specific ERC20 token may be exchanged for a different ERC20 token.
A typical use-case is generation of voting tokens based on a momentary voucher balance. This is especially useful if the original ERC20 token is subject to decay (demurrage).
The tokens used for exchange @strong{SHOULD} be locked for the full duration of holding the vended tokens.
The withdrawal function may or may not allow partial withdrawals.
@table @dfn
@item ERC165 Interface identifier
@include ../../build/TokenVend.interface
@item Solidity interface definition
@include ../../build/contract_TokenVend.texi
@item Reference implementations
@itemize
@item
@uref{git://holbrook.no/erc20-vend.git,}
@end itemize
@end table

View File

@ -0,0 +1,23 @@
@anchor{token_vote}
@subsection TokenVote
Execute elections with granular ERC20 token votes.
A proposal submitted for vote may or may not contain multiple options. If multiple options are available, an ERC20 token holder may distribute its vote among the options with the granularity of the token balance.
Voted tokens @strong{SHOULD} be locked until the voting has finalized.
Finalization of voting should be callable by anyone.
@table @dfn
@item ERC165 Interface identifier
@include ../../build/TokenVote.interface
@item Solidity interface definition
@include ../../build/contract_TokenVote.texi
@item Reference implementations
@itemize
@item
@uref{git://holbrook.no/evm-tokenvote.git,}
@end itemize
@end table

View File

@ -4,9 +4,9 @@ A complement to ERC173, which allows definition of a class of super-users for a
A super-user address may perform @emph{more} actions than a "normal" address, aswell as @emph{some} actions normally limited to the @emph{contract owner}. A super-user address may perform @emph{more} actions than a "normal" address, aswell as @emph{some} actions normally limited to the @emph{contract owner}.
No super-user should be able to perform actions that @emph{contract owner} cannot perform. If an @emph{contract owner} is defined, No super-user should be able to perform actions that @emph{contract owner} cannot perform.
Typically, only the @emph{contract owner} can add or remove a super-user. Typically, only the @emph{contract owner}, if it is defined, can add or remove a super-user.
Some use-case examples of super-user actions include: Some use-case examples of super-user actions include:

23
solidity/Offline.sol Normal file
View File

@ -0,0 +1,23 @@
pragma solidity >=0.6.12;
// Author: Louis Holbrook <dev@holbrook.no> 0826EDA1702D1E87C6E2875121D2E7BB88C2A746
// SPDX-License-Identifier: AGPL-3.0-or-later
// File-version: 1
interface IOffline {
// Verify signer and data
// Check input assuming signature is valid against contract instance.
function isOfflineValid(address _signer, bytes memory _data) external view returns(bool);
// Verify signature against data, and isOfflineValid() against data and signer (as validator)
// Signature must be ERC191 version 0x00 with contract instance as validator.
function verifyOfflineRequest(bytes memory _data, bytes memory _signature) external view returns(bool);
// Change state if signature and signer is valid.
// Call verifyOfflineRequest and:
// - revert if it returns false.
// - return 0 if state is changed according to the request.
// - return any other valid to indicate an application specific error.
function executeOfflineRequest(bytes memory _data, bytes memory _signature) external returns(uint256);
}

16
solidity/TokenVend.sol Normal file
View File

@ -0,0 +1,16 @@
pragma solidity >=0.6.12;
// Author: Louis Holbrook <dev@holbrook.no> 0826EDA1702D1E87C6E2875121D2E7BB88C2A746
// SPDX-License-Identifier: AGPL-3.0-or-later
// File-version: 1
interface ITokenVend {
// A new vended token has been created.
event TokenCreated(uint256 indexed _tokenIdx, uint256 indexed _supply, address _token);
// Create corresponding vended tokens for the control token balance of the caller.
function getFor(address _token) external returns (uint256);
// Recover control tokens that were used to retrieve the corresponding vended tokens.
function withdrawFor(address _token) external returns (uint256);
}

56
solidity/TokenVote.sol Normal file
View File

@ -0,0 +1,56 @@
pragma solidity >=0.6.12;
// Author: Louis Holbrook <dev@holbrook.no> 0826EDA1702D1E87C6E2875121D2E7BB88C2A746
// SPDX-License-Identifier: AGPL-3.0-or-later
// File-version: 1
interface ITokenVote {
// A new proposal has been created.
event ProposalAdded(uint256 indexed _blockDeadline, uint256 indexed voteTargetPpm, uint256 indexed _proposalIdx);
// A proposal vote has been completed.
// The proposal is identified by the serial number in _proposalIdx. It is up to the implementer to define how the proposal should be retrieved by index.
// The proposal result may be in one of three states:
// * Ratified (_cancelled == false, _insufficient == false)
// * Cancelled (_cancelled == true, _insufficient == false)
// * Not reached quorum (_cancelled == false, _insufficient == true)
event ProposalCompleted(uint256 indexed _proposalIdx, bool indexed _cancelled, bool indexed _insufficient, uint256 _totalVote);
// Propose a new vote.
// Voting is active until one of:
// * total cancel vote reach quorum (_targetVotePpm, ppm = parts-per-million).
// * _blockWait blocks from now.
function propose(bytes32 _description, uint256 _blockWait, uint24 _targetVotePpm) external returns (uint256);
// Same as propose(...), but provide options to vote on.
function proposeMulti(bytes32 _description, bytes32[] memory _options, uint256 _blockWait, uint24 _targetVotePpm) external returns (uint256);
// Get proposal option. Assumes that proposal was created with proposeMulti(...)
function getOption(uint256 _proposalIdx, uint256 _optionIdx) external view returns (bytes32);
// Get vote count for the given option.
// If proposal has no options, it should be called with _optionIdx = 0
function voteCount(uint256 _proposalIdx, uint256 _optionIdx) external view returns(uint256);
// Vote on a proposal without options.
// Assumes that proposal was created with propose(...) and will fail otherwise.
function vote(uint256 _value) external returns (bool);
// Vote on a proposal option. Assumes that proposal was created with proposeMulti(...).
// Must work with a non-option proposal if _optionIndex is 0.
function voteOption(uint256 _optionIndex, uint256 _value) external returns (bool);
// Vote to cancel a proposal.
// If cancel has the majority:
// * A vote without options will have rejected the proposal description.
// * A vote with options will have rejected the proposal description as well as all option descriptions.
function voteCancel(uint256 _value) external returns (bool);
// Finalize the vote for a proposal.
// May be called if deadline has been passed, or if:
// * quorum has been reached with cancel votes.
// * quorum has been reached and proposal has no/only one option.
function finalize() external returns (bool);
}