StarkEx Deep Dive 🐬
Important Links
Spot Trading
To interact with the system, users have to send messages containing orders they wish to execute. The following order types are currently supported (the withdrawal transaction doesn't require a signature and therefore, is ignored here):
The transaction is sent directly to the application through an interface exposed there, and the validity of the signature over all the fields is verified by the proof system.
In the case of Limit Order and Transfer, the signature is constructed as follows:
In the case of Conditional Transfer, the signature is constructed as follows:
Where ECDSA is the regular elliptic curve digital signature algorithm,
is the Pedersen hash function,
is the user’s private key, and the words
,
,
, and
are 252-bit words containing the data required for the signature, as described in the next section.
Message Word Definition
is the
assetId to be sold (or transferred).
depends on the order type:
- In a Limit Order,is the
assetIdto be bought. - In both Transfer and Conditional Transfer,is the recipient
starkKey.
is a bit-packed message whose lower 245 bits conform to the format described below, depending on the order type.
1
+---+---------+---------+-------------------+-------------------+---------+-------+
2
#bits | 4 | 31 | 31 | 63 | 63 | 31 | 22 |
3
+---+---------+---------+-------------------+-------------------+---------+-------+
4
label A B C D E F G
Copied!
Where:
A: order type- 0 for a Limit Order
- 1 for a Transfer
- 2 for a Conditional Transfer
B:vaultIdfrom which the user wants to take funds.C:- In case of a limit order,
vaultIdinto which the user wants to receive funds. - In case of a Transfer and Conditional Transfer,
vaultIdto receive the transferred funds.
D:quantizedAmountto be sold/transferred.E:quantizedAmountto be bought (0 in case of a Transfer and Conditional Transfer order).F:noncefor the transaction.G:expirationTimestamp, in hours since the Unix epoch. For example, for the order to expire 24 hours from the beginning of the current hour, set the timestamp to.
is used only in Conditional Transfer:
- is the
condition, which is the keccak offactandFR_addressmasked to 250 bits.
keccak(FR_address, fact)) & 0x03FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFwhere
FR_adddress is a contract address and fact is an uint256.Examples
Suppose Alice and Bob are two users trading assets 𝑋 (whose ID is 100) and Y (whose ID is 200), with the following setup:
Transfer Example
Suppose that Alice wants to transfer 25 𝑋 from her vault with ID 7 to Bob’s vault with ID 12. In this case, she will sign the following message:
Where
is formatted as follows
1
+---+---------+---------+-------------------+-------------------+-----------+-------+
2
value | 1 | 7 | 12 | 25 | 0 | nonce | ts |
3
+---+---------+---------+-------------------+-------------------+-----------+-------+
4
label A B C D E F G
Copied!
Conditional Transfer Example
Now Alice wants to do the same transfer but conditional on
fact being registered in FR_address . In this case, she will sign the following message:
Where
is:
1
condition = keccak(FR_address, fact))
2
& 0x03FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
Copied!
and
is formatted as follows:
1
+---+---------+---------+-------------------+-------------------+-----------+-------+
2
value | 2 | 7 | 12 | 25 | 0 | nonce | ts |
3
+---+---------+---------+-------------------+-------------------+-----------+-------+
4
label A B C D E F G
Copied!
Limit Order Example
Suppose that now Alice wants to trade 9000 𝑋 from her vault with ID 7 for 15000 𝑌, to be deposited in her vault with ID 4 if the trade succeeds. In this case, she will sign the following message:
Where
is formatted as follows:
1
+---+---------+---------+-------------------+-------------------+-----------+-------+
2
value | 0 | 7 | 4 | 9000 | 15000 | nonce | ts |
3
+---+---------+---------+-------------------+-------------------+-----------+-------+
4
label A B C D E F G
Copied!
Last modified 1yr ago
Export as PDF
Copy link