Token Lock Examples - Algorand

Token Lock Examples

post by JoeBlocks on Mar 3, 2022

Good day all. Please how do I create a token lock? Locking team allocated tokens is now a feature of most crypto projects, so how can this be done in Algorand? And hope the lock will be seen by investors on AlgoExplorer?

post by fabrice on Mar 3, 2022

You can definitely do it using smart contracts and inner transactions.

You move all the tokens in the application account of the smart contract.

The smart contract can then allow disbursement/unlocking of tokens according to the rules you want.

I am not sure whether there is a ready-to-use solution.

But this tutorial Build with Python - Algorand Developer Portal actually is doing something more complex and can be tweaked for your purpose.

post by ncoin on Mar 4, 2022

You could use tinylock.org, an already existing solution.

If you would like to build your own, I recommend looking at Pyteal

post by JoeBlocks on Mar 4, 2022

Good, thanks Fabrice.

post by JoeBlocks on Mar 4, 2022

If Tinyman already has it, then it is better, it will bring more trust. Thank you very much.

post by JoeBlocks on Mar 4, 2022

I just realized that you said tinylock not tinyman. Is it the same Company? Then if not is Tinylock.org a trustworthy or reputable Dapp? Imagine locking your tokens and then waking to see it is gone?

post by ncoin on Mar 7, 2022

Hello there, I do apologize for the late response.

I use it for my coin and it is trust worthy. Other tokens that say that they have locked their tokens often use tinylock.

It’s not by the Tinyman team. It’s by one individual I believe. You buy over 500 TinylockV1.1 tokens to pay the fees for locking your token. Their website tinylock.org should explain it all.

post by scholtz on Mar 7, 2022

i was speaking to Jason at ETH Denver and he told me that there will be the global variable for the block round in the smart contract in upcomming release usable for stateless logic sig smart contracts…

i see it that we should make a ARC standard from like 20 line teal code (one owner who can transact back to himself, no rekeying allowed, owner can close his lock after specific round) and make the locking fully stateless and standardized

post by tsachi on Mar 7, 2022

Maybe I misunderstood you - are you saying that a stateless smart contract would have a state controlled variable? Wouldn’t that defeat the purpose of having stateless smart contract?

I.e. the idea was that the contact would get evaluated one time only… by re-evaluating it every round, it would be equivilent to add appcall that asserts if the conditions aren’t met.

post by scholtz on Mar 8, 2022

no, the logic is stateless…

you deposit money to the stateless logicsig

you request money from the logicsig (evaluated once) block > 20000000 yes/no …

why do you call it stateful?

does logicsig where you hardcode the address is statefull in your view?

who is saying about reevaluating every block? i say that after you see that block is higher than certain number you create a transaction which is evaluated once.

are you saying that the information about the ability to use the round in stateless smart contract is not on the table?

post by tsachi on Mar 8, 2022

The statefulness of a contract is important, since it’s playing a role in the scaling of the platform.

When you send a logicsig transaction, the logic signature is evaluated once, and then placed into the transaction pool. Several rounds later, the local node could be elected to propose a block.

When that happens, the transactions from the transaction pools are being taken and without re-evaluating any of the signatures being added to the proposed block.

post by scholtz on Mar 8, 2022

can you please elaborate little more?

for example if i am trying to send a tx to logic sig, which includes fee 0.001 algo, it falls to the transaction pool. right? and you are telling me that this tx might be inserted in 5 blocks from now? what if i have the maximum round set there to be the current block? what if i make 100000 such txs and submit them at once, are they going to be submitted to the transaction pool?

post by tsachi on Mar 8, 2022

Sure.

An incoming transaction (regardless of the source), would first go through a signature verification. Once it’s found to be a (potentially) valid transaction, it will be attempted to be placed on the transaction pool.

When attempting to place it on the transaction pool, it would get evaluated as if it was executed on top of all the existing transactions in the pool. If it fails that evaluation, the transaction is being tossed away (and not being propagated further).

post by scholtz on Mar 8, 2022

yes, i understand it now better. thx

so to conclude, if there is in logicsig which includes current block, you would have to evaluate it when you submit it to the transaction pool, and reevaluate this logicsig again when it gets to the top of the transaction pool.

this is however still much more effecient than using the statefull application which reevaluates the content on every round… right?

post by tsachi on Mar 8, 2022

All correct beside the “reevaluate” portion - it’s never get reevaluated. The transaction content is being reevaluated - i.e. first valid/last valid / payer has enough money / receiver has more than min balance, etc, but the logic sig is evaluated exactly once.

Depending on the implementation, some logic sig are much more costly than AppCalls and vice versa.

If you need to add a “time” constrain to a transaction, I would suggest you’ll add an AppCall txn within the same transaction group.

post by JoeBlocks on Mar 17, 2022

Thank you all for the fresh and inspiring discussion. Scooped up a lot.

post by ismax on Aug 1, 2022

@tsachi when you say “logic sig is evaluated exactly once”, is it also true for app call code?

And at which step among the 3 of the consensus does this single evaluation occurs? Is it when constructing the block, during soft vote or during certification vote?

If Teal code gets only evaluated during block construction, my understanding is that only one node is evaluating it (the block proposer) so there is no redundancy/decentralization (we need to trust a single node).

post by fabrice on Aug 1, 2022

“One evaluation” was meant in the following sense:

Logicsigs (aka smart signatures / stateless smart contracts) are evaluated only once: the first time the node sees the transaction in the transaction pool or in a block essentially.

It was not meant one evaluation by a single node of the network.

post by ismax on Aug 1, 2022

Ok so evaluated once inside the block construction step if I understand correctly (so potentially by a single node).

Is the TEAL code evaluated again during the block certification step (this time always by multiple nodes)?

post by Titi on Aug 1, 2022

when a txn is propagated all nodes evaluate the txn to the smart contract it’s meant to if they see that txn. the block producer whoever that is just includes that in the block.