Your code above has some issues that I will describe below. Also, you are confusing off-chain metadata with on-chain metadata, tzip16 and tzip21 allow those structures because they were designed to be stored off-chain. (Only possible to store onchain with stringified JSON or in bytes.)
In make_metadata you are trying to create a map with different value ...
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, ...
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 ...
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 ...
The correct way to do this is simply:
def withdraw(self, amount):
The solidity translation tool I used didn't handle this properly
Yes, this looks correct. All divisions are rounded down except for tokens deposited in addLiquidity.
The way to think about it is that the CPMM is always "greedy", i.e. it always takes more and gives you less.
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 ...
As you can see in the explorer, the addLiquidity entrypoint accepts parameter of type
(pair address (pair nat (pair nat timestamp))
But you pass (according to the original Dexter contract):
(pair (pair address nat) (pair nat timestamp))
These are two different types, so you need to re-group your Pairs this way: