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

Operations of the following types can affect account balance: transaction revelation origination delegation endorsement seed_nonce_revelation double_endorsement_evidence double_baking_evidence activate_account However, there are three additional things which affect account balance as well: When you bake a block. When you miss seed_nonce_revelation. When ...


4

A series of blog posts from Nomadic Labs give a more detailed and up-to-date answer, notably this one: https://blog.nomadic-labs.com/emmy-in-the-partial-synchrony-model.html. Roughly, the answer depends on how much stake an attacker is considered to have. But it also depends on whether the network message delays are reasonable, and on the degree of assurance ...


3

Technically, transaction amount is of mutez type, which is internally represented by 64-bit signed integer. However, in practice, (if we speak about applied transactions) the amount cannot exceed the total supply, wich is currently 873682204744114 (https://api.tzkt.io/v1/statistics/current). And yes, a single transaction can have only one destination address....


3

When you transfer out of an address which has never revealed its public key, you must pay a burn to do this reveal operation. This was added back in, IIRC, 004 to prevent new address creation spamming. If you transfer the entire balance out of a tz1/2/3, then you must again pay the burn fee to "reactivate" the account. The blockchain does a type of ...


3

I don't agree that the mempool behavior indicate that the fee is all good. On the contrary. Public nodes like Giganode generally don't reject operations based on fee in the prevalidation, while most other nodes do apply the default filter. The fee is most likely too low. I don't know exactly how many bytes you got there, but increasing the fee with 10 mutez ...


3

The structure of an encoded operation group is the following: <branch : 32 bytes> <tag#0 : nat> | <content#0> ... <tag#n : nat> | <content#n> <signature (optional) : 64 bytes> Extracting branch: Append 0x0134 prefix Base58 encode with checksum Extracting signature: Append 0x04822b prefix Base58 encode with checksum ...


3

First you need to know what level (block height) to look at based on the provided operation hash (operation id). You have public indexer API's like tzkt or tzstats that can make this very easy for you. Then you can get the parsed operation(s) directly from the RPC API. After that you can forge it locally with for example Taquito to get it as a hex string. ...


2

There is a high chance you got scammed by a fake TezBox site. Go back and carefully check the URL. TezBox has been "dead" and unsupported for almost a year and half. There have been several fakes that have surfaced and your story sounds exactly like the others. Unfortunately, if this is indeed the case, there is absolutely no way to get your Tez ...


2

The correct way to do this is simply: @sp.entry_point def withdraw(self, amount): sp.set_type(amount, sp.TMutez) sp.send(sp.sender, amount) The solidity translation tool I used didn't handle this properly


2

The main reason is the storage diff resulted from the transaction. Adding 380 items to a big map at once is very expensive. For your use case, storing the corner coordinates should be enough.


2

storage_exhausted means the storage_limit you have set is too low for your operation. You have set 0. Your dry-run came back with "allocated_destination_contract": true. You need to pay an allocation fee to cover the cost of assigning the new address. Set your storage limit to 257


1

I would like to clarify some of the beacon behavior. The main responsibility of beacon is establishing and maintaining a communication channel between a dApp and a wallet. Beacon itself does NOT do any type checking or error handling regarding the contents of the tezos operations. The operations are sent to the other side as is, without any changes or error ...


1

Did you try value: { "int" : "10000" }? It seems that: the field value in parameters should be micheline (seeing how Unit is expressed) the entrypoint %stake has type nat (the linked contract says (nat %stake) in the parameter type) the Micheline encoding of the nat 10000 is {"int": "10000"} (this can be verified by ...


1

I suspect you mean amount as transaction size and not as a mutez value. The limits per transaction and block can be found in the following RPC: /chains/main/blocks/head/context/constants Edo Protocol hard_gas_limit_per_block: "10400000" hard_gas_limit_per_operation: "1040000" hard_storage_limit_per_operation: "60000" ...


1

Ledger's central service node (where it fetches balances) is out of sync with the network. If you've confirmed that operation has completed then your funds are indeed safe in the ledger address. It is simply that the Ledger Live application's node is out of sync. https://status.ledger.com/


1

You can use taquito for this. (https://tezostaquito.io/docs/estimate) Operation cost for invoking smart contract


1

Tezos Taquito has docs on how to drain an account which you can find here: https://tezostaquito.io/docs/drain_account It covers how to drain implicit and originated accounts.


1

[Edit] As Simon has suggested, the fee has been reduced, and the only restriction is to have 1 mutez left on the account or undelegate the account if the account is used for delegation. Jev suggested a link to the newly provided documentation. Tezos does not allow for sending the whole address balance, some dust left on the account is required to be able to ...


1

The answer given by Raphael Cauderlier in the gitlab issue helped solve the issue: "I have tried to reproduce this in sandbox (well, actually in mockup client); I think your problem is that 100 extra gas units are not enough to empty an account, apparently this consumes 400 gas units. Here is what I did (mockup_client is an alias for tezos-client --mode ...


1

Both transactions sent from your address have the same fee 0.01 tez that is not enough, taking into account the gas limit 50000. Try to set the fee 0.015 tez. If this doesn't help, it also can be a problem with the node you use, so try to use another one, like Tezos Giga Node. And yes, operations stay in the mempool for only an hour, however TzKT explorer ...


1

Don't worry, your funds are safe. You need to wait a bit and then try again with a higher fee or lower gas_limit. Why did that happen? You sent a transaction with large gas_limit: 50000 (despite a simple tz-to-tz transfer consumes about 1427 gas) and rather small, for such gas limit, fee:10000. So no one baker picked your transaction to include into a block ...


1

Account's counter is updated when the manager operation is included into the blockchain. It would be weird if the blockchain storage was affected by things not included in that blockchain :)


1

It seems that in Tezos there is no way to replace or cancel a transaction. So we would have to wait for it to be dropped (64 blocks ~64 minutes) from the mempool if transactions get stuck. source: https://twitter.com/dsintermediatd/status/1286341689368551428


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