Overview
ETH Balance
0 ETH
Eth Value
$0.00More Info
Private Name Tags
ContractCreator
Latest 25 from a total of 105 transactions
Transaction Hash |
Method
|
Block
|
From
|
To
|
|||||
---|---|---|---|---|---|---|---|---|---|
Vote | 11636684 | 1493 days ago | IN | 0 ETH | 0.00118126 | ||||
Vote | 11636227 | 1493 days ago | IN | 0 ETH | 0.0013239 | ||||
Vote | 10970937 | 1595 days ago | IN | 0 ETH | 0.00259886 | ||||
Vote | 10970930 | 1595 days ago | IN | 0 ETH | 0.00259886 | ||||
Vote | 10970378 | 1595 days ago | IN | 0 ETH | 0.0015853 | ||||
Vote | 10970121 | 1595 days ago | IN | 0 ETH | 0.0013703 | ||||
Vote | 10968075 | 1596 days ago | IN | 0 ETH | 0.00122855 | ||||
Vote | 10966191 | 1596 days ago | IN | 0 ETH | 0.00184282 | ||||
Vote | 10964296 | 1596 days ago | IN | 0 ETH | 0.00266973 | ||||
Vote | 10964131 | 1596 days ago | IN | 0 ETH | 0.00259886 | ||||
Vote | 10964131 | 1596 days ago | IN | 0 ETH | 0.00259886 | ||||
Vote | 10961964 | 1597 days ago | IN | 0 ETH | 0.00212634 | ||||
Vote | 10960987 | 1597 days ago | IN | 0 ETH | 0.00122855 | ||||
Vote | 10959888 | 1597 days ago | IN | 0 ETH | 0.00148843 | ||||
Vote | 10959826 | 1597 days ago | IN | 0 ETH | 0.00148843 | ||||
Vote | 10958086 | 1597 days ago | IN | 0 ETH | 0.00550485 | ||||
Vote | 10956809 | 1597 days ago | IN | 0 ETH | 0.00303121 | ||||
Vote | 10955292 | 1598 days ago | IN | 0 ETH | 0.00217264 | ||||
Vote | 10954367 | 1598 days ago | IN | 0 ETH | 0.00361896 | ||||
Vote | 10947800 | 1599 days ago | IN | 0 ETH | 0.00118011 | ||||
Vote | 10947480 | 1599 days ago | IN | 0 ETH | 0.00141756 | ||||
Vote | 10946616 | 1599 days ago | IN | 0 ETH | 0.00106317 | ||||
Vote | 10945614 | 1599 days ago | IN | 0 ETH | 0.00269336 | ||||
Vote | 10945453 | 1599 days ago | IN | 0 ETH | 0.00189008 | ||||
Vote | 10944044 | 1599 days ago | IN | 0 ETH | 0.00115767 |
Latest 1 internal transaction
Advanced mode:
Parent Transaction Hash | Block |
From
|
To
|
|||
---|---|---|---|---|---|---|
10913858 | 1604 days ago | Contract Creation | 0 ETH |
Loading...
Loading
Similar Match Source Code This contract matches the deployed Bytecode of the Source Code for Contract 0x6BBAC22e...4Fcb28964 The constructor portion of the code might be different and could alter the actual behaviour of the contract
Contract Name:
Poll
Compiler Version
v0.5.11+commit.c082d0b4
Contract Source Code (Solidity)
/** *Submitted for verification at Etherscan.io on 2020-05-11 */ // File: contracts/polling/Poll.sol pragma solidity ^0.5.11; contract Poll { // The block at which the poll ends and votes can no longer be submitted. uint256 public endBlock; // Vote is emitted when an account submits a vote with 'choiceID'. // This event can be indexed to tally all votes for each choiceID event Vote(address indexed voter, uint256 choiceID); modifier isActive() { require( block.number <= endBlock, "poll is over" ); _; } constructor(uint256 _endBlock) public { endBlock = _endBlock; } /** * @dev Vote for the poll's proposal. * Reverts if the poll period is over. * @param _choiceID the ID of the option to vote for */ function vote(uint256 _choiceID) external isActive { emit Vote(msg.sender, _choiceID); } /** * @dev Destroy the Poll contract after the poll has finished * Reverts if the poll is still active */ function destroy() external { require(block.number > endBlock, "poll is active"); selfdestruct(msg.sender); } } // File: openzeppelin-solidity/contracts/token/ERC20/IERC20.sol pragma solidity ^0.5.0; /** * @dev Interface of the ERC20 standard as defined in the EIP. Does not include * the optional functions; to access them see `ERC20Detailed`. */ interface IERC20 { /** * @dev Returns the amount of tokens in existence. */ function totalSupply() external view returns (uint256); /** * @dev Returns the amount of tokens owned by `account`. */ function balanceOf(address account) external view returns (uint256); /** * @dev Moves `amount` tokens from the caller's account to `recipient`. * * Returns a boolean value indicating whether the operation succeeded. * * Emits a `Transfer` event. */ function transfer(address recipient, uint256 amount) external returns (bool); /** * @dev Returns the remaining number of tokens that `spender` will be * allowed to spend on behalf of `owner` through `transferFrom`. This is * zero by default. * * This value changes when `approve` or `transferFrom` are called. */ function allowance(address owner, address spender) external view returns (uint256); /** * @dev Sets `amount` as the allowance of `spender` over the caller's tokens. * * Returns a boolean value indicating whether the operation succeeded. * * > Beware that changing an allowance with this method brings the risk * that someone may use both the old and the new allowance by unfortunate * transaction ordering. One possible solution to mitigate this race * condition is to first reduce the spender's allowance to 0 and set the * desired value afterwards: * https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729 * * Emits an `Approval` event. */ function approve(address spender, uint256 amount) external returns (bool); /** * @dev Moves `amount` tokens from `sender` to `recipient` using the * allowance mechanism. `amount` is then deducted from the caller's * allowance. * * Returns a boolean value indicating whether the operation succeeded. * * Emits a `Transfer` event. */ function transferFrom(address sender, address recipient, uint256 amount) external returns (bool); /** * @dev Emitted when `value` tokens are moved from one account (`from`) to * another (`to`). * * Note that `value` may be zero. */ event Transfer(address indexed from, address indexed to, uint256 value); /** * @dev Emitted when the allowance of a `spender` for an `owner` is set by * a call to `approve`. `value` is the new allowance. */ event Approval(address indexed owner, address indexed spender, uint256 value); } // File: openzeppelin-solidity/contracts/math/SafeMath.sol pragma solidity ^0.5.0; /** * @dev Wrappers over Solidity's arithmetic operations with added overflow * checks. * * Arithmetic operations in Solidity wrap on overflow. This can easily result * in bugs, because programmers usually assume that an overflow raises an * error, which is the standard behavior in high level programming languages. * `SafeMath` restores this intuition by reverting the transaction when an * operation overflows. * * Using this library instead of the unchecked operations eliminates an entire * class of bugs, so it's recommended to use it always. */ library SafeMath { /** * @dev Returns the addition of two unsigned integers, reverting on * overflow. * * Counterpart to Solidity's `+` operator. * * Requirements: * - Addition cannot overflow. */ function add(uint256 a, uint256 b) internal pure returns (uint256) { uint256 c = a + b; require(c >= a, "SafeMath: addition overflow"); return c; } /** * @dev Returns the subtraction of two unsigned integers, reverting on * overflow (when the result is negative). * * Counterpart to Solidity's `-` operator. * * Requirements: * - Subtraction cannot overflow. */ function sub(uint256 a, uint256 b) internal pure returns (uint256) { require(b <= a, "SafeMath: subtraction overflow"); uint256 c = a - b; return c; } /** * @dev Returns the multiplication of two unsigned integers, reverting on * overflow. * * Counterpart to Solidity's `*` operator. * * Requirements: * - Multiplication cannot overflow. */ function mul(uint256 a, uint256 b) internal pure returns (uint256) { // Gas optimization: this is cheaper than requiring 'a' not being zero, but the // benefit is lost if 'b' is also tested. // See: https://github.com/OpenZeppelin/openzeppelin-solidity/pull/522 if (a == 0) { return 0; } uint256 c = a * b; require(c / a == b, "SafeMath: multiplication overflow"); return c; } /** * @dev Returns the integer division of two unsigned integers. Reverts on * division by zero. The result is rounded towards zero. * * Counterpart to Solidity's `/` operator. Note: this function uses a * `revert` opcode (which leaves remaining gas untouched) while Solidity * uses an invalid opcode to revert (consuming all remaining gas). * * Requirements: * - The divisor cannot be zero. */ function div(uint256 a, uint256 b) internal pure returns (uint256) { // Solidity only automatically asserts when dividing by 0 require(b > 0, "SafeMath: division by zero"); uint256 c = a / b; // assert(a == b * c + a % b); // There is no case in which this doesn't hold return c; } /** * @dev Returns the remainder of dividing two unsigned integers. (unsigned integer modulo), * Reverts when dividing by zero. * * Counterpart to Solidity's `%` operator. This function uses a `revert` * opcode (which leaves remaining gas untouched) while Solidity uses an * invalid opcode to revert (consuming all remaining gas). * * Requirements: * - The divisor cannot be zero. */ function mod(uint256 a, uint256 b) internal pure returns (uint256) { require(b != 0, "SafeMath: modulo by zero"); return a % b; } } // File: openzeppelin-solidity/contracts/token/ERC20/ERC20.sol pragma solidity ^0.5.0; /** * @dev Implementation of the `IERC20` interface. * * This implementation is agnostic to the way tokens are created. This means * that a supply mechanism has to be added in a derived contract using `_mint`. * For a generic mechanism see `ERC20Mintable`. * * *For a detailed writeup see our guide [How to implement supply * mechanisms](https://forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226).* * * We have followed general OpenZeppelin guidelines: functions revert instead * of returning `false` on failure. This behavior is nonetheless conventional * and does not conflict with the expectations of ERC20 applications. * * Additionally, an `Approval` event is emitted on calls to `transferFrom`. * This allows applications to reconstruct the allowance for all accounts just * by listening to said events. Other implementations of the EIP may not emit * these events, as it isn't required by the specification. * * Finally, the non-standard `decreaseAllowance` and `increaseAllowance` * functions have been added to mitigate the well-known issues around setting * allowances. See `IERC20.approve`. */ contract ERC20 is IERC20 { using SafeMath for uint256; mapping (address => uint256) private _balances; mapping (address => mapping (address => uint256)) private _allowances; uint256 private _totalSupply; /** * @dev See `IERC20.totalSupply`. */ function totalSupply() public view returns (uint256) { return _totalSupply; } /** * @dev See `IERC20.balanceOf`. */ function balanceOf(address account) public view returns (uint256) { return _balances[account]; } /** * @dev See `IERC20.transfer`. * * Requirements: * * - `recipient` cannot be the zero address. * - the caller must have a balance of at least `amount`. */ function transfer(address recipient, uint256 amount) public returns (bool) { _transfer(msg.sender, recipient, amount); return true; } /** * @dev See `IERC20.allowance`. */ function allowance(address owner, address spender) public view returns (uint256) { return _allowances[owner][spender]; } /** * @dev See `IERC20.approve`. * * Requirements: * * - `spender` cannot be the zero address. */ function approve(address spender, uint256 value) public returns (bool) { _approve(msg.sender, spender, value); return true; } /** * @dev See `IERC20.transferFrom`. * * Emits an `Approval` event indicating the updated allowance. This is not * required by the EIP. See the note at the beginning of `ERC20`; * * Requirements: * - `sender` and `recipient` cannot be the zero address. * - `sender` must have a balance of at least `value`. * - the caller must have allowance for `sender`'s tokens of at least * `amount`. */ function transferFrom(address sender, address recipient, uint256 amount) public returns (bool) { _transfer(sender, recipient, amount); _approve(sender, msg.sender, _allowances[sender][msg.sender].sub(amount)); return true; } /** * @dev Atomically increases the allowance granted to `spender` by the caller. * * This is an alternative to `approve` that can be used as a mitigation for * problems described in `IERC20.approve`. * * Emits an `Approval` event indicating the updated allowance. * * Requirements: * * - `spender` cannot be the zero address. */ function increaseAllowance(address spender, uint256 addedValue) public returns (bool) { _approve(msg.sender, spender, _allowances[msg.sender][spender].add(addedValue)); return true; } /** * @dev Atomically decreases the allowance granted to `spender` by the caller. * * This is an alternative to `approve` that can be used as a mitigation for * problems described in `IERC20.approve`. * * Emits an `Approval` event indicating the updated allowance. * * Requirements: * * - `spender` cannot be the zero address. * - `spender` must have allowance for the caller of at least * `subtractedValue`. */ function decreaseAllowance(address spender, uint256 subtractedValue) public returns (bool) { _approve(msg.sender, spender, _allowances[msg.sender][spender].sub(subtractedValue)); return true; } /** * @dev Moves tokens `amount` from `sender` to `recipient`. * * This is internal function is equivalent to `transfer`, and can be used to * e.g. implement automatic token fees, slashing mechanisms, etc. * * Emits a `Transfer` event. * * Requirements: * * - `sender` cannot be the zero address. * - `recipient` cannot be the zero address. * - `sender` must have a balance of at least `amount`. */ function _transfer(address sender, address recipient, uint256 amount) internal { require(sender != address(0), "ERC20: transfer from the zero address"); require(recipient != address(0), "ERC20: transfer to the zero address"); _balances[sender] = _balances[sender].sub(amount); _balances[recipient] = _balances[recipient].add(amount); emit Transfer(sender, recipient, amount); } /** @dev Creates `amount` tokens and assigns them to `account`, increasing * the total supply. * * Emits a `Transfer` event with `from` set to the zero address. * * Requirements * * - `to` cannot be the zero address. */ function _mint(address account, uint256 amount) internal { require(account != address(0), "ERC20: mint to the zero address"); _totalSupply = _totalSupply.add(amount); _balances[account] = _balances[account].add(amount); emit Transfer(address(0), account, amount); } /** * @dev Destoys `amount` tokens from `account`, reducing the * total supply. * * Emits a `Transfer` event with `to` set to the zero address. * * Requirements * * - `account` cannot be the zero address. * - `account` must have at least `amount` tokens. */ function _burn(address account, uint256 value) internal { require(account != address(0), "ERC20: burn from the zero address"); _totalSupply = _totalSupply.sub(value); _balances[account] = _balances[account].sub(value); emit Transfer(account, address(0), value); } /** * @dev Sets `amount` as the allowance of `spender` over the `owner`s tokens. * * This is internal function is equivalent to `approve`, and can be used to * e.g. set automatic allowances for certain subsystems, etc. * * Emits an `Approval` event. * * Requirements: * * - `owner` cannot be the zero address. * - `spender` cannot be the zero address. */ function _approve(address owner, address spender, uint256 value) internal { require(owner != address(0), "ERC20: approve from the zero address"); require(spender != address(0), "ERC20: approve to the zero address"); _allowances[owner][spender] = value; emit Approval(owner, spender, value); } /** * @dev Destoys `amount` tokens from `account`.`amount` is then deducted * from the caller's allowance. * * See `_burn` and `_approve`. */ function _burnFrom(address account, uint256 amount) internal { _burn(account, amount); _approve(account, msg.sender, _allowances[account][msg.sender].sub(amount)); } } // File: contracts/zeppelin/Ownable.sol pragma solidity ^0.5.11; /** * @title Ownable * @dev The Ownable contract has an owner address, and provides basic authorization control * functions, this simplifies the implementation of "user permissions". */ contract Ownable { address public owner; event OwnershipTransferred(address indexed previousOwner, address indexed newOwner); /** * @dev The Ownable constructor sets the original `owner` of the contract to the sender * account. */ constructor() public { owner = msg.sender; } /** * @dev Throws if called by any account other than the owner. */ modifier onlyOwner() { require(msg.sender == owner); _; } /** * @dev Allows the current owner to transfer control of the contract to a newOwner. * @param newOwner The address to transfer ownership to. */ function transferOwnership(address newOwner) public onlyOwner { require(newOwner != address(0)); emit OwnershipTransferred(owner, newOwner); owner = newOwner; } } // File: contracts/token/ILivepeerToken.sol pragma solidity ^0.5.11; contract ILivepeerToken is ERC20, Ownable { function mint(address _to, uint256 _amount) public returns (bool); function burn(uint256 _amount) public; } // File: contracts/polling/PollCreator.sol pragma solidity ^0.5.11; contract PollCreator { // 33.33% uint256 public constant QUORUM = 333300; // 50% uint256 public constant QUOTA = 500000; // 10 rounds uint256 public constant POLL_PERIOD = 10 * 5760; uint256 public constant POLL_CREATION_COST = 100 * 1 ether; ILivepeerToken public token; event PollCreated( address indexed poll, bytes proposal, uint256 endBlock, uint256 quorum, uint256 quota ); constructor(address _tokenAddr) public { token = ILivepeerToken(_tokenAddr); } /** * @dev Create a poll by burning POLL_CREATION_COST LPT. * Reverts if this contract's LPT allowance for the sender < POLL_CREATION_COST. * @param _proposal The IPFS multihash for the proposal. */ function createPoll(bytes calldata _proposal) external { uint256 endBlock = block.number + POLL_PERIOD; Poll poll = new Poll(endBlock); require( token.transferFrom(msg.sender, address(this), POLL_CREATION_COST), "LivepeerToken transferFrom failed" ); token.burn(POLL_CREATION_COST); emit PollCreated( address(poll), _proposal, endBlock, QUORUM, QUOTA ); } }
Contract Security Audit
- No Contract Security Audit Submitted- Submit Audit Here
[{"constant":false,"inputs":[{"internalType":"uint256","name":"_choiceID","type":"uint256"}],"name":"vote","outputs":[],"payable":false,"stateMutability":"nonpayable","type":"function"},{"constant":true,"inputs":[],"name":"endBlock","outputs":[{"internalType":"uint256","name":"","type":"uint256"}],"payable":false,"stateMutability":"view","type":"function"},{"constant":false,"inputs":[],"name":"destroy","outputs":[],"payable":false,"stateMutability":"nonpayable","type":"function"},{"inputs":[{"internalType":"uint256","name":"_endBlock","type":"uint256"}],"payable":false,"stateMutability":"nonpayable","type":"constructor"},{"anonymous":false,"inputs":[{"indexed":true,"internalType":"address","name":"voter","type":"address"},{"indexed":false,"internalType":"uint256","name":"choiceID","type":"uint256"}],"name":"Vote","type":"event"}]
Deployed Bytecode
0x608060405234801561001057600080fd5b50600436106100415760003560e01c80630121b93f14610046578063083c63231461006557806383197ef01461007f575b600080fd5b6100636004803603602081101561005c57600080fd5b5035610087565b005b61006d610106565b60408051918252519081900360200190f35b61006361010c565b6000544311156100cd576040805162461bcd60e51b815260206004820152600c60248201526b3837b6361034b99037bb32b960a11b604482015290519081900360640190fd5b60408051828152905133917ff668ead05c744b9178e571d2edb452e72baf6529c8d72160e64e59b50d865bd0919081900360200190a250565b60005481565b6000544311610153576040805162461bcd60e51b815260206004820152600e60248201526d706f6c6c2069732061637469766560901b604482015290519081900360640190fd5b33fffea265627a7a723158206c9ce9bb5a8444cdce50e29a4427a60253222473d36eb7b1ee1eea3cb051f4b564736f6c634300050b0032
Deployed Bytecode Sourcemap
69:1112:0:-;;;;8:9:-1;5:2;;;30:1;27;20:12;5:2;69:1112:0;;;;;;;;;;;;;;;;;;;;;;;;;;;;;802:102;;;;;;13:2:-1;8:3;5:11;2:2;;;29:1;26;19:12;2:2;-1:-1;802:102:0;;:::i;:::-;;169:23;;;:::i;:::-;;;;;;;;;;;;;;;;1046:132;;;:::i;802:102::-;473:8;;457:12;:24;;435:86;;;;;-1:-1:-1;;;435:86:0;;;;;;;;;;;;-1:-1:-1;;;435:86:0;;;;;;;;;;;;;;;869:27;;;;;;;;874:10;;869:27;;;;;;;;;;802:102;:::o;169:23::-;;;;:::o;1046:132::-;1108:8;;1093:12;:23;1085:50;;;;;-1:-1:-1;;;1085:50:0;;;;;;;;;;;;-1:-1:-1;;;1085:50:0;;;;;;;;;;;;;;;1159:10;1146:24
Swarm Source
bzzr://6c9ce9bb5a8444cdce50e29a4427a60253222473d36eb7b1ee1eea3cb051f4b5
Loading...
Loading
Loading...
Loading
Multichain Portfolio | 31 Chains
Chain | Token | Portfolio % | Price | Amount | Value |
---|
Loading...
Loading
[ Download: CSV Export ]
[ Download: CSV Export ]
A contract address hosts a smart contract, which is a set of code stored on the blockchain that runs when predetermined conditions are met. Learn more about addresses in our Knowledge Base.