Fixed some mdx issues
This commit is contained in:
Piotr Janosz
committed by
fabioberger
fabioberger
parent
99ffe6bb2d
commit
42ed4e393f
@@ -9,13 +9,13 @@ export const meta = {
|
||||
type: 'Docker images'
|
||||
};
|
||||
|
||||
# Title
|
||||
## Title
|
||||
|
||||
We designed the 0x protocol to be extensible exchange infrastructure for the entire crypto economy. 0x's functionality can be extended through extension contracts, which broaden how 0x orders can be filled. There are a variety ways to build extension contracts. An Extension contract can perform work on the users behalf. They can validate that users belong to a specific group. Extension contracts can even be written to join multiple Decentralised Finance projects together.
|
||||
|
||||
0x allows for contracts to perform 0x operations, though before version 2 of the protocol there was no way to enforce that an order executed via a specific contract. The 0x order format now contains a field senderAddress. When this is defaulted to empty it is completely open for any anyone to fill. The Forwarder uses open orders with an unspecified sender address to perform a fill on behalf of the user. When the sender address is specified the 0x protocol ensures the operation originates from this address. For example it's possible to create a KYC (Know Your Customer) orderbook. This orderbook contains orders specifying the sender address as the KYC attestation contract. 0x protocol enforces all operations originate from the KYC contract in which all addresses have been validated by this contract.
|
||||
|
||||
# Forwarder Contract
|
||||
## Forwarder Contract
|
||||
|
||||
Wrapping ETH into ERC-20 compliant wETH has been a large barrier to adoption for the greater Decentralised Finance ecosystem. The 0x core team wrote and deployed a Forwarder contract to address these issues. You have used the Forwarder Contract if you have purchased tokens through 0x Instant. The Forwarder is an example of an extension which performs work on the users behalf.
|
||||
|
||||
@@ -25,13 +25,13 @@ The Forwarder extends the behavior of trading on 0x. It presents a different int
|
||||
|
||||
Projects can use the Forwarder contract and a Relayers orders in their own integrations. We've seen great adoption of 0x Instant, which uses the Forwarder under the hood. These projects are able to use the affiliate fee in the Forwarder to collect fees in ETH for the trades they originate.
|
||||
|
||||
# Dutch Auction Contract
|
||||
## Dutch Auction Contract
|
||||
|
||||
The price of an asset decreases over time and the buyer submits a matching order when they believe the asset is appropriately priced. The Dutch Auction contract guarantees the asset is exchanged for the current price, given the block time. The Dutch Auction contract is an example of an extension which validates some state before matching two orders.
|
||||
|
||||
The Dutch Auction contract is powered by the 0x Exchange contracts matchOrders function and extends the order format to include additional data. When using match orders, two orders are passed in as parameters, known as the sell order and the buy order. The seller of the asset creates an order for the asset at the lowest price. When a buyer decides the asset is at an acceptable price, they create a matching order for that amount. The buyer submits both the sell order and the buy order to the Dutch Auction contract.
|
||||
|
||||
# Cryptography used by 0x protocol
|
||||
## Cryptography used by 0x protocol
|
||||
|
||||
Once an order maker has decided on all the details of the trade they wish to make, the last step is for them to cryptographically commit to the trade. 0x uses two fundamental building blocks of cryptography to make this happen. This section will introduce these building blocks and how 0x uses them.
|
||||
|
||||
@@ -52,7 +52,7 @@ A digital signature is a mathematical scheme for verifying the authenticity and
|
||||
|
||||
In order for a 0x order to be considered valid and fillable, it must have all the stipulated fields listed above, and come with a digital signature from the maker attesting to all the field values. At this point, the 0x order is ready to be shared with potential counter-parties.
|
||||
|
||||
# Off-chain relay, on-chain settlement
|
||||
## Off-chain relay, on-chain settlement
|
||||
|
||||
Up until this point, the 0x order was created and is sitting on the order maker’s computer. In order to find a counter-party for the order, where does it need to go? Unlike other decentralized exchanges, 0x does not store orders on the blockchain. Instead orders are stored off-chain, and only trade settlement occurs on-chain.
|
||||
|
||||
|
||||
@@ -8,13 +8,13 @@ export const meta = {
|
||||
type: 'Starter projects'
|
||||
};
|
||||
|
||||
# Title
|
||||
## Title
|
||||
|
||||
We designed the 0x protocol to be extensible exchange infrastructure for the entire crypto economy. 0x's functionality can be extended through extension contracts, which broaden how 0x orders can be filled. There are a variety ways to build extension contracts. An Extension contract can perform work on the users behalf. They can validate that users belong to a specific group. Extension contracts can even be written to join multiple Decentralised Finance projects together.
|
||||
|
||||
0x allows for contracts to perform 0x operations, though before version 2 of the protocol there was no way to enforce that an order executed via a specific contract. The 0x order format now contains a field senderAddress. When this is defaulted to empty it is completely open for any anyone to fill. The Forwarder uses open orders with an unspecified sender address to perform a fill on behalf of the user. When the sender address is specified the 0x protocol ensures the operation originates from this address. For example it's possible to create a KYC (Know Your Customer) orderbook. This orderbook contains orders specifying the sender address as the KYC attestation contract. 0x protocol enforces all operations originate from the KYC contract in which all addresses have been validated by this contract.
|
||||
|
||||
# Forwarder Contract
|
||||
## Forwarder Contract
|
||||
|
||||
Wrapping ETH into ERC-20 compliant wETH has been a large barrier to adoption for the greater Decentralised Finance ecosystem. The 0x core team wrote and deployed a Forwarder contract to address these issues. You have used the Forwarder Contract if you have purchased tokens through 0x Instant. The Forwarder is an example of an extension which performs work on the users behalf.
|
||||
|
||||
@@ -24,17 +24,17 @@ The Forwarder extends the behavior of trading on 0x. It presents a different int
|
||||
|
||||
Projects can use the Forwarder contract and a Relayers orders in their own integrations. We've seen great adoption of 0x Instant, which uses the Forwarder under the hood. These projects are able to use the affiliate fee in the Forwarder to collect fees in ETH for the trades they originate.
|
||||
|
||||
# Dutch Auction Contract
|
||||
## Dutch Auction Contract
|
||||
|
||||
The price of an asset decreases over time and the buyer submits a matching order when they believe the asset is appropriately priced. The Dutch Auction contract guarantees the asset is exchanged for the current price, given the block time. The Dutch Auction contract is an example of an extension which validates some state before matching two orders.
|
||||
|
||||
The Dutch Auction contract is powered by the 0x Exchange contracts matchOrders function and extends the order format to include additional data. When using match orders, two orders are passed in as parameters, known as the sell order and the buy order. The seller of the asset creates an order for the asset at the lowest price. When a buyer decides the asset is at an acceptable price, they create a matching order for that amount. The buyer submits both the sell order and the buy order to the Dutch Auction contract.
|
||||
|
||||
# Cryptography used by 0x protocol
|
||||
## Cryptography used by 0x protocol
|
||||
|
||||
Once an order maker has decided on all the details of the trade they wish to make, the last step is for them to cryptographically commit to the trade. 0x uses two fundamental building blocks of cryptography to make this happen. This section will introduce these building blocks and how 0x uses them.
|
||||
|
||||
## Cryptographic hash function
|
||||
### Cryptographic hash function
|
||||
|
||||
A cryptographic hash function is a function that maps an input of arbitrary size to an output of fixed size (a hash). It is a one-way function meaning that it is infeasible to invert. The input data is typically called the message and the output the message digest.
|
||||
|
||||
@@ -51,7 +51,7 @@ A digital signature is a mathematical scheme for verifying the authenticity and
|
||||
|
||||
In order for a 0x order to be considered valid and fillable, it must have all the stipulated fields listed above, and come with a digital signature from the maker attesting to all the field values. At this point, the 0x order is ready to be shared with potential counter-parties.
|
||||
|
||||
# Off-chain relay, on-chain settlement
|
||||
## Off-chain relay, on-chain settlement
|
||||
|
||||
Up until this point, the 0x order was created and is sitting on the order maker’s computer. In order to find a counter-party for the order, where does it need to go? Unlike other decentralized exchanges, 0x does not store orders on the blockchain. Instead orders are stored off-chain, and only trade settlement occurs on-chain.
|
||||
|
||||
|
||||
@@ -7,13 +7,13 @@ export const meta = {
|
||||
type: 'Command-line tools'
|
||||
};
|
||||
|
||||
# Title
|
||||
## Title
|
||||
|
||||
We designed the 0x protocol to be extensible exchange infrastructure for the entire crypto economy. 0x's functionality can be extended through extension contracts, which broaden how 0x orders can be filled. There are a variety ways to build extension contracts. An Extension contract can perform work on the users behalf. They can validate that users belong to a specific group. Extension contracts can even be written to join multiple Decentralised Finance projects together.
|
||||
|
||||
0x allows for contracts to perform 0x operations, though before version 2 of the protocol there was no way to enforce that an order executed via a specific contract. The 0x order format now contains a field senderAddress. When this is defaulted to empty it is completely open for any anyone to fill. The Forwarder uses open orders with an unspecified sender address to perform a fill on behalf of the user. When the sender address is specified the 0x protocol ensures the operation originates from this address. For example it's possible to create a KYC (Know Your Customer) orderbook. This orderbook contains orders specifying the sender address as the KYC attestation contract. 0x protocol enforces all operations originate from the KYC contract in which all addresses have been validated by this contract.
|
||||
|
||||
# Forwarder Contract
|
||||
## Forwarder Contract
|
||||
|
||||
Wrapping ETH into ERC-20 compliant wETH has been a large barrier to adoption for the greater Decentralised Finance ecosystem. The 0x core team wrote and deployed a Forwarder contract to address these issues. You have used the Forwarder Contract if you have purchased tokens through 0x Instant. The Forwarder is an example of an extension which performs work on the users behalf.
|
||||
|
||||
@@ -23,13 +23,13 @@ The Forwarder extends the behavior of trading on 0x. It presents a different int
|
||||
|
||||
Projects can use the Forwarder contract and a Relayers orders in their own integrations. We've seen great adoption of 0x Instant, which uses the Forwarder under the hood. These projects are able to use the affiliate fee in the Forwarder to collect fees in ETH for the trades they originate.
|
||||
|
||||
# Dutch Auction Contract
|
||||
## Dutch Auction Contract
|
||||
|
||||
The price of an asset decreases over time and the buyer submits a matching order when they believe the asset is appropriately priced. The Dutch Auction contract guarantees the asset is exchanged for the current price, given the block time. The Dutch Auction contract is an example of an extension which validates some state before matching two orders.
|
||||
|
||||
The Dutch Auction contract is powered by the 0x Exchange contracts matchOrders function and extends the order format to include additional data. When using match orders, two orders are passed in as parameters, known as the sell order and the buy order. The seller of the asset creates an order for the asset at the lowest price. When a buyer decides the asset is at an acceptable price, they create a matching order for that amount. The buyer submits both the sell order and the buy order to the Dutch Auction contract.
|
||||
|
||||
# Cryptography used by 0x protocol
|
||||
## Cryptography used by 0x protocol
|
||||
|
||||
Once an order maker has decided on all the details of the trade they wish to make, the last step is for them to cryptographically commit to the trade. 0x uses two fundamental building blocks of cryptography to make this happen. This section will introduce these building blocks and how 0x uses them.
|
||||
|
||||
@@ -50,7 +50,7 @@ A digital signature is a mathematical scheme for verifying the authenticity and
|
||||
|
||||
In order for a 0x order to be considered valid and fillable, it must have all the stipulated fields listed above, and come with a digital signature from the maker attesting to all the field values. At this point, the 0x order is ready to be shared with potential counter-parties.
|
||||
|
||||
# Off-chain relay, on-chain settlement
|
||||
## Off-chain relay, on-chain settlement
|
||||
|
||||
Up until this point, the 0x order was created and is sitting on the order maker’s computer. In order to find a counter-party for the order, where does it need to go? Unlike other decentralized exchanges, 0x does not store orders on the blockchain. Instead orders are stored off-chain, and only trade settlement occurs on-chain.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user