KT1 addresses are computed from origination nonce. The origination nonce is made of operation hash (the operation that creates the origination) and its index (the index starts from 0 and it gets incremented for each origination in the operation).
The operation hash depends on block header of the branch where it was included.The CHAIN_ID depends on genesis ...
In case someone needs precise calculations.
Say, you have an operation group hash onvsLP3JFZia2mzZKWaFuFkWg2L5p3BDUhzh5Kr6CiDDN3rtQ1D and an origination index 0 which is increased for every origination operation in the group including internal operations. In order to calculate originated contract hash you need to do:
Base58 decode (with checksum) the opg ...
For sure! For instance, when originating with tezos-client, in this example I send 99 tez from the bootstrap1 account when originating the contract my_contract:
$ tezos-client originate contract my_contract transferring 99 \
from bootstrap1 running my_contract.tz \
--init Unit --burn-cap 10.0
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 \
The problem lies in this part (set %signers key). The set requires that its elements are comparable, but key type is not comparable. To get around this, you could use key_hash for the set instead, which is comparable and you can compute it from key.
Michelson full grammar
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-...