7

As of 003_PsddFKi3: An originated account is forever.[1] An implicit account is 'allocated'[2] and 'deleted'[3] as its balance goes above and back to zero (if it is not a delegate[4]). Currently you must pay a storage burn to allocate an implicit account, and there is no refund upon deletion. The storage_limit for an operation accounts for this burn (...


7

In the command line ./tezos-client get contract storage for KT1BRudFZEXLYANgmZTka1xCDN5nWTMWY7SZ You could also just call the RPC curl http://localhost:8732/chains/main/blocks/head/context/contracts/KT1BRudFZEXLYANgmZTka1xCDN5nWTMWY7SZ/storage


6

1) Here they are $ ./tezos-client rpc get /chains/main/blocks/1/context/contracts | grep KT1 "KT1WPEis2WhAc2FciM2tZVn8qe6pCBe9HkDp", "KT1W148mcjmfvr9J2RvWcGHxsAFApq9mcfgT", "KT1VvXEpeBpreAVpfp4V8ZujqWu2gVykwXBJ", "KT1VsSxSXUkgw6zkBGgUuDXXuJs9ToPqkrCg", "KT1Um7ieBEytZtumecLqGeL56iY6BuWoBgio", "KT1TzamC1SCj68ia2E4q2GWZeT24yRHvUZay", "...


6

The difference is very simple :) The parameter is made of data that are sent to the contract with a transaction while the storage holds the state of the contract (i.e all the data that the contract saves to be reused later). It is true that both the storage and the parameter can be seen as inputs because they are fed to the contract at the beginning of its ...


5

In the FA2.0 standard the sender and receiver is send as Bytes (vs. send as string for FA1.2). Both token standards say that sender and receiver are Michelson addresses. Michelson addresses have two allowed representations, as strings (readable representation) and as bytes (optimized representation). What is the extra byte used for? The extra byte is used ...


5

Why can I convert between address and contract. But not between address and key_hash? There is the (IMPLICIT_ACCOUNT) instruction to go from key_hash to address. For the other direction, there was (a feature request) but it was closed because no use case has been presented to motivate it.


5

key_hash is blake2b hash of a public key, in the base58 encoded form it can start only with tz, but address is more general, it can also hold KT accounts; There are no instructions for that, probably because it's a rare and arguable case; EDIT: as pointed out by Raphaël, you can convert key_hash to contract and then to address using IMPLICIT_ACCOUNT ; ...


4

No. The only way to do that is for the contract you call to explicitely send you a callback, continuation passing style.


4

You cannot create a contract and call it immediately. It goes like this, chronologically: Your script is running. You invoke CREATE_CONTRACT or CREATE_ACCOUNT. An operation and address are returned and your script continues on. The operation will create the account after your script returns it. Right now, the account does not exist. You now immediately try ...


3

You need to provide an initial storage value for your contract. You can write it in Ligo and compile it too using the ligo compile-storage command.


3

No, whitespace and comments do not affect storage or gas costs. The syntax of Michelson code and values is called "Micheline". The concrete syntax (the way you actually write Micheline expressions in text, with whitespace and comments, etc) is used by clients for the convenience of humans. It is also validated to prevent some obfuscation tricks -- ...


3

In a scenario where both the TZ1 and KT1 addresses have been emptied, you can still send funds to your KT1 address. The KT1 contract never gets destroyed. You will however need fund your manager account again (TZ1 address) in order to move the funds you just sent to your KT1 address. The delegation would remain active as long as you don't change or cancel ...


3

No - these are helper functions that provide typecheck and testing features. You originate a contract via an operation (with kind origination), and you call it via a standard transaction and the parameter field.


2

In my understanding, you can call a contract by sending a parametrised transaction, that's injected as an operation under /injection/operation. You can trace the flow above in the source of eztz.js. /injection/operation doesn't return much more, but a hash of the operation you've just injected. (there is a mention of a $unistring although i'm not sure what ...


2

You are using a private key which do not correspond to any account on the alphanet. It works with liquidity --tezos-node http://alphanet-node.tzscan.io:80 --private-key edsk2j7Ka5nRzh2QkGCtcD1dFLbHYvYw7XAafWL3YEAQQ3Zd61NiqS --protocol alphanet simple.liq --deploy Main contract Simple New contract KT18bLbXyH5yMY9ShDfCwtiXegWHMTa4aS8H deployed in operation ...


2

As I understand the concepts, transferring tezos is one kind of contract. It has amount to move from account to another and the move is containing a transaction to track, that the operation gets through in meaningful time. So, actually tezos transfer is a small contract, sort of. What about smart contract data types (is it amount of money in tezos, dollars, ...


2

Let's find the contract on Arronax and look at its code... storage unit; code { CDR ; NIL operation ; AMOUNT ; PUSH mutez 0 ; { COMPARE ; EQ ; IF {} { SOURCE ; CONTRACT unit ; { IF_NONE { { UNIT ; FAILWITH } } {} } ; AMOUNT ; UNIT ; TRANSFER_TOKENS ; CONS } } ; PAIR } ..you will see that nothing is effectively being ...


2

The babylonnet was terminated about 2 weeks ago. It is no longer supported. You should be on carthagenet now. "Waiting for the node to be bootstrapped" means your node is not yet synchronized with the rest of the network. You cannot submit operations until you are in sync. On carthagenet, this might take about 24 hrs to sync.


2

You created a contract which can only transfer funds when it receives a call to do so from its "manager" account which was specified at origination and is the only value the contract has in its storage. The contract can be seen here https://better-call.dev/main/KT1VSiaepk9USGAHDjJQAm4aaYRC6J8dTBHG/operations You can see that the storage has the value ...


1

I think we are in the third case: Maybe useful but none has yet proposed it with convincing use cases? It is true that the keys must be given from the outside but so are the signatures so if one needs to combine signature checking and address-based authentication it is always possible to replace all occurrences of signature with pair key signature and ...


1

Hehey, ok if this is true, it is sad. but i found a solution; liquidity -> .liq -> .tz and deploy with tezos-client. :) – candlez Jan 6 at 15:00


1

There is no need to edit the "do" entry point since they are the manager. All that is required is for them to import the KT1 address into their wallet and they can send the funds.


1

You need quotes for the parameter itself, and inside quotes for the contract literal. It should look like this. --init '"KT1..."'


1

After further contract investigation, I found out that these operations are used for internal blockchain operations like transferring tez to an account or calling a contract with parameters. These operations are created from Michelson stack elements and are a series of bytes which represent a forged operation. There is a example on the official Tezos ...


1

The best way to estimate it is to use the CLI like you've done. Otherwise, you need to know the contract's high water mark (the most storage it ever held), the current size of its storage, whether the operation will increase the storage beyond the high water mark and if so by how much. However, I note that in your screenshot you are transferring from a tz1 ...


1

You can do this via a signed operation of kind origination: http://tezos.gitlab.io/mainnet/api/p2p.html#origination-tag-9 Similar to a standard origination of a KT address, except there's the presence of the script field. To get this, you need to convert your Michelson to Micheline (details of the syntax/format for Micheline here) and then you need to forge ...


Only top voted, non community-wiki answers of a minimum length are eligible