0

Well, I want to create my own contract and I will give like 10 coins to every user every month, but if the user doesn't transfer it from his own wallet, I want to "delete" this coins, to encourage transactions between the Community.

I was thinking in program this on a wallet. But this is really the best way to do that?

Thanks

OBS: it's not a homework. I just wanted a direction, and I believe you guys have a lot more experience than I do.

0
0

In keeping the general theme of the other answers, this is possible. It just calls for reframing the processes as user-initiated steps.

You say you want to "delete" coins. From this, I surmise that you will create the token contract because it would be madness to burn tokens of another type that carry value outside this system. Given that you will create your own token, then you can make it a "mintable" token. The token contract is only concerned with issuing the tokens and tracking transfers between accounts.

You will have another contract, the "Mint", that will handle the monthly airdrops and creation/destruction logic. This will be the only address with the authority to issue new tokens (a.k.a. the "minter" in a typical mintable ERC20 design).

Users will simply ask the Mint to forward tokens. Simple. The Mint will:

  • Assess the request. Is it allowable? Given the interval rules and user history, are they permitted to ask for more tokens at this time?
  • Instruct the Token contract to "Mint" tokens to the benefit of the requester (if allowable).

There would be no need to destroy tokens because they would only be created as needed, as you go.

Hope it helps.

p.s. The economics of such a design is questionable.

0

If you are writing the contract for the token as well, then yes, this is possible.

Your token contract can having a mapping of addresses to timestamps that is updated every time an address transfers tokens.

A privileged actor on the contract can then call a function along the lines of reclaim(address) to clear a token's balance if the last transaction was over thirty days ago.

Alternatively, you could do this without any additional transactions by checking a user's last transfer time on each transfer, and if it is more than 30 days ago, fail their current transfer and redirect the tokens to a reclaimed wallet. This has the disadvantage that tokens won't be moved until the user tries to move them after 30 days, but it also doesn't require additional transactions.

0

The two strategies described by Raghav also demonstrate one of the fundamental aspects of Solidity programming: nothing will happen until a transaction triggers it. You can design the transfer function to check whether the address is allowed to keep holding its token, or you can create a reclaim function which gets the token back, but neither of those strategies "automatically" work at the 30-day mark.

Scheduling future events for a specific time is inherently impossible within a Solidity contract because your code only runs when a transaction or call triggers it. You can check that a time has passed, but you can't ensure that your code will run at that time.

Given that many applications do require scheduled events, some people are trying to work around this issue. The ethereum-alarm-clock project is under active development, it aims to let anybody schedule transactions by registering them with their EAC contract. It hasn't been deployed to the Ethereum mainnet yet as of 2018/08/16, but it looks like the 1.0 release will be there soon.

With that said, using their solution depends on trusting them to stick around. Their smart contract will execute your transaction, but based on my reading of their repositories, they only get around Solidity's fundamental constraints by running a Javascript server on a 5-minute interval which checks if any calls needs to get made. They have a very general solution to this problem, but you could probably write a simple node.js server yourself which handles just calling the reclaim() function at your desired interval.

Not the answer you're looking for? Browse other questions tagged or ask your own question.