Hot answers tagged

3

Only admin can call mintOrBurn in that particular contract. As you can see in the contract storage, tz1KqTpEZ7Yob7QbPE4Hy4Wo8fHG8LhKxZSx is the admin, so you need a private key from this address. Fortunately, tz1KqTpEZ7Yob7QbPE4Hy4Wo8fHG8LhKxZSx is one of the bootstrap addresses with known private key edsk3gUfUPyBSfrS9CCgmCiQsTCHGkviBDusMxDJstFtojtc1zcpsh, ...


2

The FA1.2 template was updated this week by Keefer Taylor. It will be updated in https://smartpy.io templates this weekend. Template link: https://smartpy.io/ide?cid=Qma5v9x6xjbzB82hjhr5Y5Sw2oppRzhyNBN11eVVyXpvxv&k=ea98e1d25d85d92f75c7 Here is an example after deployment: https://tzcomet.io/#/explorer%3Fexplorer-input%...


2

Currently, LIGO does not support failing with an arbitrary type like a tuple or record. However you can embed Michelson to fail with the tuple.


2

You are correct. There is not a way to get the value directly. You would have to originate a contract like this. Let's call it getnat.tz. We will use it to create an error message after a dry run call. parameter (nat); storage unit; code { CAR; FAILWITH }; Now we can call it from the client. tezos-client transfer 0 from alice to token \ --...


2

I thought that it was a copy of the previous main net + the new changes to be applied (Granada in this case). It isn't, testnets share no history with mainnet, or each-other. From the Test Networks docs: every time a new protocol is proposed on Mainnet, a new test network is spawned. This also makes synchronization much faster than with a long-lived ...


2

the allowance is only 10 and when I try to chance it I get an UnsafeAllowanceChange error. This error is raised because the allowance is already 10, from the UnsafeAllowanceChange documentation: Fires if: Allowance change from non-zero value to non-zero value is performed. This contract does not allow such an update, see the corresponding attack vector for ...


2

Its not possible to send lower than 1 mutez. nat is also required to be a whole number. Tezos/XTZ has 6 decimal places. When a user sees "1 XTZ" in an app, that is represented as 1000000 on the blockchain (6 zeros for 6 decimal places). The blockchain and RPC deal in this smaller scale (called mutez) and its up to each application to scale it up to ...


2

When you add tezAmount liquidity you deposit tezAmount * tokenPool / xtzPool tokens (with division rounding up) and receive tezAmount * lqtTotal / xtzPool LQT (with division rounding down). When you remove lqtAmount liquidity you get back lqtAmount * xtzPool / lqtTotal tez and lqtAmount * tokenPool / lqtTotal tokens (with divisions rounding down).


1

tzBTC uses 8 decimals like Bitcoin, so you should divide tokenPool by 100000000 to get the number of tzBTC held by the contract.


1

When liquidity providers deposit tez and tzBTC they receive a liquidity token in return and when they redeem liquidity tokens they receive back tez and tzBTC. The subsidy means they will receive more back than they put in, which you can think of as a "reward" for providing liquidity. See this question for the actual calculations: how to calculate ...


1

One way to think about it is to think about how many lqt would be minted if the transaction hit the contract in its current state and allow for some slippage. For example, with 10% slippage, you would let minLqt be 10% lower than what you would get if the transaction hit the contract in its current state. The slippage number for this can be quite higher than ...


1

We've implemented a version of this for Murmuration DAO, and I think it's a pretty valid and cool idea. Our code is here: https://github.com/Hover-Labs/murmuration/blob/main/smart_contracts/token.py You can see an example in dao.py that shows how you can read data out of the token snapshots.


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