> ## Documentation Index
> Fetch the complete documentation index at: https://docs.intention.xyz/llms.txt
> Use this file to discover all available pages before exploring further.
# Matching
> Order book, bagaimana prioritas harga-waktu direpresentasikan, dan bagaimana masa berlaku order serta pencegahan self-trade diselesaikan terhadapnya.
Matching adalah tahap di dalam [eksekusi kernel](/id/protocol/architecture/kernel), bukan layanan yang diajak bicara oleh chain. Tahap ini mengambil order milik blok dalam urutan terkomitnya, menjalankannya terhadap order book, dan menghasilkan eksekusi. Yang tidak dilakukannya: memindahkan saldo siapa pun — itu tugas [lembaga kliring](/id/protocol/architecture/clearinghouse), dan terjadi setelah matching selesai.
Pemisahan itulah yang membuat engine ini dapat diuji. Matching menjawab *apa yang bertransaksi dengan apa*. Lembaga Kliring menjawab *berapa biayanya dan siapa kini berutang kepada siapa*.
Order book
Setiap instrumen punya order book sendiri, disimpan di memori sebagai tiga struktur yang bekerja sama:
Slab arena — satu wilayah slot order teralokasi di muka
Level hargapeta terurut, harga → levelpuncak ditemukan dengan berjalan ke ujung, bukan memindai
Indeks orderid order → slotbatal dan ubah berwaktu konstan
order
order
order
order
order
Rantai berkait ganda dalam urutan kedatangan, sehingga prioritas dalam level bersifat posisional, bukan dihitung.
Alasan urutan pakai ulang tetapSlot yang dibebaskan dipakai ulang dalam urutan tetap dan indeks di-seed tetap. Bukan pilihan performa: dua validator dengan urutan pakai ulang berbeda akan fork.
kepala tiap level
akses langsung
| Struktur | Peran |
| ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Level harga** | Peta terurut dari harga ke level, sehingga bid terbaik dan ask terbaik ditemukan dengan berjalan ke ujung alih-alih memindai |
| **Rantai order** | Senarai berkait ganda yang merangkai order dalam urutan kedatangan, sehingga prioritas di dalam satu level bersifat posisional alih-alih dihitung |
| **Indeks order** | Peta langsung dari ID order ke slotnya, sehingga pembatalan dan perubahan berwaktu konstan alih-alih berupa pencarian |
Order tinggal di dalam `slab arena` — wilayah teralokasi di muka dengan alokasi dan pelepasan berwaktu konstan. Karena itu operasi order book tidak melakukan alokasi di jalur panas, dan slot yang dibebaskan dipakai ulang dalam urutan tetap alih-alih di mana pun alokator kebetulan menaruhnya. Detail terakhir itu bukan pilihan performa: jika dua validator memakai ulang slot dalam urutan berbeda, apa pun yang mengamati tata letak slot akan menyimpang.
Disiplin yang sama berlaku pada indeks order, yang di-seed secara tetap alih-alih acak. Peta hash dengan seed per proses adalah pertahanan standar terhadap serangan kolisi; di jalur eksekusi konsensus, itu adalah fork.
Harga berupa bilangan bulat di sepanjang jalur — satuan subtick, bukan desimal. Lihat [Presisi](/id/trading/precision) untuk pemetaannya ke apa yang Anda kirim.
Prioritas
Prioritas ditentukan harga dulu, lalu posisi dalam rantai pada harga itu. “Waktu” adalah posisi kanonis order tersebut dalam barisan blok yang dikomit, bukan kapan order itu tiba di suatu node.
Inilah yang menghapus perlombaan latensi intrablok. Dua order dalam blok yang sama punya urutan prioritas terdefinisi yang dihitung identik oleh setiap validator, dan sedekat apa pun Anda dengan node tertentu tidak mengubahnya. Antarblok, kedatangan tetap berpengaruh — tetapi satuan persaingannya adalah blok, bukan mikrodetik.
Urutan tahap kernel memperkuat hal ini: pembatalan dieksekusi sebelum penempatan agresif di dalam satu blok, sehingga kuotasi terpasang tidak bisa diambil order yang masuk di blok yang sama dengan pembatalannya.
Mencocokkan order
Order masuk
Melintasi order book?
Konsumsi level lawan terbaik
Terbitkan eksekusi
Selesai
Pasang atau tolak sisanya, sesuai masa berlakuGTC terpasang · IOC membatalkannya · FOK tidak dieksekusi kecuali penuh · post-only ditolak alih-alih melintasi
sisa — ambil level berikutnya
tanpa sisa
Matcher berulang kali mengonsumsi kepala sisi lawan, menerbitkan satu eksekusi untuk setiap maker yang diambilnya, sampai order masuk habis atau order book tidak lagi bersilangan. Apa yang terjadi pada sisanya ditentukan oleh masa berlaku order:
* **GTC** — pasang sisanya di order book.
* **IOC** — batalkan sisanya.
* **FOK** — jika order tidak bisa dieksekusi penuh, tidak ada yang dieksekusi sama sekali.
* **ALO** — post-only: jika order akan mengambil likuiditas, order itu ditolak alih-alih melintasi order book.
Eksekusi membawa atribusi sejak dihasilkan. Setiap eksekusi mencatat posisinya dalam barisan eksekusi untuk instrumennya, dan posisi per instrumen itu kemudian diselesaikan menjadi satu urutan tunggal untuk seluruh blok saat output dirakit. Inilah yang membuat sebuah event bisa dilacak kembali, di kemudian hari, ke transaksi persis dan titik persis di dalam blok yang menyebabkannya.
Pencegahan self-trade
Ketika order masuk akan bertemu likuiditas terpasang milik pemilik yang sama, pencocokan itu ditekan alih-alih dieksekusi. Sisi mana yang mengalah dapat dikonfigurasi:
| Mode | Perilaku |
| ---------------- | --------------------------------------------------------- |
| **Expire taker** | Order yang masuk dibatalkan |
| **Expire maker** | Order terpasang dibatalkan dan order yang masuk berlanjut |
| **Expire both** | Keduanya dibatalkan |
Maker yang dibatalkan dengan cara ini dikumpulkan selama matching dan dihapus sebagai bagian dari blok yang sama, sehingga order book tidak membawa order yang sudah ditekan.
Kepemilikan untuk pemeriksaan ini ditentukan pada tingkat akun yang dilacak order book. Lihat [Pencegahan self-trade](/id/trading/self-trade-prevention) untuk sudut pandang sisi trading.
Apa yang tidak dilakukan matching
Matching tidak menghitung biaya, tidak merealisasi laba dan rugi, tidak menyesuaikan posisi, dan tidak memeriksa margin. Semua itu terjadi setelah matching, di [lembaga kliring](/id/protocol/architecture/clearinghouse), digerakkan oleh eksekusi yang dihasilkan matching.
Matching juga tidak memutuskan apakah order boleh ada. Kecukupan margin, batas order terbuka, kendala reduce-only, dan konversi market-to-limit sudah diselesaikan sebelum order sampai ke order book. Saat matcher melihat order, pertanyaannya tinggal di titik mana order itu ditempatkan di order book.
Ke mana selanjutnya
Apa yang terjadi pada saldo dan posisi setelah eksekusi terbentuk.
Sudut pandang sisi trading: apa yang bisa Anda kirim dan bagaimana masing-masing berperilaku.
Kedalaman, level, dan cara membaca order book sebagai trader.
Letak matching dalam eksekusi blok.