I am looking to issue voting Tokens.
The basic idea is that I will send something like 100 tokens to 10 people. Then there will be three wallets that act as ballot box.
In order to incentivize the people I wan’t to burn the tokens after a certain period of time.
Am I right that i can do so by burning the tokens as token issuer?
And when burning, what will happen to the ADA used during token minting?
Actually, native tokens can only be burned if the transaction is witnessed by the script that created them. It is not possible to burn them if they are in someone else’s wallet without that wallet signing the burning transaction. The ADA is not lost when a token is burned, aside from the small fee paid in the transaction that burns them.
When smart contracts are available, it will be possible to simulate tokens that expire, using a sort of “smart token” that is actually just a smart contract, not a normal native token.
thnx @bwbush seems as if the best solution is to wait for the smart contracts to land.
I’m not sure: using a “smart token” would require a voter that understands how smart contracts/tokens work and a wallet that makes it easy to use them.
For the voting use case that you describe, a positive incentive like providing a reward for voting might work just as well as a negative incentive of having the voting tokens expire. Also note that there is already an incentive to return the token if doing so could redeem the the ~1.5 ADA min-ada value attached to the token.
the actual use case i wan’t to realise is to enable people how staked in my pool to vote where the rewards should be donated.
Therefore i wan’t to give them voting rights proportional to their stake.
As it is hard/impossible to attach some sort of identity to a stake and setup some sort of web based voting system, i thought sending voting tokens to their addresses might be a good possibility.
The main idea is to increase engagement and transparency in the reward donation process.
Also everything would be described on our website and within our social channels.
I like your idea. Thanks for explaining the use case. I’m wondering if an approach like the following would meet most of your requirements, given the present situation where the network doesn’t support identity or smart contracts:
- Send the proportional number of voting tokens to the wallet address associated with the stake key’s delegation transaction. It would be accompanied by the min-ada value (~ 1.5 ADA) plus maybe the transaction fee (~ 0.17 ADA) needed to vote and maybe a bonus to encourage them to vote. Include a link to the voting instructions (or the briefly stated voting instructions) in the transaction metadata. (To save transaction fees, it would be best to bundle the sending of tokens in as few transactions as possible: about 400 outputs can fit in a single transaction, and still leave room for metadata.)
- When the voter receives the tokens, they can read or visit the voting instructions if they aren’t already aware of the voting system.
- The voter sends the tokens to the voting address(es), as you’ve described. (They will be returning the ~ 1.5 ADA and paying the transaction fee, but they can keep the bonus. Your net cost would be the transaction fees and the bonus.)
- The voter won’t receive any more tokens for future rounds of voting until they have voted with the ones they were already given. They’d get to keep the tokens, the min-ada, and the bonus, but they wouldn’t get the future bonuses.
An alternative to step 1 would be to use a registration system like pooltool.io, so that each delegator would have to opt into the voting system.
A scheme like the above provides a mild incentive to vote. The downsides are:
- Non-voters would keep the min-ADA and bonus.
- Delegators could trade or sell their votes for others to cast.
- Voters could skips rounds of voting and use their tokens to vote in a later round.
There are probably other ways to do this, and I’m not sure whether the downsides outweigh the benefits.