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?
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.
You could use tinylock.org, an already existing solution.
If you would like to build your own, I recommend looking at Pyteal
Good, thanks Fabrice.
If Tinyman already has it, then it is better, it will bring more trust. Thank you very much.
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?
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.
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
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.
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?
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.
If the logic signature was referring to a round number, then it could lead to a situation where the proposal would include transactions that would not pass the validation.
AppCalls, on the other hand are being executed during the assembly of the proposal ( as well as during validation, naturally ). That’s why these could have state associated with them ( as well as their lower total execution cost ).
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?
if i set the props for max round to be submitted in the pool, can it get submitted after this round?
with the same logic there should be some validity for the fee… right? can i submit 2 txs for 0.001 to the transaction pool with available balance of 0.001?
so if the adding tx to the pool means it will be on the blockchain even if you do not validate with the max round parameter, you can use the same approach for validity of stateless smart contract and validate the round… you always validate once. that is good approach for stateless contract txs. but it does not break the ability of the engine to verify agains the current round
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 ).
One of the things that being tracked by the transaction pool is the generated block size. Once the transaction pool content exceed the size of a single block, the MinFee increases. The second time the transaction pool exceed the size of the block ( i.e. two pending blocks ), the MinFee increase again, and so forth.
The reason you won’t be able to submit “2 txs for 0.001 to the transaction pool with available balance of 0.001” is because the transaction are being “staged” as if they were to be executed. Since the latter one would fail, it would get tossed away, leaving only the first one.
When a new round starts, all the proposers are trying to assemble a block. In order to do so, they reevaluate the first block on the transaction pool ( since we’re at a new round ). Some of the expired transactions would be dropped, some others would remain.
Throughout that process, the logicsig was validated only once. The LastValid on the transaction is evaluated on every round.
Is that answer your questions ?
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?
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.
Thank you all for the fresh and inspiring discussion. Scooped up a lot.
@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).
In my view, TEAL code should be evaluated by the block proposer node when building the block and again by all committee nodes during certification of this block (3rd and last step).
So I don’t understand how we could have only one execution and have proper decentralization.
Please enlighten me 
“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.
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) ?
when a txn is propagted all nodes evaluate the txn to the smart contract it’s meant to if they see that txn. the block producer who ever that is just includes that in the block. certVote comittee i believe check the validity of the txns in the block