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):
    Limit Order with Fees, declaring a regular Limit Order on which the operator can take a fee
    Conditional Transfer with Fees, declaring a regular Conditional Transfer on which the operator can take a fee
    Transfer with Fees, declaring a regular Transfer on which the operator can take a fee
    Limit Order, declaring intent to sell a certain amount of a certain asset in exchange for a different asset at a certain ratio.
    Conditional Transfer, requesting funds to be transferred from one vault to another if some on-chain event was recorded.
    Transfer, requesting funds to be transferred from one vault to another.
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/Transfer/Conditional Transfer with Fees, the signature is constructed as follows:
ECDSA(H(H(H(H(w1,w2),w3),w4),w5),kprivate)ECDSA(H(H(H(H(w_1, w_2), w_3),w_4),w_5), k_{private})
In the case of Limit Order and Transfer, the signature is constructed as follows:
ECDSA(H(H(w1,w2),w3),kprivate)ECDSA(H(H(w_1, w_2),w_3), k_{private})
In the case of Conditional Transfer, the signature is constructed as follows:
ECDSA(H(H(H(w1,w2),w4),w3),kprivate)ECDSA(H(H(H(w_1, w_2),w_4),w_3), k_{private})
Where ECDSA is the regular elliptic curve digital signature algorithm,
HH
is the Pedersen hash function,
kprivatek_{private}
is the user’s private key, and the words
w1w_1
,
w2w_2
,
w3w_3
,
w4w_4
,
w5w_5
and are 252-bit words containing the data required for the signature, as described in the next section.

Limit Order with Fees

For limit order with fees, the signature is constructed as follows:
ECDSA(H(H(H(H(w1,w2),w3),w4),w5),kprivate)ECDSA(H(H(H(H(w_1, w_2), w_3),w_4),w_5), k_{private})
w1w_1
is the assetId to be sold
w2w_2
is the assetId to be bought.
w3w_3
is the assetId used to pay the fee.
w4w_4
is defined as follows:
1
+-------+--------------+--------------+--------------+--------+
2
#bits | 27 | 64 | 64 | 64 | 32 |
3
+-------+--------------+--------------+--------------+--------+
4
label A B C D E
Copied!
    A: padding of zeros
    B: quantizedAmount to be sold.
    C: quantizedAmount to be bought
    D: quantizedAmount to pay fees
    E: nonce for the transaction.
w5w_5
is defined as follows:
1
+---+--------------+--------------+--------------+-----+-----+
2
#bits | 10| 64 | 64 | 64 | 32 | 17 |
3
+---+--------------+--------------+--------------+-----+-----+
4
label A B C D E F
Copied!
    A: order type
      3 for a Limit Order with Fees
    B: vaultId from which the user wants to use to pay fees.
    C: vaultId from which the user wants to take the sold asset
    D: vaultId from which the user wants to receive the bought asset.
    E: 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
    𝑡𝑢𝑛𝑖𝑥3600+24⌊\frac{𝑡_{𝑢𝑛𝑖𝑥}}{3600}⌋+24
    F: padding of zeros

Transfer/Conditional Transfer with Fees

For Transfer with Fees, the encoding is as follows
ECDSA(H(H(H(H(w1,w2),w3),w4),w5),kprivate)ECDSA(H(H(H(H(w_1, w_2), w_3),w_4),w_5), k_{private})
For Conditional Transfer with Fees, the encoding is as follows
ECDSA(H(H(H(H(H(w1,w2),w3),w6),w4),w5),kprivate)ECDSA(H(H(H(H(H(w_1, w_2), w_3),w_6),w_4),w_5), k_{private})
w1w_1
is the assetId to be sold
w2w_2
is the assetId used to pay the fee.
w3w_3
is the receiver_starkKey used to pay the fee.
w4w_4
is defined as follows
1
+-------+--------------+--------------+--------------+--------+
2
#bits | 27 | 64 | 64 | 64 | 32 |
3
+-------+--------------+--------------+--------------+--------+
4
label A B C D E
Copied!
    A: padding of zeros
    B: senderpositionId
    C: receiver positionId
    D: fee positionId
    E: nonce for the transaction.
w5w_5
is defined as follows:
1
+---+--------------+--------------+--------+-----------------+
2
#bits | 10| 64 | 64 | 32 | 81 |
3
+---+--------------+--------------+--------+-----------------+
4
label A B C D E
Copied!
    A: order type
      4 for Transfer with Fees
      5 for Conditional Transfer with Fees
    B: quantizedAmount to transfer
    C: quantizedAmount to limit the max fee
    D: 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
    𝑡𝑢𝑛𝑖𝑥3600+24⌊\frac{𝑡_{𝑢𝑛𝑖𝑥}}{3600}⌋+24
    E: padding of zeros
w6w_6
is the condition defined as Perdersen hash of the contract address and fact.
Where ECDSA is the regular elliptic curve digital signature algorithm,
HH
is the Pedersen hash function,
kprivatek_{private}
is the user’s private key, and the words
w1w_1
,
w2w_2
,
w3w_3
, and
w4w_4
are 252-bit words containing the data required for the signature, as described in the next section.

Limit Order/Transfer/Conditional Transfer (deprecated)

In the case of Limit Order and Transfer, the signature is constructed as follows:
ECDSA(H(H(w1,w2),w3),kprivate)ECDSA(H(H(w_1, w_2),w_3), k_{private})
In the case of Conditional Transfer, the signature is constructed as follows:
ECDSA(H(H(H(w1,w2),w4),w3),kprivate)ECDSA(H(H(H(w_1, w_2),w_4),w_3), k_{private})
w1w_1
is the assetId to be sold (or transferred).
w2w_2
depends on the order type:
    In a Limit Order,
    w2w_2
    is the assetId to be bought.
    In both Transfer and Conditional Transfer,
    w2w_2
    is the recipient starkKey.
w3w_3
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: vaultId from which the user wants to take funds.
    C:
      In case of a limit order, vaultId into which the user wants to receive funds.
      In case of a Transfer and Conditional Transfer, vaultId to receive the transferred funds.
    D: quantizedAmount to be sold/transferred.
    E: quantizedAmount to be bought (0 in case of a Transfer and Conditional Transfer order).
    F: nonce for 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
    𝑡𝑢𝑛𝑖𝑥3600+24⌊\frac{𝑡_{𝑢𝑛𝑖𝑥}}{3600}⌋+24
w4w_4
is used only in Conditional Transfer:
    w4w_4
    is the condition, which is the keccak of fact and FR_address masked to 250 bits.
keccak(FR_address, fact)) & 0x03FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
where FR_adddress is a contract address and fact is an uint256.
Last modified 2mo ago