Integers have arbitrary precision, meaning that the only size limit is the gas_limit/storage_limit.
$ ./tezos-codec describe ground.Z binary schema
| Name | Size | Contents |
| Unnamed field 0 | Determined from data | $Z.t ...
sp.unpack gives you an option (because Michelson gives an option when you call UNPACK) that you need to open.
You can do it like this
myBytes = sp.unpack(packedString, t = sp.TBytes).open_some()
if you're sure that packedString is indeed a packed sp.TBytes.
If you're not 100% sure, you can add an optional error message to open_some().
Edo2net is not the default protocol in sandbox.
You will need to provide the --protocol-hash arg:
tezos-sandbox mini \
--size 1 \
--number-of-boot 2 \
--protocol-hash PtEdo2ZkT9oKpimTah6x2embF25oss54njMuPzkJTEi5RqfdZFA \
--until-level 2_000_000 \
Yes and no.
There are no built-in convertors in Michelson.
Some operations are doable nonetheless.
For example, the string manipulations template demonstrates kind of extreme string manipulations in SmartPy.
For mutez, you could start to convert to int (by dividing by 1 mutez) and then use the same technics.
That was fixed in granadanet by this merge request: https://gitlab.com/tezos/tezos/-/merge_requests/2815
You need to add self.add_flag("initial-cast") in the contract constructor to solve the issue until mainnet adopts the new protocol.
Doing math on nats casts them to an int. The value needs to be casted back to a nat after the subtraction:
self.data.shop_items[item_to_purchase.key].amount = sp.as_nat(self.data.shop_items[item_to_purchase.key].amount - item_to_purchase.value)
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:
Can you give more information on your setup? Like which hash do you use?
In the latest versions of BLS12-381 (used by Edo), it has been decided to pad the bytes for Fr elements. Some users requested it because it was a bit annoying to push 32 bytes if the elements should represent 5 for instance (which can be encoded with 0x05). Previous versions of BLS12-...