Initial commit

This commit is contained in:
Yaser
2026-08-13 19:50:53 +03:30
commit 38084458fe
879 changed files with 95198 additions and 0 deletions

View File

@@ -0,0 +1,82 @@
# trading: trade executor
###### Sprint: ?
###DOC
* in case of reading first part processor or matching please skip this part.
for matching and executing orders openware creates a flow that manage by RabbitMQ and its consumers.
we have three consumers that works on trades:
1. order processor:<br >
does preliminary calculations and works on order like locking order<br >
2. matching:<br >
match orders and pass them to executor
3. trade executor:<br >
execute trades that matching creates
```mermaid
stateDiagram-v2
[*] --> API
API --> RabbitMQ
RabbitMQ --> OrderProcessor
OrderProcessor --> RabbitMQ
RabbitMQ --> Matching
Matching --> RabbitMQ
RabbitMQ --> Executor
Executor --> Notify
Notify --> [*]
```
#### Trade executor
##### what does trade executor do step by step:
1. it gets price and market and other informations
2. create_trade_and_strike_orders
1. get both orders
2. get both needed accounts
3. validate above informations
4. initialize new trade with above data
5. strike maker side
1. change order attr like volume,locked,...
2. unlocking funds and plus funds
2. check order fill
6. strike taker side
1. change order attr like volume,locked,...
2. check order fill
7. create operations and accountings recorde
1. record_liability_debit!
2. record_liability_credit!
3. record_liability_transfer!
4. record_revenues!
8. publish trade dependent on its state
```mermaid
graph TD
A[RabbitMQ] -->|submit payload| B(executor)
B --> |execute|C(get information about trade)
C --> D(get both orders)
D --> E(get both needed accounts)
E --> F(validation on datas)
F --> G(initialize new trade)
G --> H( maker side)
G --> I(taker side)
H --> J(striker)
I --> J
J -->K(calculate incomes and fees)
K --> L(update orders data like locked and volume,..)
L --> M(unlock funds and plus incomes)
M --> N{is order filled}
N --> |yes|O(change state to done)
O --> P(unlocked extra locked funds)
N -->|no and market order|Q(cancell order)
Q --> R(create operations record for cancellation)
R --> S(create operation records)
P --> S
S --> T(record_liability_debit, record_liability_credit, record_liability_transfer, record_revenues)
T --> U(save trade)
U --> V(publish trade)
```

View File

@@ -0,0 +1,73 @@
# trading: order matching
###### Sprint: ?
###DOC
* in case of reading first part processor please skip this part.
for matching and executing orders openware creates a flow that manage by RabbitMQ and its consumers.
we have three consumers that works on trades:
1. order processor:<br >
does preliminary calculations and works on order like locking order<br >
2. matching:<br >
match orders and pass them to executor
3. trade executor:<br >
execute trades that matching creates
```mermaid
stateDiagram-v2
[*] --> API
API --> RabbitMQ
RabbitMQ --> OrderProcessor
OrderProcessor --> RabbitMQ
RabbitMQ --> Matching
Matching --> RabbitMQ
RabbitMQ --> Executor
Executor --> Notify
Notify --> [*]
```
#### Order matching
##### what does order matching do step by step:
1. submit order ro engine
2. match method
1. get orderbooks
2. loop
1. is order filled?(all amount)
2. get top order of opposite order book(top means order with best price)
* for better and faster searching they use rbtree. for more information [click here](https://www.geeksforgeeks.org/red-black-tree-set-1-introduction-2/)
3. check can they create a trade
4. is trade valid?(trade validation):<br >
* not zero,calculation problems
5. fill both orders:<br >
* decrease order volume(if the opposite order is filled, we remove it from orderbook)
* filled order means that order completely get its needed volume
6. send to trade executor
```mermaid
graph TD
A[RabbitMQ] -->|submit payload| B(Matching)
B -->|submit engine|C(match method)
C --> D(get orderbooks)
D --> E(loop)
E --> F{order filled?}
F --> |yes|X(break)
F --> |no|G{opposit orderbook is blanked}
G --> |yes|H{is it limit order?}
H --> |yes|I(add to orderbook)
I --> X
H --> |no|J(cancel order)
J --> X
G --> |no|K(get top of opposit orderbook)
K --> L(make trade with top of opposit)
L --> |created trade|M{trade.blank?}
M --> |yes|H
M --> |no|N(validate trade)
N --> O(fill order)
O --> P(fill opposit order)
O --> |publish to executor|A
O --> E
X --> A
```

View File

@@ -0,0 +1,34 @@
# Order Creation: Api
### Outcome:
Users create sell or buy order.
### Implementation description:
#### Endpoints:
- POST {$domain}/api/v2/peatio/marker/orders/fiat
#### Params
- market
- side
- volume
- ord_type
#### File destination:
{$Dena_Path}/app/api/v2/market/orders.rb
```mermaid
sequenceDiagram
title Order Creation
User->>Ranj: market, side, volume, ord_type
Ranj->>Dena: POST: after client side checking
Dena->>Ranj: 4xx if lose any required parameters
Dena->>Ranj: 4xx if users level lower than the
Dena->>Dena: compute lock balance
Dena->>Dena: send order to the Order Processor queue
Dena->>Ranj: 2xx order record created
Ranj->>User: show The Order response
```

View File

@@ -0,0 +1,52 @@
# trading: order processor
###### Sprint: ?
###DOC
for matching and executing orders openware creates a flow that manage by RabbitMQ and its consumers.
we have three consumers that works on trades:
1. order processor:<br >
does preliminary calculations and works on order like locking order<br >
2. matching:<br >
match orders and pass them to executor
3. trade executor:<br >
execute trades that matching creates
```mermaid
stateDiagram-v2
[*] --> API
API --> RabbitMQ
RabbitMQ --> OrderProcessor
OrderProcessor --> RabbitMQ
RabbitMQ --> Matching
Matching --> RabbitMQ
RabbitMQ --> Executor
Executor --> Notify
Notify --> [*]
```
#### Order Processor
##### what does order processor do step by step:
1. initializing: submit all orders with pending state(take them to ram)
2. submit:<br >
1. it finds order by id with lockversion
2. check state of order
3. update locked and balance of account
4. submit operation and accounting
5. update order state to WAIT
6. enqueue in rabbit (pass orders to matching)
```mermaid
graph TD
A[api] -->|enque| B(RabbitMQ)
B --> C(order processor)
C --> |submit order in ram|D{check state}
D -->|pending| E[order locking]
D -->|else| B
E -->G[submit operation and accounting]
G --> F[update state to wait]
F --> |enque to matching| B
```