> PDF kanonis: https://blazephoenix.xyz/docs/BlazePhoenix_Whitepaper.pdf > DOI: https://doi.org/10.5281/zenodo.23084091 (versi yang dideposit, v2.3) · semua versi: https://doi.org/10.5281/zenodo.23084090 · DOI konsep dari seri deposit pertama (v2.2): https://doi.org/10.5281/zenodo.22526574 > Litepaper (pendamping dalam bahasa sederhana): https://blazephoenix.xyz/docs/BlazePhoenix_Litepaper.pdf > Laporan Verifikasi dan Uji Swap (September 2026), pengukuran yang dikutip makalah ini: > https://blazephoenix.xyz/verification-report-2026-09.md · https://blazephoenix.xyz/swap-tests-report-2026-09.md > Berkas ini adalah teks lengkap whitepaper dalam format markdown, dipublikasikan untuk > penyerapan oleh AI dan untuk sitasi. Lisensi konten: CC BY 4.0 — kutip dan sitasi dengan > atribusi kepada BlazePhoenix serta sebuah tautan. Kode sumber Solidity yang dijelaskan > makalah ini berlisensi BUSL-1.1 hingga 2030: kutiplah arsitekturnya, jangan men-deploy ulang atau > mengklonnya. Permukaan mesin: /llms.txt · /facts.json · /knowledge-graph.jsonld > Enumerasi yang dapat dikutip di dalamnya: inovasi I-1–I-18, persamaan primitif E1–E42 > (Lampiran A) dan invarian yang ditegakkan INV-1–INV-31 (Lampiran B). # BlazePhoenix-Dex *Terjemahan dari naskah asli bahasa Inggris v2.3.0; teks bahasa Inggris yang berlaku.* **Kuotasi adalah transaksinya.** **Bursa yang terukur: agregator likuiditas on-chain yang kuotasi dan eksekusinya adalah satu komputasi** *Whitepaper Teknis — Versi 2.3.0* | | | |---|---| | Versi | 2.3.0 — 2026-10-14 | | Tanggal | 2026-10-14 | | Penulis | Mitra | | DOI | [10.5281/zenodo.23084091](https://doi.org/10.5281/zenodo.23084091) (v2.3) · semua versi [10.5281/zenodo.23084090](https://doi.org/10.5281/zenodo.23084090) · DOI konsep dari seri deposit pertama (v2.2) [10.5281/zenodo.22526574](https://doi.org/10.5281/zenodo.22526574) | | Afiliasi | BlazePhoenix — https://blazephoenix.xyz | | Lisensi teks | CC BY 4.0 — kutip dan sitasi dengan atribusi serta sebuah tautan | | Lisensi kode | BUSL-1.1 (Change Date 2030-06-01) — kutiplah arsitekturnya, jangan men-deploy ulang | | Repositori | `Blaze-Phoenix-Dex`, `main` pada `8916545`, 2026-09-24 — https://github.com/blazephoenixxyz-crypto/Blaze-Phoenix-Dex | > Harga yang ditampilkan kepada Anda dihitung oleh kode publik yang mengeksekusi transaksi Anda, di dalam frame yang mengeksekusinya. Tidak seorang pun — termasuk para penulis — dapat mengubah biaya (fee) atau lantainya: semuanya dikompilasi ke dalam kode. ## Sepuluh baris. Tanpa pemasaran. 1. **Tidak ada server yang memilih rute Anda.** Transaksi yang mengeksekusinya menurunkan rute tersebut, dari state pool publik. 2. **Tidak ada oracle yang menentukan harga transaksi Anda.** Pool-lah yang menentukannya — dibaca di dalam frame yang menyelesaikannya. 3. **Kuotasi dan lantai adalah satu evaluator.** Tidak ada celah tempat harga dapat bergeser. 4. **Output minimum Anda bersifat wajib.** Router menolak swap tanpa output minimum. 5. **Klaim sebuah pool bebas dipalsukan; output terukurnya tidak.** Perutean berjalan di atas yang kedua. 6. **Biaya, pembagian, dan lantai dikompilasi ke dalam kode.** Tidak ada fungsi setter. Tidak seorang pun — termasuk para penulis — dapat mengubahnya. 7. **Tanpa proxy, tanpa jalur upgrade, tanpa `selfdestruct`, tanpa saldo yang mengendap.** Tidak ada yang dapat dicuri dari Router di antara transaksi. 8. **Pool yang bermusuhan merugikan Anda dalam harga, lalu di-revert.** Pool itu tidak pernah mengirimkan di bawah lantai Anda. 9. **Setiap angka di sini dicetak di samping penyebutnya** — dan di samping cara angka itu dapat dimanipulasi. 10. **Jika setiap server yang kami jalankan lenyap malam ini, kontrak-kontraknya tetap akan memberi kuotasi, merutekan, dan menyelesaikan transaksi esok hari.** Segala sesuatu di bawah ini adalah buktinya, beserta baris kode yang menegakkan setiap klaim dan batas yang membatasinya. ## Abstrak BlazePhoenix-Dex adalah agregator likuiditas on-chain yang dibangun di atas satu klaim: kuotasi dan eksekusinya adalah komputasi yang sama. Rute diturunkan di dalam transaksi yang mengeksekusinya, dari state pool publik, oleh sebuah library tanpa state yang dapat dijalankan ulang oleh pembaca mana pun; angka yang mengikat saat penyelesaian (settlement) diturunkan ulang oleh dispatcher yang sama di dalam frame eksekusi. Tidak ada layanan perutean, tidak ada oracle harga, tidak ada keeper, dan tidak ada jalur upgrade. Makalah ini menspesifikasikan lima kontrak — Core, Hub, Solver, Router, Quoter — dan operator-operator Meta-Persamaan: Dispatcher Delapan Lipat Ω, Penurunan Deterministik 𝒟, lantai Iron-Law Φ, Medan Vitalitas Ψ, dan proyektor anti-penipuan Ξ. Di belakangnya terdapat satu disiplin, Desain Metrologis: ukur setiap koordinat yang dapat diukur, dan jadikan sisanya monoton sehingga input palsu hanya merugikan pemasoknya. Setiap jaminan dinyatakan beserta lokasi penegakannya dan batasnya. Perangkat verifikasi dicetak beserta penyebutnya: 1,609 uji yang dideklarasikan di 236 berkas, 268 dari 268 mutan terkurasi dimatikan, 14 dari 15 mutan yang diarahkan pada 43 invarian stateful terdeteksi, covering array berkekuatan 2 (63 baris, 258 pasangan) dan 3 (168 baris, 1,636 tripel), 14 + 5 relasi metamorfik, tiga build optimiser yang saling sepakat, dan studi 240 sampel tentang bagaimana sebuah kuotasi menua. Delapan belas inovasi bernama menopang desain ini, dari Meta-Persamaan hingga kekebalan karena habis dicoba; masing-masing dikatalogkan beserta matematikanya sebelum spesifikasi dimulai. Generasi yang aktif di Base, Ethereum, Optimism, dan Arbitrum adalah V1; makalah ini menspesifikasikan V2, yang telah diuji secara menyeluruh pada fork likuiditas aktif di setiap chain yang dilayaninya. ## Cara membaca makalah ini Setiap mekanisme mendapat satu kalimat sederhana sebelum mendapat kalimat yang presisi, sehingga makalah ini dapat dibaca pada dua kedalaman: kalimat-kalimat sederhana dan gambar-gambar memberikan arsitekturnya; kalimat-kalimat presisi, tabel-tabel, dan lampiran-lampiran memungkinkan Anda memeriksanya. Setiap jaminan adalah satu kalimat — klaimnya, lokasi yang menegakkannya, dan batas yang membatasinya. Enam contoh terhitung membawa aritmetikanya secara manual: kuotasi constant-product (§4), pembagian di antara dua pool (§10), lantai Iron-Law pada rute dua hop (§11), pengenal pool Uniswap V4 yang diturunkan dari kuncinya (§5), dua rezim biaya pada satu rute (§13), dan pembacaan sebuah penyelesaian (§11). Angka-angka dicetak di samping penyebut yang menjadi acuan pengukurannya, dan perintah yang mereproduksinya terdapat di Lampiran C. Repositori bersifat kanonis: apabila teks ini dan kode sumber berbeda, kode sumberlah yang berlaku. ## Inovasi-Inovasi BlazePhoenix-Dex bukanlah agregator dengan server yang lebih baik. Ia adalah agregator **tanpa server** — dan untuk mencapainya diperlukan serangkaian mekanisme yang sebelumnya tidak ada. Delapan belas di antaranya menopang desain ini. Masing-masing dicantumkan di sini beserta apa itu, matematika yang mendefinisikannya, mengapa hal itu penting bagi orang yang bertransaksi, dan bagian yang menspesifikasikannya secara lengkap. ### I-1 · Kuotasi ≡ Eksekusi **Apa.** Angka yang dikuotasikan kepada Anda dan angka yang mengikat transaksi Anda berasal dari satu evaluator — dispatcher Ω milik Core — yang dijalankan sekali untuk merencanakan dan sekali lagi di dalam frame eksekusi untuk menyelesaikan. Tidak ada model penetapan harga kedua di mana pun dalam sistem. **Matematika.** Untuk setiap leg $\ell$, perencana dan eksekutor mengevaluasi fungsi yang sama $\Omega(p_{\ell}, x_{\ell})$ pada state publik yang sama; lantai rute diturunkan ulang dari nilai di dalam frame tersebut (E15, E16), tidak pernah dibaca dari rute. **Mengapa penting.** Setiap kelas eksploit agregator yang hidup di celah antara "apa yang dikatakan server" dan "apa yang dilakukan chain" tidak memiliki tempat untuk hidup. Terukur: kuotasi tanpa pergeseran diselesaikan tepat sesuai prediksinya **64 kali dari 64**, pada mock dan pada Base yang aktif. (§3, §11, §12) ### I-2 · Solver on-chain, gratis untuk dipanggil **Apa.** `Solver.findBestRoutePlan(tokenIn, tokenOut, amountIn)` adalah fungsi `view`. Siapa pun mendapatkan rute terbaik yang trustless dengan `eth_call` gratis — tanpa kunci API, tanpa relayer, tanpa tanda tangan — dan `swapBestExactIn` menyelesaikan perhitungan dan penyelesaian secara atomik dalam satu transaksi. **Matematika.** Seluruh Solver adalah maksimisasi terkendala dari Meta-Persamaan (E1) atas ruang rute $\mathcal{R}_{\mathcal{D}}$, yang dieksekusi sebagai pipeline deterministik: turunkan → peringkatkan → uji (probe) → saring → alokasikan → gerbang → lantai. **Mengapa penting.** Kecerdasan perutean industri berjalan di server tertutup tanpa jumlah baris yang dapat diaudit. Milik kami adalah 29,183 byte bytecode publik yang dapat dijalankan ulang oleh siapa pun dengan hasil yang sama. (§2, §10, §11.1) ### I-3 · Meta-Persamaan **Apa.** Seluruh agregator, ditulis sebagai satu ekspresi. **Matematika.** $$R^{\star} = \arg\max_{R}\ \mathrm{net}(R)\cdot\prod_{\ell \in R}\hat{\Psi}(p_{\ell})\cdot\mathbf{1}[\mathrm{net}(R)\ge\Phi(R)]\cdot\Xi(R)$$ **Mengapa penting.** Bentuk perkalian adalah sebuah properti keamanan: satu faktor yang gagal — leg yang mengkuotasikan nol, pool tanpa kedudukan, rute di bawah lantainya, hook yang bermusuhan — membuat skor rute menjadi tepat nol. Tanpa penalti lunak, tanpa bobot yang dapat disetel, tanpa rute yang nyaris gagal lolos diam-diam. (§3) ### I-4 · Dispatcher Delapan Lipat Ω **Apa.** Enam jenis venue — Uniswap V2, V3, V4, Algebra, Solidly stable, dan Solidly volatile — dilebur menjadi empat keluarga matematis di balik satu tabel atribut dan satu dispatcher. **Matematika.** Constant product $y = \lfloor x(\mathrm{BPS}-f)\,r_{\mathrm{out}} / (r_{\mathrm{in}}\mathrm{BPS} + x(\mathrm{BPS}-f)) \rfloor$ (E2); likuiditas terkonsentrasi dalam Q64.96, $\sqrt{P}' = L\sqrt{P}/(L + x_{f}\sqrt{P}/Q_{96})$, $y = L(\sqrt{P}-\sqrt{P}')/Q_{96}$ (E3); setiap perkalian berbahaya difaktorkan melalui `mulDiv` 512-bit. **Mengapa penting.** Fragmentasi ternyata adalah masalah bahasa, bukan masalah matematika. Satu rumus teraudit per keluarga menentukan harga setiap venue di setiap chain; fork baru dari keluarga yang sudah dikenal hanyalah satu baris tabel, bukan kode baru. (§4) ### I-5 · Penurunan Deterministik 𝒟 **Apa.** Pool **dihitung**, bukan ditanyakan. Hub menurunkan setiap alamat kandidat dari factory, pasangan token, dan hash init-code, dan hanya menerima alamat yang memiliki bytecode runtime. **Matematika.** $\mathrm{pool} = \mathrm{addr}_{20}(\mathrm{keccak256}(\mathtt{0xff}\,\Vert\,\mathrm{origin}\,\Vert\,\mathrm{salt}\,\Vert\,\mathrm{initCodeHash}))$ (E8). **Mengapa penting.** Jawaban sebuah factory dapat dipalsukan; aritmetika tidak. Penemuan pool tidak memerlukan panggilan eksternal per kandidat dan bekerja secara identik di setiap chain EVM, dengan pool manager dan factory sebagai konfigurasi runtime, tidak pernah di-hard-code. (§7) ### I-6 · Uniswap V4, sepenuhnya di dalam frame **Apa.** Pool V4 tidak memiliki alamat dan tidak menjawab panggilan. BlazePhoenix menurunkan id-nya, **membuktikan** masing-masing aktif terhadap storage PoolManager, membaca harga dan likuiditas melalui `extsload`, menelusuri buku tick hingga enam belas rentang, menyelesaikan melalui singleton — termasuk ETH native — dan menyaring hook hanya dengan aritmetika. **Matematika.** Basis storage $\mathrm{slot} = \mathrm{keccak256}(\mathrm{abi.encode}(\mathrm{poolId}, 6))$ dengan $\sqrt{P}$ pada bit [0,160) dan biaya LP pada [208,232) (E4); gerbang hook $(\mathrm{uint160}(\mathrm{hook})\,\&\,\mathtt{0x3FFF})\,\&\,((1\ll3)\mid(1\ll2)) \ne 0 \Rightarrow$ tolak, tanpa panggilan (E18); gerbang biaya dinamis E19. **Mengapa penting.** Menurunkan, membuktikan, menentukan harga, menyaring, dan menyelesaikan V4 tanpa memercayai satu jawaban pun dari venue — integrasi V4 terdalam yang dapat dimiliki sebuah agregator, dan semuanya dapat diverifikasi on-chain. (§5) ### I-7 · Solver stable Solidly **Apa.** Solver yang eksak dan fail-closed untuk kurva stable kuartik yang digunakan oleh venue kelas Aerodrome dan Velodrome. **Matematika.** Invarian $k(x,y) = x^{3}y + xy^{3}$ (E5), diselesaikan dengan iterasi Newton terbatas dengan penyesuaian satu unit yang merugikan pengambil (taker) dan batas 64-langkah (E6), setelah normalisasi desimal ke 18 tempat (E7). **Mengapa penting.** Aliran stablecoin dan liquid-staking berkumpul pada kurva-kurva ini, yang menghasilkan output hampir sebesar seluruh input. Solver mengkuotasikannya secara eksak — dan bila suatu batas tidak dapat dibuktikan, ia mengembalikan nol alih-alih tebakan. (§6) ### I-8 · Monoslot **Apa.** Seluruh state perutean sebuah pool — aktivitas, kelas kedalaman, biaya, jenis, flag, kebaruan — dikemas ke dalam **satu word 256-bit**. **Matematika.** $s = a \,\vert\, f\!\ll\!8 \,\vert\, k\!\ll\!32 \,\vert\, r\!\ll\!40 \,\vert\, (c\wedge\mathtt{0xFFF})\!\ll\!48 \,\vert\, b\!\ll\!60 \,\vert\, \dots \,\vert\, B_{\mathrm{last}}\!\ll\!224$ (E9). **Mengapa penting.** Satu `SLOAD` memeringkat sebuah pool; satu `SSTORE` di atas satu `SLOAD` menjaganya tetap mutakhir. Dan word tersebut tidak berisi harga, sehingga memori registri secara struktural tidak mampu salah menentukan harga sebuah transaksi. (§8) ### I-9 · Registri Swa-Pulih dan Medan Vitalitas Ψ **Apa.** Protokol mempelajari likuiditas dengan memperdagangkannya. Enam belas slot per pasangan, skor kebugaran yang diperoleh dari swap nyata, peluruhan secara aritmetika, dan sebuah **bukti pasangan (pair-proof)**: sebuah pool membuktikan token mana yang diperdagangkannya sebelum disimpan. **Matematika.** $\Psi = V \cdot 2^{b} \cdot (1 + 0.25\,\mathbf{1}_{\mathrm{bridge}}) \cdot (1 + 0.05\,\mathbf{1}_{\mathrm{conc}})$ (E10); aktivitas berkurang setengah setiap 24,576 detik tanpa aktivitas, $V = \mathrm{swapCount} \gg \lfloor (t - t_{\mathrm{last}})/24{,}576 \rfloor$ (E11); kelas kedalaman $b = \min(15, \lfloor \log_{10}(d/10^{15}) \rfloor)$ (E12); pendatang baru menggeser yang terlemah hanya jika melampaui suatu margin, $2^{b(d_{\mathrm{new}})} > \Psi_{\mathrm{worst}} + \lfloor \Psi_{\mathrm{worst}}/4 \rfloor$ (E13). **Mengapa penting.** Tanpa keeper, tanpa cron, tanpa kurator yang memutuskan pool mana yang penting: registri memulihkan dirinya sendiri dari aliran yang memang sudah dikirim oleh pengguna. (§9) ### I-10 · Pembagian Berjangkar Modal **Apa.** Kualitas harga dan kedalaman pool diukur secara terpisah. Sebuah probe kecil mengukur kurs marjinal setiap pool; sebuah **pita kepercayaan** yang dijangkarkan pada modal membuang pencilan; pool yang lolos berbagi order sebanding dengan kedalaman terukurnya. **Matematika.** Pusat = median berbobot kedalaman — $r_{i}$ pertama yang memenuhi $\sum_{j \le i} d_{j} \ge \lceil \sum d / 2 \rceil$ — dengan pita $[0.95, 1.05]\times$ pusat (E25); pembagian hanya bertahan jika $\mathrm{out}_{\mathrm{split}} \ge \mathrm{out}_{\mathrm{single}}\cdot(1 + 25/10^{6})$ (E14). **Mengapa penting.** Untuk menggeser jangkar, penyerang harus menyetor lebih banyak daripada setengah likuiditas nyata pasangan tersebut — modal yang dipertaruhkan, bukan donasi gratis. Jaminan yang berlaku: **sebuah pembagian tidak pernah membayar lebih sedikit daripada pool tunggal terbaik.** Diukur terhadap grid menyeluruh di Base, rute Solver berada dalam 0.13 bps dari optimum. (§10) ### I-11 · Lantai Iron-Law Φ **Apa.** Output minimum yang diturunkan ulang **on-chain, saat eksekusi**, dari dampak harga terukur dan konsentrasi rute — independen dari apa pun yang diberikan pemanggil. **Matematika.** $\mathtt{floorBps} = \max(9{,}600 - \mathtt{legShv} - \min(\delta, 10^{4}) - \sigma_{\ln}/10^{14},\ 8{,}000)$ (E15), dengan pemangkasan konsentrasi $\mathtt{legShv} = \sum_{\mathrm{hops}} \lfloor 200\,((\sum a)^{2} - \sum a^{2})/\sum a^{2} \rfloor$ (E23); pengiriman harus melampaui $\mathtt{effMin} = \max(\mathtt{userMinOut},\ \mathtt{route.singleOutFloor},\ \lceil \mathtt{finalHopQuote}\cdot\mathtt{floorBps}/10^{4}\rceil)$ (E16). **Mengapa penting.** Data pemanggil hanya dapat memperketat perlindungan, tidak pernah melonggarkannya. Pada transaksi sebesar 1 % dari kedalaman, lantai membatasi sandwich pada sekitar 2.7 % dari transaksi dan **menolak** di atas itu — perjalanan pulang-pergi penyerang menjadi negatif setelah melewati batas tersebut. (§11.5, §14.3) ### I-12 · Pengukuran di setiap sambungan **Apa.** Router tidak pernah memercayai bahwa sebuah transfer telah terjadi; ia mengukurnya. Setiap penarikan, setiap kedatangan hop, dan setiap pengiriman adalah delta saldo yang nyata, dari instruksi pertama swap hingga dompet penerima. **Matematika.** Setiap hop diskalakan ulang terhadap kedatangan terukurnya; token fee-on-transfer pada leg constant-product dihargai berdasarkan selisih yang benar-benar dilihat pool, yaitu kuantitas persis yang akan diperiksa oleh invarian pool itu sendiri. **Mengapa penting.** Token yang memungut pajak, melakukan rebase, atau melaporkan secara keliru tidak dapat mendorong Router menjanjikan apa yang tidak dimilikinya — dan Router **tidak menyimpan apa pun saat diam** di antara transaksi (INV-1). (§11.2, §11.4) ### I-13 · Doktrin Satu Callback **Apa.** Satu `fallback` menjawab callback flash-accounting dari setiap venue berbentuk V3 — Uniswap V3, Algebra, Pancake V3, Sushi V3, fork Solidly terkonsentrasi — dengan konteks leg yang sedang berjalan disimpan dalam transient storage EIP-1153. **Matematika.** Token yang terutang dibaca dari tanda kedua delta; pembayaran dibatasi dengan tiga cara — hanya pool yang telah ditetapkan, hanya selama sebuah leg sedang berjalan, tidak pernah melebihi anggaran leg yang tercatat (INV-10). **Mengapa penting.** Satu titik masuk yang kecil dan dijaga tiga lapis menggantikan sekumpulan callback per-fork — lebih sedikit bytecode, lebih sedikit permukaan serangan, satu hal untuk diverifikasi. (§11.4) ### I-14 · Aturan Surplus dan kekebalan karena habis dicoba **Apa.** Biaya 0.28 %, dikompilasi ke dalam kode, dipungut satu kali pada koin jembatan pertama yang dipegang Router — dan **tidak ada komponen biaya yang tumbuh seiring selisih antara kuotasi dan pengiriman.** **Matematika.** $\mathrm{fee} = \lceil 28 \cdot \mathrm{base} / 10^{4} \rceil$, dibagi $t_{1} = \lfloor 3{,}000\cdot\mathrm{fee}/10^{4} \rfloor$, $t_{2} = \mathrm{fee} - t_{1}$ (E17); predikat rezim $\mathrm{feeHop} = \min\{h : \mathrm{isBridge}(\mathrm{hops}[h].\mathrm{tokenIn})\}$ (E26). Rute yang menghindari setiap jembatan membayar di setiap hop, sehingga tidak ada awalan debu (dust) yang dapat membawa kabur biaya tersebut. **Mengapa penting.** Segala sesuatu yang dikirimkan pool di atas kuotasi sampai kepada Anda secara penuh. Biaya tidak dapat dinaikkan terhadap seorang trader atau diturunkan untuk integrator yang diistimewakan — tidak ada yang memegang kunci itu. (§13) ### I-15 · Kurs byte–gas ρ* **Apa.** Empat pintu Router adalah model biaya afin yang dijadikan antarmuka: selesaikan perhitungan on-chain, atau bawa rute yang telah diselesaikan sebelumnya di dalam calldata — mana pun yang lebih murah di chain tersebut. **Matematika.** Bawa rute di dalam calldata jika dan hanya jika $p_{\mathrm{byte}} < \rho^{*}$, dengan $\rho^{*}$ terukur pada 66.9–105.5 gas per byte menurut bentuk rute (E22). **Mengapa penting.** Setiap chain memiliki harga untuk byte dan harga untuk komputasi. BlazePhoenix mengukur kurs di antara keduanya dan memberikan pintu yang lebih murah kepada trader. (§17.6) ### I-16 · Proyektor anti-penipuan Ξ **Apa.** Setiap pool yang hook V4-nya mendeklarasikan izin pengubah delta dikeluarkan dari himpunan kandidat **sebelum pemeringkatan**, tanpa hook tersebut pernah dipanggil. **Matematika.** $\Xi(R) \in \{0,1\}$ dalam Meta-Persamaan, dievaluasi melalui uji bit E18 pada alamat hook. **Mengapa penting.** Hook yang bermusuhan tidak pernah mendapat kesempatan untuk berbohong: ia tidak pernah ditanya. Tiga lapisan independen — bit alamat, allow-list yang dipatok pada codehash, dan Ξ — berdiri di antara trader dan venue yang berbahaya. (§5.5, §14.2) ### I-17 · Pintu Satu Arah **Apa.** Otoritas administratif berakhir secara tidak dapat dibatalkan, di dalam bytecode. `renounceControl` menulis sebuah flag yang tidak dapat di-reset oleh jalur kode mana pun; setelahnya, hanya tersisa tingkat kurator yang hanya dapat bertambah. **Mengapa penting.** "Kami tidak akan menyentuhnya" menjadi "kami tidak dapat menyentuhnya." Biaya, pembagian, dan lantai sejak awal memang tidak pernah dapat diatur (INV-4); setelah pintu tertutup, tidak ada hal lain yang dapat diatur pula. (§14.7) ### I-18 · Desain Metrologis dan penyebut yang dipublikasikan **Apa.** Disiplin di balik semua hal di atas — ukur setiap koordinat yang dapat diukur, jadikan sisanya monoton sehingga input palsu hanya merugikan pemasoknya — dan perangkat verifikasi yang melaporkan **setiap angka di samping penyebutnya**. **Matematika.** 1,609 uji yang dideklarasikan di 236 berkas; 268 dari 268 mutan terkurasi dimatikan, masing-masing dipasangkan dengan satu uji yang harus gagal; covering array berkekuatan 2 (258 dari 258 pasangan) dan 3 (1,636 dari 1,636 tripel) atas faktor-faktor rezim; 14 + 5 relasi metamorfik; tiga build optimiser yang sepakat bit demi bit; bukti simbolik dalam Halmos dan Certora Prover. **Mengapa penting.** Sebagian besar proyek memublikasikan jumlah uji. BlazePhoenix memublikasikan bagaimana buktinya dapat dimanipulasi dan terhadap apa ia mengukur — dan menghitungnya ulang pada setiap commit. (§2.3, §15) ### Papan skor | Properti terukur | Hasil | |---|---| | Kuotasi tanpa pergeseran yang diselesaikan tepat sesuai prediksinya (studi 240 sampel) | **64 / 64** | | Patologi venue × pintu yang diselesaikan atau ditolak dengan selector milik kami — tidak pernah dengan cara ketiga | **20 / 20** | | Mutan terkurasi yang dimatikan | **268 / 268** | | Aksi kontrol yang penolakannya diuji oleh kode yang eksak | **31 / 31** | | Kuantitas yang dihitung di dua tempat dan diikat bersama oleh uji bernama | **7 / 7** | | Pasangan nilai faktor rezim yang diuji melalui konstruksi | **258 / 258** | | Tripel nilai faktor rezim yang diuji melalui konstruksi | **1,636 / 1,636** | | Build optimiser matematika kuotasi yang saling sepakat (runs 1 / 300 / 20,000) | **3 / 3** | | Pratinjau → pengiriman di empat chain | **0–1 bps** | | Rute Solver vs. grid menyeluruh di Base | **dalam 0.13 bps** | | Sandwich terbesar yang diizinkan lantai pada transaksi sebesar 1 % dari kedalaman, sebelum menolak | **≈ 2.7 %** | | Peneliti keamanan eksternal yang diakui · Temuan kritis | **25 · 0** | ## Daftar isi - Inovasi-Inovasi (I-1–I-18) dan papan skor - §1 Masalahnya: kuotasi adalah janji yang dihitung oleh pihak lain - §2 Jawaban dan disiplinnya: desain berbasis invarian dan Desain Metrologis - §3 Meta-Persamaan dan anggaran dependensi - §4 Dispatcher Delapan Lipat Ω — jenis, keluarga, bentuk tertutup - §5 Uniswap V4 secara menyeluruh — singleton, bukti keberadaan, gerbang biaya, hook - §6 Solver Solidly - §7 Penurunan Deterministik 𝒟 - §8 Monoslot - §9 Registri Swa-Pulih dan Medan Vitalitas Ψ - §10 Perutean dan Alokator Pembagian - §11 Lapisan eksekusi dan lantai Iron-Law Φ - §12 Permukaan kuotasi, dan bagaimana sebuah kuotasi menua - §13 Kebijakan biaya: dua rezim dan Aturan Surplus - §14 Model keamanan - §15 Perangkat verifikasi, terukur - §16 Arsitektur dan ukuran - §17 Kinerja terukur - §18 DEX, dikupas hingga ke tulangnya - §19 Status deployment - §20 Token — BZPX - §21 Program riset dan rekam jejak keamanan - §22 Apa yang harus Anda percayai, dan apa yang tidak perlu - §23 Karya terkait - §24 Kesimpulan - §25 Staking V4: Desain - Lampiran A · Persamaan primitif (E1–E42) - Lampiran B · Invarian (INV-1–INV-31) - Lampiran C · Perintah reproduksi - Glosarium - Referensi --- ## §1 Masalahnya: kuotasi adalah janji yang dihitung oleh pihak lain Bayangkan menjual mobil di sebuah kota yang memiliki dua puluh dealer. Broker yang baik mendatangi kedua puluh dealer itu, menemukan harga terbaik, dan mungkin membagi penjualan ke dua di antaranya. Sebagian besar "broker" on-chain memeriksa harga pada basis data mereka sendiri — yang mungkin sudah usang — lalu menampilkan hasilnya kepada Anda. Anda tidak dapat memverifikasi bahwa mereka telah memeriksa kedua puluh dealer, atau bahwa mereka menunjukkan yang terbaik kepada Anda. Anda hanya dapat memverifikasi bahwa sejauh ini mereka bersikap jujur. Setiap agregator yang dokumentasinya kami baca — 1inch, CoW Swap, Velora (ParaSwap), KyberSwap, OpenOcean, Jupiter, dan UniswapX, sebagaimana didokumentasikan pada 2026-09-07 — bekerja dengan cara ini: sebuah layanan menghitung rute secara off-chain dan kontrak mengeksekusi rute yang diserahkan kepadanya. Kontrak tidak memilih; kontrak hanya memeriksa. Itu adalah rekayasa yang baik — itulah sebabnya sistem-sistem tersebut cepat dan murah — dan ia memiliki satu konsekuensi yang jarang dinyatakan secara terus terang: **klaim terkuat yang dapat dibuat oleh sistem semacam itu adalah bahwa operatornya jujur.** Kesenjangan ini biasanya bukan penipuan. Kesenjangan ini adalah pergeseran, yang berasal dari tiga sumber biasa. Kuotasi dihitung terhadap cadangan yang sudah bergerak sebelum transaksi masuk ke blok. Pencarian hanya selengkap yang dimungkinkan oleh anggaran operator. Dan setiap koreksi antara kuotasi dan pengisian — penyangga slippage, biaya (fee) di tengah jalan — diterapkan oleh kode yang tidak dibaca pengguna, pada angka yang tidak dapat direproduksi pengguna. Tidak satu pun dari hal itu memerlukan niat buruk. Semuanya tidak terlihat. ### §1.1 Fragmentasi itu nyata, dan lebih dangkal daripada kelihatannya Seorang trader yang menginginkan harga terbaik menghadapi sebuah paradoks. Likuiditasnya ada, tersebar di puluhan bursa terdesentralisasi, masing-masing dengan kontrak pool sendiri, kurva harga sendiri, skema alamat sendiri — tetapi tidak ada satu venue pun yang memegang semuanya. Harga dari eksekusi terbaik adalah biaya untuk berbicara dalam bahasa setiap bursa sekaligus, serta untuk memercayai setiap penerjemah di antara harga yang ditampilkan dan trade yang benar-benar terjadi. Jawaban para petahana mengintegrasikan venue satu per satu: satu konektor untuk Uniswap, satu lagi untuk fork Solidly, satu lagi untuk setiap varian likuiditas terkonsentrasi, masing-masing dengan kuotasi khusus, pencarian alamat khusus, dan eksekusi khusus. Permukaan integrasi tumbuh secara linear terhadap jumlah venue, dan setiap konektor merupakan tempat baru bagi cacat penetapan harga atau ketidakcocokan diam-diam antara angka yang dikuotasikan dan angka yang dieksekusi. Fragmentasi itu lebih dangkal daripada kelihatannya. Di balik keragaman permukaan, automated market maker yang memegang sebagian besar likuiditas on-chain diatur oleh sekumpulan kecil invarian. Pool constant-product mematuhi $x \cdot y = k$. Pool likuiditas terkonsentrasi melacak harga akar kuadrat dalam fixed point di atas likuiditas aktif yang konstan sepotong-sepotong. Keluarga Solidly mematuhi persamaan kuartik, $x^{3}y + xy^{3} = k$, pada pasangan stabilnya dan constant product pada pasangan volatilnya. Yang ada hanyalah segelintir bentuk, bukan enam puluh. Jika bentuknya sedikit, biaya agregasi tidak perlu tumbuh seiring jumlah venue; biaya itu cukup tumbuh seiring jumlah bentuk. Protokol yang mengimplementasikan setiap bentuk satu kali, dengan benar, dan mengarahkan setiap venue ke bentuk yang tepat meruntuhkan permukaan integrasi dari linear menjadi konstan. Menambahkan venue tidak lagi merupakan pekerjaan rekayasa, melainkan konfigurasi: tetapkan sebuah jenis (kind) dan sebuah mode penurunan alamat, maka matematika yang sudah ada akan menghargainya, router yang sudah ada akan menyelesaikannya, dan registri yang sudah ada akan mempelajarinya. **Klaim sentral desain ini:** setiap venue yang dilalui perutean BlazePhoenix adalah parametrisasi dari salah satu anggota sebuah keluarga kecil fungsi output — empat keluarga yang berfungsi dalam taksonomi enam jenis (§4) — yang disimpan satu kali, dalam satu pustaka tanpa state, dan tidak pernah didefinisikan ulang. Menambahkan venue berarti menetapkan sebuah jenis dan sebuah mode penurunan, bukan menulis kode penetapan harga yang baru. ### §1.2 Jalan keluar off-chain Arsitektur agregator yang lazim mengkuotasikan rute pada sekumpulan server, menjalankan lelang di antara solver off-chain, mengindeks likuiditas pool dengan bot keeper, dan mengirimkan hasilnya ke kontrak penyelesaian (settlement) on-chain yang tipis — sering kali di balik proxy yang dapat di-upgrade, yang kunci admin-nya dapat mengganti logikanya secara langsung. Sebuah layanan web menghasilkan harga, sebuah basis data menyimpan graf likuiditas, seorang operator istimewa dapat mengubah aturan, dan rantai menjadi sekadar venue penyelesaian bagi keputusan yang dibuat di tempat lain, oleh perangkat lunak yang tidak dapat dilihat dan tidak dapat diverifikasi oleh pengguna. Pengaturan itu justru memasukkan kembali kepercayaan yang hendak dihilangkan oleh teknologi ini. Kuotasi off-chain dapat berbeda dari pengisian on-chain, dan pengguna tidak dapat membuktikan bahwa seharusnya tidak demikian. Keeper dapat mati dan router menjadi buta. Admin proxy dapat, dalam satu transaksi, mengubah kontrak yang jujur menjadi kontrak yang bermusuhan. | Aspek | Agregator yang diselesaikan off-chain | BlazePhoenix-Dex | |---|---|---| | Kuotasi | Server off-chain atau lelang solver | Satu dispatcher on-chain, digunakan bersama oleh pratinjau dan oleh eksekusi di dalam frame | | Penemuan likuiditas | Bot keeper mengindeks dan mengirimkan daftar | Registri Swa-Pulih — likuiditas dipelajari dengan memperdagangkannya — ditambah penemuan deterministik | | Pemilihan rute | Pengoptimal off-chain proprietary | Solver on-chain, dapat direproduksi oleh siapa pun dari state publik | | Permukaan upgrade | Proxy yang dikendalikan admin | Core tanpa state; tanpa proxy, tanpa jalur upgrade, tanpa `selfdestruct` | | Kuasa istimewa atas dana | Sering ada | Router tidak menyimpan apa pun saat diam; tidak ada fungsi yang memindahkan pokok dana pengguna | | Konsistensi lintas rantai | Logika backend per rantai | Satu bytecode per rantai | | Asumsi kepercayaan | Kejujuran operator | Minimum milik pengguna sendiri, yang ditolak oleh kontrak jika bernilai nol | BlazePhoenix menolak kedua sisi tawar-menawar itu. Ia menolak permukaan integrasi linear dengan menunjukkan bahwa permukaan itu tidak linear, dan ia menolak jalan keluar off-chain dengan menyimpan seluruh keputusan — penemuan, kuotasi, penilaian, perutean, dan penyelesaian — di dalam kontrak yang dapat dibaca siapa pun dan yang menghasilkan jawaban yang sama di setiap rantai. Biayanya nyata: mengkuotasikan pool terkonsentrasi secara on-chain lebih mahal daripada membacanya dari basis data. Yang dibeli oleh biaya itu adalah hilangnya satu kelas kegagalan — divergensi diam-diam yang tidak dapat dibuktikan antara apa yang dijanjikan server dan apa yang diberikan rantai. Setiap keputusan desain berikutnya merupakan wujud dari pertukaran tersebut. ## §2 Jawabannya dan disiplinnya **Yang memilih adalah yang bertransaksi.** BlazePhoenix-Dex memiliki titik masuk yang menerima enam nilai — dua token, jumlah, minimum Anda, penerima, dan tenggat waktu — dan menentukan rute di dalam transaksi yang mengeksekusinya, dari cadangan pool yang merupakan state publik: venue mana, berapa banyak ke masing-masing, dan dalam urutan apa. Karena rute diturunkan dari state publik oleh kode publik, siapa pun dapat menurunkannya kembali. Karena angka yang mengikat pada saat penyelesaian diturunkan kembali oleh dispatcher yang sama, dalam frame yang sama, dari state langsung yang sama, kuotasi dan eksekusi bukanlah dua artefak yang harus direkonsiliasi; keduanya adalah satu komputasi, dan yang memisahkan pratinjau dari pengisian adalah waktu, bukan model kedua. Tiga titik masuk lainnya menerima rute yang telah dihitung sebelumnya dari calldata, bagi pemanggil yang menginginkan jalur yang lebih murah dan bersedia menyediakan jawabannya sendiri; mesin pengukuran, lantai, dan penyelesaian yang sama berlaku untuk keempat pintu (§11). Kami tidak mengklaim bahwa pendekatan off-chain itu salah, dan kami tidak mengklaim lebih murah. Kami mengklaim kelas jaminan yang berbeda — dapat diaudit alih-alih dijanjikan — bagi pengguna yang menginginkannya dan bersedia membayar gas untuk itu. Empat keputusan dalam desain ini, sejauh yang dapat kami pastikan, tidak lazim di bidang ini, dan masing-masing dinyatakan bersama batas yang menjaganya tetap jujur. - **Alamat diturunkan, bukan diambil.** Di mana pun deployment suatu keluarga venue dapat direproduksi, alamat pool dihitung dengan aritmetika CREATE2 — sebuah teorema yang dapat diperiksa ulang siapa pun dari tiga input publik — alih-alih dibaca dari storage factory; di mana aritmetika itu tidak sahih, protokol bertanya, dan pool yang ditanya membuktikan pasangannya sendiri sebelum didaftarkan (§7). - **State perutean sebuah pool adalah satu word.** Monoslot mengemas semua yang diperlukan untuk memeringkat sebuah venue ke dalam satu slot 256-bit dan dengan sengaja tidak memuat harga, sehingga memori registri dapat memengaruhi pool mana yang ditanya, tetapi secara struktural tidak mampu menghargai sebuah trade (§8–§9). - **Lantai diturunkan kembali dari trade yang benar-benar terjadi.** Router mengukur dampak yang terealisasi pada setiap leg dan konsentrasi yang terealisasi pada setiap hop di dalam frame eksekusi, lalu menghitung ulang lantainya dari pengukuran tersebut, sehingga field yang diberikan pemanggil dapat memperketat perlindungan dan tidak pernah melonggarkannya (§11). - **Penemuan bersifat buta-deployer di mana venue tidak memiliki alamat.** Untuk singleton Uniswap V4, pengenal pool diturunkan dari parameter publik lalu dibuktikan aktif terhadap storage milik manager itu sendiri — bukti yang tidak dapat ditulis oleh pihak lain (§5). Tidak satu pun dari keputusan ini menghilangkan residu yang ditanggung setiap agregator — state dapat bergerak antara penandatanganan dan inklusi — itulah sebabnya minimum yang Anda tetapkan sendiri bersifat wajib, dan final: setiap pintu menolak minimum nol dengan `RouterE(10)` sebelum token apa pun berpindah. ### §2.1 Desain berbasis invarian Di balik jawaban itu terdapat sebuah metode. Kami menyebutnya desain berbasis invarian: protokol dispesifikasikan bukan sebagai urutan operasi, melainkan sebagai sekumpulan properti yang harus berlaku di setiap state yang dapat dicapai, dengan kode yang diorganisasi sedemikian rupa sehingga properti-properti itu bersifat struktural — ditegakkan oleh bentuk kode, bukan oleh kewaspadaan pemrogram. Sebagian besar perangkat lunak ditulis secara imperatif, dan kebenarannya hanyalah harapan yang muncul dengan sendirinya. Untuk perangkat lunak biasa hal itu dapat diterima, karena kegagalan dapat dipulihkan. Di blockchain publik, tidak satu pun dari hal itu berlaku: kode tidak dapat diubah setelah di-deploy; kode menyimpan nilai secara langsung; kode dieksekusi dalam lingkungan yang bermusuhan di mana setiap celah diburu; dan satu kekeliruan aritmetika adalah kerugian yang tidak dapat dibatalkan, bukan sekadar crash. Invarian adalah properti yang benar terlepas dari bagaimana sistem mencapai state-nya. *Router tidak menyimpan dana di antara transaksi.* *Sebuah pasangan registri memuat paling banyak enam belas pool, dan eviksi mempertahankan enam belas yang paling layak.* *Penyelesaian yang tidak membayar biaya protokol tidak ada.* Tiga prinsip menempatkan pernyataan semacam itu di pusat: | Prinsip | Pernyataan | Di mana muncul | |---|---|---| | Hitung, jangan percaya | Di mana sebuah nilai dapat diturunkan atau dibuktikan, jangan pernah mengambil atau mengasumsikannya. | 𝒟 menghitung alamat pool; Router menurunkan kembali basis biaya dan lantai di dalam frame dari saldo yang diukur. | | Satu sumber kebenaran | Setiap primitif matematika didefinisikan satu kali dan diimpor; tidak pernah dinyatakan ulang. | Core memuat seluruh matematika penetapan harga, penurunan, lantai, dan penilaian; Hub, Solver, Router, dan Quoter mengimpornya dan tidak ada yang mendefinisikan ulang primitif. Sebuah register besaran bersama (§15) menilai setiap besaran yang memiliki dua produsen. | | Gagal tertutup | Ketika sebuah properti tidak dapat dijamin, hentikan alih-alih melanjutkan berdasarkan tebakan. | Solver tidak mengembalikan rute alih-alih rute rekaan (`SolverE(5)`); solver stabil mengembalikan nol alih-alih kuotasi yang tersaturasi (§6); penjaga koherensi registri melakukan revert terhadap venue yang secara struktural mustahil sebelum state apa pun ditulis (§9). | Prinsip keempat mengatur kustodi: **tidak ada jalur istimewa menuju dana.** Solver dan Quoter adalah kontrak jalur baca; Router adalah satu-satunya kontrak yang memindahkan uang, ia memindahkannya secara atomik di bawah batas milik pengguna sendiri, dan setiap kuasa administratif yang dapat mengalihkannya dapat dilepaskan secara permanen melalui Pintu Satu Arah (§14). ### §2.2 Mengapa disiplin ini cocok dengan medium ini Setiap properti lingkungan yang membuat kode imperatif berbahaya merupakan properti yang diubah menjadi keuntungan oleh kode berbasis invarian. Imutabilitas menghargai keterbuktian: kode yang telah di-deploy tidak dapat ditambal, sehingga nilai sebuah bukti di awal menjadi sangat tinggi. Komposabilitas menghargai satu sumber kebenaran: sebuah fungsi penetapan harga dapat dipanggil di dalam vault yang tidak pernah diantisipasi oleh pembuatnya, dan dengan satu Core setiap pemanggil mendapatkan jawaban yang sama. Sifat adversarial menghargai kegagalan tertutup: penyerang hanya memerlukan satu jalur yang tidak dipertimbangkan oleh pembuatnya, dan sistem yang berhenti ketika asumsinya runtuh menutup peluang mereka untuk berimprovisasi. Nilai yang dipertaruhkan menghargai keterbacaan: protokol yang dinyatakan sebagai lima operator bernama di atas satu inti matematika dapat diperiksa baris demi baris oleh orang-orang yang tidak menulisnya. Disiplin ini tidak gratis, dan pertukarannya disengaja: membuktikan batas overflow memakan waktu lebih lama daripada mengabaikannya dengan asumsi; merutekan setiap perkalian melalui operasi kali-bagi berpresisi penuh menghabiskan gas yang tidak akan dihabiskan oleh perkalian naif; menurunkan alamat memerlukan pekerjaan rekayasa yang dilewati oleh pengambilan alamat. Itu berarti biaya lebih besar sebelum deployment sebagai ganti atas hilangnya kegagalan yang tidak dapat dipulihkan setelahnya. ### §2.3 Desain Metrologis: satu morfisme, koordinat terukur, input monoton Desain berbasis invarian menyatakan apa yang harus selalu berlaku. Tiga aturan lebih lanjut menyatakan bagaimana kode yang menegakkannya *dibentuk*, dan bersama-sama aturan-aturan itu membentuk sebuah metode yang belum kami temukan namanya di tempat lain di bidang ini, sehingga makalah ini menamainya: **Desain Metrologis** — membangun kontrak sebagai sebuah *instrumen*. Tesisnya dalam satu baris: *kode yang percaya adalah permukaan serangan; kode yang mengukur adalah pertahanan.* **Satu morfisme, dievaluasi pada satu titik.** Agregator ini tidak memuat integrasi per venue; ia adalah evaluasi satu morfisme penetapan harga terparametrisasi pada satu titik dalam ruang (bentuk venue, rantai, model biaya). Jika dinyatakan sebagai percabangan, setengah lusin jenis venue aktif dengan konvensi biaya masing-masing berlipat ganda menjadi ratusan kombinasi berpasangan — bytecode yang multiplikatif, permukaan audit yang multiplikatif, pergeseran yang multiplikatif. Jika dinyatakan sebagai morfisme, cakupan yang sama hanyalah segelintir *bentuk state*, satu Core tanpa state, konvensi biaya yang dibawa dalam satuan aslinya, dan tabel registrasi — dan bytecode tumbuh secara *aditif*: venue baru adalah satu baris, bukan satu cabang. Aturan yang menjaga keruntuhan ini adalah `KIND → SHAPE`: sebuah keluarga venue adalah *data* — sebuah jenis yang ditetapkan ke bentuk yang sudah ada dan sebuah mode penurunan — tidak pernah jalur kode baru yang dapat dipilih oleh input adversarial. Core menyatakan bentuk-bentuk itu sebagai tabel bit (`THETA_ATTR`, §4), sehingga "apakah jenis ini membaca cadangan?" hanyalah sebuah shift dan sebuah AND, dan tidak ada cabang default yang dapat dilupakan siapa pun. Keruntuhan ini memiliki rem: tidak ada satu rumus universal. Dua bentuk tertutup dievaluasi secara eksak — constant product dan likuiditas terkonsentrasi — dan untuk setiap kurva yang replikasinya akan menjadi liabilitas, bytecode milik venue itu sendiri yang ditanya (§6). Morfisme ini meruntuhkan *keanggotaan*, tidak pernah *verifikasi*. **Koordinat diukur, tidak pernah dipercaya.** Kontrak tidak pernah bertindak berdasarkan nilai yang dimodelkan, nominal, atau diberikan pemanggil di mana pengukuran on-chain tersedia — dan tidak ada datum tanpa izin yang pernah memilih kode mana yang dijalankan. Data yang diberikan oleh pihak yang tidak dipercaya — sebuah rute, biaya yang dideklarasikan, kedalaman yang diklaim, sebuah id pool — adalah *koordinat*: tempat untuk mengarahkan instrumen, yang kemudian dibaca sendiri oleh kontrak, secara gagal tertutup. Setiap pertahanan penting dalam makalah ini merupakan wujudnya: saldo setelah penarikan yang diukur alih-alih jumlah nominal (§11), basis biaya yang diambil dari selisih saldo yang diukur alih-alih dari calldata (§13), pita kepercayaan yang berjangkar pada median berbobot kedalaman dari kedalaman yang diukur alih-alih pada saldo mentah yang dapat digelembungkan oleh donasi (§10), penjepit kapasitas yang dipotong terhadap kepemilikan yang diukur (§10), gerbang biaya V4 yang membaca state langsung alih-alih memercayai sebuah sentinel (§5), penemuan bukti-keberadaan yang membaca storage milik singleton itu sendiri (§5), dan pool yang ditanya yang membuktikan `token0`/`token1` miliknya sendiri sebelum penemuan mendaftarkannya (§7). Repositori memublikasikan klasifikasi setiap field yang dapat ditulis pemanggil berdasarkan aturan ini: 23 field, 14 dikonfirmasi terhadap sebuah observasi, 5 bersifat mengarahkan, 4 dideklarasikan beserta alasannya (§15). **Di mana pengukuran berakhir, monotonisitas dimulai.** Sebagian angka tidak dapat diukur maupun diturunkan kembali — lantai milik pemanggil, skala yang dideklarasikan pemanggil, minimum milik pemanggil sendiri. Untuk angka-angka ini, desain menerima angka tersebut dan membentuk fungsinya sedemikian rupa sehingga berbohong hanya dapat merugikan si pembohong: lantai yang diatestasi rute hanya dapat *menaikkan* lantai yang ditegakkan (§11); kuotasi yang diatestasi sebuah leg dinaikkan ke kuotasi terukur ketika ia tidak mencukupinya (§11); penskalaan yang dideklarasikan dibatasi oleh kedatangan yang diukur, sehingga melebih-lebihkannya tidak dapat merutekan dana yang tidak pernah ada; dan satu-satunya angka yang tidak dapat dipilih oleh protokol — minimum Anda — bersifat wajib. Input monoton tidak memerlukan kepercayaan, sehingga dapat dihitung secara off-chain, oleh siapa pun, secara gratis, dan dibawa di dalam calldata — begitulah protokol ini memindahkan pekerjaan ke off-chain *tanpa memindahkan kepercayaan ke off-chain*, dan itulah sebabnya Router dapat menawarkan satu pintu pemecahan (solving) dan tiga pintu calldata dengan jaminan yang sama. Desain Metrologis juga mengatur rekayasa di sekitar artefak itu, karena sebuah instrumen hanya sebaik kalibrasinya. Margin keamanan dihargai berdasarkan bahaya yang diukur: gerbang pembagian berada pada 25 ppm karena titik impas leg terukur sebesar 3 ppm (§10); potongan (haircut) perencanaan yang melebihi bahaya terukurnya hingga 27× telah dipensiunkan (§10). Perbandingan eksternal disertai batas galat metodenya atau tidak dicetak (§17). Dan perangkat pengukurnya sendiri pun diukur: setiap instrumen jaminan dikalibrasi terhadap cacat yang sudah diketahui melalui jalur lain sebelum angkanya dicetak (§15). Itulah seluruh teorinya; sisa dokumen ini adalah praktiknya. ## §3 Meta-Persamaan dan anggaran dependensi Seluruh agregator dapat dibaca sebagai maksimisasi dari satu ekspresi. Diberikan token input $t_{\mathrm{in}}$, token output $t_{\mathrm{out}}$, dan jumlah $x$, Solver menelusuri rute-rute yang dapat diterima untuk menemukan rute yang memaksimalkan nilai bersih yang diterima, dengan syarat lantai kelayakan dan gerbang anti-penipuan: $$ R^{\star} \;=\; \mathrm{arg\,max}_{\;R \,\in\, \mathcal{R}_{\mathcal{D}}(t_{\mathrm{in}},\, t_{\mathrm{out}},\, x)} \;\; \mathrm{net}(R)\cdot\prod_{\ell\in R}\hat{\Psi}(p_{\ell})\cdot \mathbf{1}[\,\mathrm{net}(R) \ge \Phi(R)\,]\cdot \Xi(R) $$ ^e1 $$ \mathrm{net}(R) \;=\; \sum_{\ell\in R}\Omega(p_{\ell},\, x_{\ell})\;-\;f_{\mathrm{proto}} $$ Di sini $\mathcal{R}_{\mathcal{D}}$ adalah ruang rute atas pool yang ditemukan oleh Penurunan Deterministik 𝒟 dan registri; $\Omega(p_{\ell}, x_{\ell})$ adalah output dispatcher untuk leg $\ell$ yang mendorong $x_{\ell}$ melalui pool $p_{\ell}$; $f_{\mathrm{proto}}$ adalah biaya protokol; $\hat{\Psi}(p_{\ell})$ adalah vitalitas ternormalisasi leg tersebut; $\Phi(R)$ adalah lantai Iron-Law untuk dampak dan konsentrasi terukur rute tersebut; dan $\Xi(R) \in \{0, 1\}$ adalah proyektor anti-penipuan. | Operator | Nama | Peran dalam persamaan | Bagian | |---|---|---|---| | Ω | Dispatcher Delapan Lipat | Menghargai setiap leg — satu cabang per jenis pool — dan melaporkan kedalaman berdenominasi token untuk alokator pembagian | §4 | | 𝒟 | Penurunan Deterministik | Menemukan pool yang digunakan rute, melalui alamat yang dihitung di mana keluarganya memungkinkan, melalui id pool yang dibuktikan untuk singleton V4 | §5, §7 | | Φ | Lantai Iron-Law | Memproyeksikan rute ke himpunan yang layak: lantai di bawah output bersih, diturunkan kembali di dalam frame eksekusi | §11 | | Ψ | Medan Vitalitas | Memberi bobot pada setiap pool berdasarkan kualitas yang diperolehnya, dibaca dari state on-chain yang dikemas | §9 | | Ξ | proyektor anti-penipuan | Memberi nilai tepat nol pada setiap rute yang tidak aman untuk ditampilkan | §5, §14 | Faktorisasi ini disengaja. Ω menjawab *berapa banyak yang dikembalikan sebuah pool*; Ψ menjawab *seberapa besar pool itu dapat dipercaya*; Φ menjawab *apakah rute dapat diterima*; 𝒟 menjawab *di mana pool itu berada*; Ξ menjawab *apakah rute aman untuk ditampilkan*. Bentuk perkalian berarti satu leg yang gagal meruntuhkan skor rute — leg yang mengkuotasikan nol, atau pool tanpa reputasi, membuat hasil perkalian menjadi nol alih-alih sekadar mendiskonnya — dan indikatornya secara tegas membuat nol setiap rute yang output bersihnya jatuh di bawah lantai. Tanpa penalti lunak, tanpa bobot yang dapat disetel, tanpa rute nyaris-lolos yang menyelinap masuk.  Secara on-chain, Solver mewujudkan persamaan itu sebagai sebuah pipeline (`findBestRoutePlan`): kandidat per pasangan dikumpulkan oleh registri dan, ketika registri tidak segar, oleh 𝒟; diperingkat dan dipangkas oleh Ψ hingga `MAX_CANDIDATES = 8`; diuji dan dikuotasikan oleh Ω; disaring oleh pita kepercayaan; dialokasikan ke berbagai leg; dan rute yang telah tersusun membawa lantai yang diatestasi Φ. Router kemudian mengevaluasi ulang Ω dan Φ pada jumlah yang benar-benar tiba. Klaim yang dibuat oleh persamaan ini — klaim yang dapat digunakan auditor untuk menguji kode — adalah bahwa tidak ada langkah dalam pipeline itu yang merujuk pada apa pun di luar kelima operator tersebut. Jika suatu besaran bukan argumen bagi salah satu dari kelimanya, besaran itu tidak dapat memengaruhi rute: tidak ada pemasaran venue, tidak ada reputasi off-chain, tidak ada preferensi operator. ### §3.1 Anggaran dependensi Alih-alih kata sifat — *terdesentralisasi*, *tanpa server*, *tanpa kepercayaan* sudah tidak lagi membawa informasi — inilah daftar yang dapat diperiksa: segala sesuatu yang harus ada, dan terus berfungsi, agar satu trade dapat diselesaikan. | Dependensi | Agregator tipikal yang diselesaikan off-chain | BlazePhoenix-Dex | |---|---|---| | Layanan yang menghitung rute | Diperlukan | Tidak digunakan — Solver adalah fungsi `view` yang dilayani node mana pun | | Oracle atau feed harga | Bervariasi | Tidak ada — tidak ada panggilan feed di kelima kontrak | | Jaringan solver atau lelang | Umum | Tidak ada | | Keeper, cron, atau relayer | Bervariasi | Tidak ada — vitalitas meluruh secara aritmetis saat dibaca berikutnya; registri belajar dari trading biasa | | Proxy yang dapat di-upgrade | Umum | Tidak ada — tanpa proxy, tanpa `selfdestruct`, tanpa initialiser; satu-satunya `delegatecall` adalah milik compiler sendiri ke pustaka Core publik, yang ditetapkan pada saat linking | | Antarmuka yang di-hosting | Dalam praktiknya ya | Hanya kemudahan | Baris terakhir adalah tempat sebagian besar anggaran gagal secara diam-diam. Antarmuka yang di-hosting adalah kemudahan, bukan dependensi: `swapBestExactIn` menerima enam nilai yang dapat disusun seseorang secara manual, dan seorang integrator, sebuah skrip, atau front end milik pesaing dapat memanggilnya tanpa hubungan apa pun dengan kami. Jika setiap server yang dioperasikan proyek ini lenyap malam ini, kontrak-kontraknya akan tetap mengkuotasikan, merutekan, dan menyelesaikan besok persis seperti hari ini. Harga dari properti itu adalah bahwa pemanggil membayar pencarian dengan gas; anggaran di atas adalah daftar hal-hal yang digantikan oleh gas tersebut. Imutabilitas juga memotong ke arah sebaliknya. Cacat tidak dapat ditambal — harga dari kontrak yang Anda audit satu kali — itulah sebabnya cacat diungkapkan dan diberi bounty sebagai gantinya (§21). ### §3.2 Tiga batas Anggaran ini memiliki tiga batas, yang dinyatakan di samping klaim yang dibatasinya. Antarmukanya di-hosting, seperti milik semua pihak, dan front end yang disusupi adalah eksposur tunggal terbesar dalam model ancaman: kontrak menghormati minimum bukan-nol apa pun yang diserahkan kepadanya, sehingga minimum yang Anda tetapkan adalah satu-satunya batas yang tidak dapat diambil dari Anda oleh antarmuka mana pun. Penemuan venue membaca state yang ditulis oleh transaksi sebelumnya — publik dan tanpa izin, tetapi tidak diciptakan pada saat trade. Dan kuasa administratif ada sampai dilepaskan melalui Pintu Satu Arah; setelah pelepasan, tingkat kendali — jeda, peran, treasury, pengkabelan, penghapusan — hilang untuk selamanya, dan hanya tingkat kurator yang hanya-bertambah yang tersisa (§14). Core tanpa state, operasi tanpa server, tata kelola yang hanya-bertambah: tabel itulah klaimnya; kata-kata hanyalah bayangannya. ## §4 Dispatcher Delapan Lipat Ω *Sederhana:* satu fungsi yang tahu cara menghargai setiap jenis pool. *Presisi:* `universalQuote(QuoteCtx, amountIn)` di Core adalah dispatcher kuotasi untuk Solver dan untuk pratinjau Quoter; fungsi ini mengembalikan output yang diharapkan dan kedalaman berdenominasi token untuk alokator pembagian, dan pool yang tidak dapat dihargainya mengembalikan nol dan dibuang sebelum apa pun dikirim. Router mengevaluasi primitif Core yang sama per leg di dalam frame-nya sendiri (`_hopScaleImpactAndQuote`), sebuah saudara yang dipertahankan demi gas dan kedalaman stack, dan Exact Pass milik Quoter mengajukan pertanyaan yang berbeda lagi (§12); ketiganya dicatat bersama dalam register besaran bersama di repositori, dan kesesuaiannya dikunci oleh tes bernama alih-alih diasumsikan (§15). Nama internal ini dipertahankan dari enumerasi delapan jenis yang dibawa dispatcher saat pertama kali dirilis; enumerasi itu sejak itu bertambah dengan anggota kesembilan dan melepaskan tiga anggota melalui pemangkasan yang disengaja. Penomorannya mempertahankan celah-celahnya: Monoslot yang tercatat kemarin harus didekode secara identik untuk selamanya. ### §4.1 Enam jenis, empat keluarga, satu tabel atribut | Jenis | Konstanta | Keluarga | Cabang penetapan harga | Atribut Θ | Tangga gas (Solver) | |---|---|---|---|---|---| | 0 | `KIND_V2` | Constant product (Uniswap V2, Sushi, fork) | bentuk tertutup `outV2` atas `getReserves` | cadangan · pasangan-dapat-diverifikasi | 90,000 | | 1 | `KIND_V3` | Likuiditas terkonsentrasi (Uniswap V3 dan fork berbentuk V3) | bentuk tertutup `outV3` atas `slot0` | terkonsentrasi-di-pool · pasangan-dapat-diverifikasi | 110,000 | | 4 | `KIND_V4` | Singleton Uniswap V4 | bentuk tertutup `outV3` atas `extsload` | terkonsentrasi-di-singleton | 180,000 | | 5 | `KIND_SOLIDLY` | Solidly (Aerodrome, Velodrome, fork), stabil dan volatil | tanya pool `getAmountOut`; kurva replikasi sebagai cadangan | cadangan · pasangan-dapat-diverifikasi | 90,000 | | 6 | `KIND_ALGEBRA` | Algebra (kelas Camelot), biaya dinamis | bentuk tertutup `outV3` atas `globalState` | terkonsentrasi-di-pool · pasangan-dapat-diverifikasi | 110,000 | | 8 | `KIND_V4_NATIVE` | Pool V4 yang memegang mata uang native rantai | cabang yang sama dengan jenis 4 | terkonsentrasi-di-singleton | 215,000 | Enam jenis, empat keluarga yang berfungsi: constant product {0}, terkonsentrasi {1, 6}, Solidly {5}, dan singleton V4 {4, 8}. Kolom atribut bukanlah prosa: kolom itu adalah tabel bit `THETA_ATTR = 0x040A9400A9` di Core, empat bit per jenis — *membaca cadangan*, *terkonsentrasi di alamat pool*, *terkonsentrasi di singleton*, *mengekspos `token0()`/`token1()`* — sehingga setiap pertanyaan keanggotaan dalam kelima kontrak ("apakah jenis ini membaca cadangan?") adalah satu shift dan satu AND (`kindHas`, `kindHasAny`), dan jenis tanpa bit gagal tertutup tanpa cabang default yang dapat dilupakan siapa pun. Kolom gas adalah tabel kedua, `THETA_GAS`, yang hanya dibaca oleh `estGas` milik Solver, dalam satuan 5,000 gas per leg. **Jenis 2, 3, dan 7 tidak ada karena pemangkasan yang disengaja.** Keluarga berbobot (3) tidak pernah menghasilkan kuotasi yang dapat dirutekan. Dua keluarga Curve (2, 7) berfungsi dan tetap dihapus, dalam pengerasan batas kepercayaan pada Agustus 2026, karena mendukungnya memerlukan satu-satunya `approve` token milik Router, satu-satunya angka kedalaman yang diatestasi oleh pemanggil alih-alih diukur dari pool, dan satu-satunya pengecualian dalam bukti keaslian pasangan milik Hub — tiga permukaan serangan, masing-masing yang terakhir dari kelasnya. Nomor yang dipensiunkan tidak pernah ditetapkan ulang: `decodeKind` membaca jenis dari bit Monoslot, sehingga menggunakan ulang 2 akan menafsirkan ulang setiap pool yang pernah tercatat di bawahnya, dan sebuah penjaga CI menggagalkan build jika simbol yang telah dipangkas muncul kembali. **Jenis mata uang native (8) ada karena satu invarian runtuh di sana dan tidak di tempat lain.** Asumsi kerja Router — setiap aset adalah ERC-20 dengan `balanceOf` — gagal tepat ketika mata uang sebuah pool V4 adalah aset native rantai, dan mengodekan pengecualian itu sebagai sebuah *tipe* membuatnya terlihat dalam catatan pool, dibawa dalam rencana rute, dan dapat di-grep oleh auditor. Penetapan harganya tidak memerlukan cabang: pengenal pool diturunkan dari dua mata uang yang telah diurutkan, dan `address(0)` secara konstruksi berada di urutan pertama. Jenis ini membuktikan kelayakannya secara empiris: diukur pada 2026-08-13 di seluruh rantai yang dilayani, 62.9 % likuiditas berdenominasi ETH di dalam V4 berada di pool native (Arbitrum 99.6 %, Optimism 95.0 %, Base 48.9 %). ### §4.2 Bentuk-bentuk tertutup **Constant product.** Cadangan memenuhi $x \cdot y = k$ dan biaya $f$ dalam basis poin diambil dari input. Core menghitung $$ y \;=\; \mathrm{outV2}(x,\, r_{\mathrm{in}},\, r_{\mathrm{out}},\, f) \;=\; \left\lfloor \frac{x\,(\mathrm{BPS}-f)\; r_{\mathrm{out}}}{\,r_{\mathrm{in}}\cdot \mathrm{BPS} \;+\; x\,(\mathrm{BPS}-f)\,} \right\rfloor $$ ^e2 tanpa pembagian hingga langkah terakhir, sehingga satu-satunya pembulatan adalah pembulatan ke bawah dari hasil bagi terakhir, dan biaya sebesar `BPS` atau lebih membuat pool tidak dapat dikuotasikan (mengembalikan nol). Biaya yang masuk ke dalam rumus ini adalah `effV2Fee(declared)`: biaya yang dideklarasikan sebesar nol atau di atas `V2_FEE_CEILING_BPS = 100` diganti dengan nilai kanonik 30 bps, sehingga sebuah registrasi tidak dapat mengempiskan kuotasinya sendiri — dan bersama itu lantai yang dijangkarkan oleh kuotasi tersebut — dengan mendeklarasikan biaya yang tidak masuk akal; aturan yang sama dicerminkan pada jalur eksekusi, sehingga kedua sisi trade menghargai dengan satu angka. **Contoh terhitung 1 — kuotasi constant-product.** Sebuah pool memegang $r_{\mathrm{in}} = 1{,}000{,}000$ USDC dan $r_{\mathrm{out}} = 500$ WETH dengan biaya kanonik 30 bps; seorang trader menjual $x = 10{,}000$ USDC. Dalam satuan milik pool itu sendiri (USDC memiliki 6 desimal, WETH 18) $x = 10^{10}$, $r_{\mathrm{in}} = 10^{12}$, $r_{\mathrm{out}} = 5 \times 10^{20}$: 1. Input setelah penyesuaian biaya: $x(\mathrm{BPS}-f) = 10^{10} \times 9{,}970 = 9.97 \times 10^{13}$. 2. Pembilang: $9.97 \times 10^{13} \times 5 \times 10^{20} = 4.985 \times 10^{34}$. 3. Penyebut: $10^{12} \times 10^{4} + 9.97 \times 10^{13} = 1.00997 \times 10^{16}$. 4. Output: $\lfloor 4.985 \times 10^{34} / 1.00997 \times 10^{16} \rfloor = 4.935790 \times 10^{18}$ wei, yaitu **4.935790 WETH** (hingga enam desimal; kontrak membulatkan hasil bagi terakhir ke bawah hingga satuan wei). Pada harga spot 0.0005 WETH per USDC, 10,000 USDC yang sama akan menghasilkan 5 WETH; pengisiannya 1.28 % di bawah spot, dengan 0.30 % di antaranya merupakan biaya. Ukuran dampak berbasis cadangan milik Core untuk leg ini adalah $\mathrm{impactV2Bps} = \lceil x \cdot \mathrm{BPS} / (r_{\mathrm{in}} + x) \rceil = \lceil 10^{14} / 1.01 \times 10^{12} \rceil = 100$ bps — angka yang dikonsumsi oleh lantai Iron-Law di §11. **Likuiditas terkonsentrasi.** Pool berbentuk V3 tidak menyimpan cadangan; pool tersebut menyimpan harga akar kuadrat $\sqrt{P}$ dalam fixed point Q64.96 dan likuiditas aktif $L$. Di dalam satu tick, untuk token0 → token1 dengan biaya $f$ dalam bagian per juta dan $x_{f} = \lfloor x\,(10^{6} - f)/10^{6} \rfloor$: $$ \sqrt{P}\,' \;=\; \frac{L\,\sqrt{P}}{\,L \;+\; x_{f}\,\sqrt{P}/Q_{96}\,}, \qquad y \;=\; \frac{L\left(\sqrt{P}-\sqrt{P}\,'\right)}{Q_{96}} $$ ^e3 dan untuk token1 → token0, $\sqrt{P}\,' = \sqrt{P} + x_{f} Q_{96}/L$ dan $y = L\,Q_{96}(\sqrt{P}\,' - \sqrt{P})/(\sqrt{P}\,\sqrt{P}\,')$, dengan pembagian yang dipecah menjadi dua tahap. Komputasi naif akan mengalami overflow: $L \cdot \sqrt{P}$ dapat mencapai $2^{288}$. Core tidak pernah membentuknya — setiap perkalian difaktorkan melalui `mulDiv` berpresisi penuh (nilai antara 512-bit, hasil 256-bit), sehingga setiap tahap terbukti muat, dan langkah yang akan menggerakkan harga ke arah yang salah atau ke nol mengembalikan nol alih-alih sebuah angka. Pool Algebra (jenis 6) berbagi cabang yang sama dan berbeda dalam satu hal yang ditangani oleh cabang tersebut: state dan biaya dinamisnya berada di `globalState`, yang dibaca satu kali (§5.4). Rumus ini eksak di dalam satu tick dan tidak eksak melintasi batas tick, di mana bentuk satu-tick memberikan estimasi berlebih. Dispatcher tidak mereplikasi aritmetika lintas tick: mereplikasi matematika internal sebuah venue merupakan liabilitas struktural, karena setiap divergensi antara salinan dan aslinya muncul sebagai kuotasi yang salah harga. Dua hal menggantikannya. Core membawa penjepit batas (`sqrtBoundary`) yang memotong langkah di tepi rentang saat ini — eksak untuk bagian yang muat di dalam rentang dan secara ketat di bawah untuk sisanya, tidak pernah di atas — dan desain menempatkannya di sisi *janji*, bukan pada pemeringkatan, karena menjepit hanya keluarga yang memiliki tick akan membandingkan venue di bawah dua konvensi. Dalam tree yang diukur oleh makalah ini, penjepit tersebut sudah didefinisikan tetapi belum dihubungkan: `Router._v4LegQuote` dan lengan pemeringkatan Core sama-sama memanggil bentuk satu-tick tanpa penjepit, sehingga leg terkonsentrasi yang keluar dari rentangnya hanya dibatasi oleh lantai per leg pada §11.3 dan anggaran hop, dengan lantai Iron-Law sebagai penyangga terakhir. Dan pada saat eksekusi, lantai Iron-Law ditegakkan terhadap kuotasi yang diturunkan kembali oleh Router di dalam frame dari jumlah yang benar-benar tiba, sehingga estimasi berlebih di batas tick merugikan akurasi pemeringkatan sebuah rute, tidak pernah merugikan lantai pengguna. Exact Pass milik Quoter (§12) memberi integrator angka milik pool itu sendiri ketika ia menginginkannya. **Kedalaman.** Setiap cabang juga mengembalikan kedalaman dalam satuan token — sisi cadangan yang lebih pendek untuk keluarga cadangan (`shortSide18`), dan untuk keluarga terkonsentrasi cadangan virtual $L/\sqrt{P}$ atau $L\sqrt{P}$ yang diwakili $L$ pada harga saat ini (`depthFromL18`), sehingga pool V3 dan pool V2 dengan kedalaman yang sama dibandingkan setara dalam alokator alih-alih berbeda dengan faktor $\sqrt{P}$. ### §4.3 Dua satuan biaya, dibawa secara asli Venue constant-product dan Solidly mengkuotasikan biaya dalam basis poin; venue terkonsentrasi dalam bagian per juta. Dispatcher membawa masing-masing dalam satuan aslinya dan tidak pernah mengonversi silang, yang menghilangkan satu kelas kegagalan pembulatan dengan harga dua konstanta alih-alih satu. Dua keluarga venue baru mengetahui biayanya pada saat eksekusi — pool biaya dinamis V4 dan Algebra — dan keduanya ditangani dengan mengukur biaya dari pembacaan state yang sama yang menyediakan harga (§5.4). ### §4.4 Satu dispatcher, dua permukaan | Jenis | Pratinjau Quoter | Di dalam frame (rencana Solver; penurunan kembali oleh Router) | |---|---|---| | V2 (0) | bentuk tertutup `outV2` | bentuk tertutup `outV2` | | V3 / Algebra (1, 6) | bentuk tertutup `outV3` atas `slot0` / `globalState`; biaya langsung Algebra diukur dari pembacaan yang sama | sama | | Solidly (5) | tanya pool; kurva replikasi × 9,800 / 10,000 sebagai cadangan | sama | | V4 / V4-native (4, 8) | bentuk tertutup `outV3` melalui `extsload`, gerbang biaya gagal-tertutup (E19) | sama | Dengan demikian, yang memisahkan pratinjau dari pengisian adalah waktu: state yang bergerak antara blok pratinjau dan frame eksekusi. §12 mengukur tepat celah tersebut pada 240 sampel. ## §5 Uniswap V4 dari ujung ke ujung Uniswap V4 bukanlah kontrak pool baru; ia adalah bentuk venue yang baru, dan ia membatalkan empat asumsi yang menjadi dasar setiap router yang dibangun antara 2020 dan 2024. Pool tidak memiliki alamat — pool adalah entri dalam storage satu singleton, dengan kunci berupa sebuah hash. Kode arbitrer berjalan di dalam swap — sebuah hook dieksekusi pada titik-titik tertentu dari penyelesaian (settlement) yang sedang dilakukan router. Biaya (fee) tidak harus konstan. Dan pool dapat memegang mata uang native milik chain, yang tidak memiliki `balanceOf`. Bagian ini menjawab keempatnya secara struktural, sehingga sebuah leg V4 — bagi Solver, bagi lantai, dan bagi trader — tidak dapat dibedakan dari leg lainnya. ### §5.1 Menemukan pool yang tidak memiliki alamat: turunkan, lalu buktikan Penurunan Deterministik 𝒟 menghitung alamat (§7), tetapi pool V4 tidak memiliki alamat untuk dihitung. Yang dimilikinya adalah sebuah identifier — hash keccak dari `PoolKey`-nya — sehingga mode 9 pada tabel penurunan menurunkan *poolId* alih-alih alamat, lalu melakukan sesuatu yang tidak dapat dilakukan oleh penurunan alamat mana pun: ia membuktikan bahwa pool tersebut ada, dengan membaca storage milik PoolManager sendiri untuk id tersebut dan mensyaratkan harga akar kuadrat yang bukan nol serta likuiditas yang bukan nol. Tidak ada yang dapat memalsukan bukti tersebut, karena tidak ada pihak selain manager yang menulis storage itu. Id rekaan akan menghasilkan nilai nol dan dibuang. **Contoh terhitung 4 — identifier pool V4 dari kuncinya.** Id kanonisnya adalah $\mathrm{poolId} = \mathrm{keccak256}(\mathrm{abi.encode}(c_{0}, c_{1}, \mathrm{fee}, \mathrm{tickSpacing}, \mathrm{hooks}))$ (`computeV4PoolId`), lima word 32-byte. Ambil pool ETH native / USDC di Base pada tier 0.05 %: $c_{0} = \mathtt{0x0000…0000}$ (mata uang native diurutkan pertama), $c_{1} = \mathtt{0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913}$ (USDC), fee $= 500$, tickSpacing $= 10$, hooks $= \mathtt{0x0}$. 1. `abi.encode` menyusun 160 byte: kedua mata uang masing-masing di-left-pad hingga 32 byte, lalu `500`, lalu `10` (sebuah `int24`, diperluas tandanya hingga 32 byte), lalu hook nol. 2. Hasilnya, $\mathrm{poolId} = \mathtt{0x96d4b53a38337a5733179751781178a2613306063c511b78cd02684739288c0a}$. 3. Field `pool` di registri untuk baris V4 adalah 160 bit terendah dari id tersebut, $\mathtt{0x781178a2613306063c511b78cd02684739288c0a}$ — sebuah alamat tanpa kode, itulah sebabnya baris V4 tidak pernah ditanyai `token0()`, tidak pernah dibaca saldonya, dan sebagai gantinya membuktikan diri melalui penurunan ulang (§9). 4. Basis storage pool tersebut adalah $\mathrm{keccak256}(\mathrm{abi.encode}(\mathrm{poolId}, 6)) = \mathtt{0x13a3a697…73b2893d}$: slot 6 milik manager adalah mapping `pools`. Core membaca word 0 pada slot tersebut dan word 3 pada $\mathrm{base} + 3$ (`v4SqrtAndLiq`, selector `extsload(bytes32)` = `0x1e2eaeaf`). 5. Word 0 mengemas $\sqrt{P}$ pada bit [0, 160), tick pada [160, 184), biaya protokol pada [184, 208), dan biaya LP pada [208, 232); word 3 membawa likuiditas aktif pada 128 bit terendahnya. Jika $\sqrt{P}$ atau $L$ bernilai nol, pool tersebut tidak ada bagi protokol ini. Saudara wrapped dari pasangan yang sama — $c_{0} = \mathtt{0x4200…0006}$ (WETH), tier yang sama — memiliki id $\mathtt{0x90333bb0…ebd943a0}$: pool yang berbeda dengan kedalaman yang berbeda, itulah sebabnya pemindaian memeriksa kedua kunci dan memeriksa kunci native terlebih dahulu (lihat di bawah). Tata letak pada langkah 5 tidak diambil dari dokumentasi: pool yang sama, jika dibaca melalui tata letak ini dan melalui kontrak kanonis `StateView`, mengembalikan angka yang sama pada fork mainnet, dan identitas itulah yang dikutip oleh komentar di Core. **Tangga biaya.** Pemindaian yang menghasilkan id kandidat berbentuk tangga, dimulai dari anak tangga termurah, karena penyisiran naif atas setiap kombinasi fee dan spacing akan menimbulkan tagihan gas yang tidak dapat diterima pada jalur penyelesaian solusi: | Anak tangga | Apa yang dicobanya | Biaya ketika berhasil | |---|---|---| | 1 | Pola tier yang sudah dipelajari untuk pasangan token ini | satu probe — jalur kondisi tunak | | 2 | Pemeriksaan provenans sebelum membayar pemindaian dingin | satu pembacaan | | 3 | Tier kanonis Uniswap, dikelompokkan melalui `extsload(bytes32[])` | satu panggilan untuk satu kelompok | | 4 | Pasangan `(fee, spacing)` yang dideklarasikan oleh baris registrasi | dibatasi oleh registrasi | | 5 | Grid generator cold-start — fee $= 10{,}000\,j$, spacing $= 100\,j$, $j$ menurun dari `V4_GRID_MAX = 99` | paling banyak `V4_GRID_PROBES = 40` yang di-probe | Seluruh pemindaian berhenti pada `V4_CAP = 8` pool yang terbukti. Dua sifat muncul dari konstruksinya, bukan dari sebuah pemeriksaan: pool ber-hook tidak akan pernah dapat dikeluarkan oleh pemindaian ini — pemindaian menurunkan id *tanpa hook*, dan id tanpa hook dari pool ber-hook tidak ada di manager, sehingga ia gagal dalam bukti keaktifan sebelum pertanyaan kebijakan apa pun diajukan — dan id duplikat dari tebakan tier yang berbeda digabungkan menjadi satu kandidat, sehingga satu pool tidak dapat memenuhi corong melalui aliasing. Urutan probe itu sendiri merupakan kebijakan, karena batas tersebut terpakai oleh apa pun yang di-probe terlebih dahulu: pasangan terhadap aset native milik chain memiliki dua kunci di V4, native dan wrapped, dan kunci native terukur sebagai yang lebih dalam pada chain yang dilayani saat urutan ini diputuskan (3.76× di Base, 292× di Robinhood Chain), sehingga kunci native di-probe terlebih dahulu.  **Pintu tanpa izin.** Siapa pun dapat memanggil `claimV4(c0, c1, fee, tickSpacing)` dan membuat sebuah pool tanpa hook diterima, karena klaim tersebut membawa buktinya sendiri: id dihitung ulang dari kunci yang diajukan dan dibaca kembali dari storage manager, sehingga klaim palsu menghasilkan nilai nol dan tidak menerima apa pun (`HubE(9)`). Tiga syarat tambahan menjaga pintu ini: salah satu sisi pasangan harus berupa koin jembatan yang dapat dirutekan, sehingga satu kursi di registri yang berkapasitas terbatas tidak pernah terpakai untuk pasangan yang tidak akan pernah dapat dilintasi router; biaya efektifnya harus dapat dikuotasi di bawah gerbang biaya di bawah ini; dan klaim tersebut harus melewati margin penerimaan yang sama dengan yang dilewati registrasi yang dipicu oleh swap (§9), dengan likuiditas terukur pool sebagai kedalamannya. Registri dapat diajari oleh publik dan tidak dapat dibohongi olehnya. ### §5.2 Membaca pool yang tidak menjawab panggilan apa pun Dengan id yang terbukti aktif, dispatcher memerlukan harga dan likuiditas — dan tidak ada `slot0()` untuk dipanggil. Core membaca storage singleton secara langsung melalui `extsload` seperti pada contoh di atas, dan cabang V4 tereduksi menjadi bentuk tertutup likuiditas terkonsentrasi pada §4.2: matematika yang sama, disiplin overflow yang sama. Singleton mengubah di mana state berada, bukan apa arti state tersebut. Manager tanpa kode atau yang tidak sesuai standar menghasilkan word yang seluruhnya nol — gagal tertutup (fail-closed), tidak pernah revert. ### §5.3 Penyelesaian dengan singleton Eksekusi membalik alur kendali yang biasa. Alih-alih memanggil pool lalu dipanggil balik untuk pembayaran, Router memanggil `unlock` pada manager dan melakukan seluruh swap di dalam callback yang diberikan manager kepadanya: swap, lalu selesaikan setiap mata uang yang terutang melalui `sync → settle → take`, lalu lepaskan lock. Mata uang yang sedang dalam proses dibawa melintasi batas unlock dalam transient storage (`TSLOT_V4IN`, `TSLOT_V4OUT`), sehingga frame tersebut tidak mengotori state persisten apa pun dan konteksnya terbukti kosong di antara swap. `BalanceDelta` yang dikembalikan manager berbentuk terkemas — `amount0` pada 128 bit teratas, `amount1` pada bit terendah — dan Router mendekodenya sesuai bentuk itu sebelum aritmetika penyelesaian apa pun dijalankan. Mata uang native mempertahankan invarian yang penting. Router bersifat WETH-kanonis di mana pun — nilai native yang masuk ke `swapExactInNative` di-wrap tepat sekali di pintu, dan output native sengaja tidak diimplementasikan: penerima menerima WETH, yang tidak dapat terperangkap diam-diam oleh jalur mana pun. Leg V4 native melakukan unwrap *tepat pada waktunya* di dalam frame unlock-nya sendiri — `WETH.withdraw`, lalu `settle` dengan nilai, dengan ETH yang diterima dari `take` native di-wrap ulang dalam frame yang sama — sehingga ETH native tidak pernah ada dalam keadaan diam di dalam kontrak. Satu-satunya permukaan baru yang diperlukan untuk ini adalah `receive()` yang dijaga sesempit yang dimungkinkan oleh kebutuhan tersebut: sebuah slot transient (`TSLOT_ETHOK`) memegang satu-satunya alamat yang diizinkan mengirim ETH mentah ke Router pada saat itu — kontrak WETH kanonis selama unwrap, PoolManager selama take native, nol pada setiap saat lainnya — sehingga ETH polos dari pihak lain mana pun akan revert. Pintu native bersifat gagal tertutup hingga `weth` terhubung (`RouterE(3)`). ### §5.4 Biaya yang hanya ada pada saat eksekusi Pool V4 berbiaya statis membawa biaya LP-nya di dalam kuncinya, tempat biaya itu tidak dapat diubah. Pool manager juga dapat memungut biaya manager milik Uniswap sendiri — dibatasi 1,000 pip, sepersepuluh dari satu persen, per arah — yang tidak ditambahkan oleh lengan statis Core, sehingga kuotasi pada kunci statis dapat melebih-lebihkan output yang diserahkan hingga sebesar biaya manager tersebut begitu fee controller Uniswap mengaktifkannya (biaya itu nol pada setiap chain yang dilayani pada saat penulisan); kekurangannya jatuh di dalam lantai, dan basis biaya, karena diukur, mengabaikannya. Pool berbiaya dinamis sebagai gantinya membawa sentinel `0x800000`, dan biaya sebenarnya berada di `slot0`. Mengkuotasi sentinel apa adanya akan memberi harga perdagangan seolah gratis sementara eksekusi membayar tarif aktual. Gerbangnya berupa tiga baris di Core (`effV4Fee`): $$ f_{\mathrm{eff}} \;=\; \begin{cases} f_{\mathrm{key}} & f_{\mathrm{key}} \ne \mathtt{0x800000} \\ \mathtt{0xFFFFFF}\ (\text{unquotable}) & f_{\mathrm{key}} = \mathtt{0x800000} \ \wedge\ f_{\mathrm{proto}} \ne 0 \\ f_{\mathrm{LP}}\ \text{read from } \mathtt{slot0} & \text{otherwise} \end{cases} $$ ^e19 Kunci berbiaya dinamis yang disertai biaya protokol bukan nol mengembalikan biaya pada atau di atas $10^{6}$, dan `outV3` mengembalikan nol untuknya: gagal tertutup, karena komposisi biaya protokol dan biaya LP belum terjangkar sesuai standar kami, dan biaya protokol terukur di Base pada saat penulisan adalah nol, sehingga cabang tersebut dalam praktiknya tidak menimbulkan biaya. Aturan yang sama menutup celah yang sama pada satu famili di sebelahnya: pool Algebra berbiaya dinamis secara konstruksi dan mendaftarkan sentinel nol, sehingga `quoteV3Fee` menganggap biaya terkonfigurasi yang bukan nol sebagai kebenaran, biaya pool dinamis diambil dari pembacaan `globalState` yang sudah menyediakan harganya, dan — untuk fork likuiditas terkonsentrasi yang biayanya dikunci berdasarkan tick spacing dan berada di pool — `fee()` milik pool itu sendiri, gagal tertutup pada `0xFFFFFF` ketika tidak ada yang menjawab. Pool V3 statis tidak memerlukan pembacaan tambahan dan mengkuotasi secara identik hingga tingkat byte. Satu celah tersisa dan dibatasi alih-alih dihilangkan: hook berbiaya dinamis dapat menimpa biayanya per swap di dalam `beforeSwap`, sehingga biaya yang tersimpan di `slot0` tidak dalam setiap kasus merupakan biaya yang dieksekusi. Residu tersebut dibendung oleh daftar izin hook milik Hub pada saat penerimaan dan oleh lantai Iron-Law yang diturunkan ulang dari output yang terealisasi pada saat eksekusi, sehingga penimpaan yang bermusuhan berakhir sebagai revert atau kekurangan di dalam lantai, tidak pernah sebagai pengisian di bawah lantai (§14). ### §5.5 Hook: disaring dengan aritmetika, tidak pernah dengan interogasi Hook adalah kode arbitrer yang berjalan di dalam penyelesaian yang sedang dilakukan Router. Pertahanan yang intuitif — menanyakan kepada hook apa niatnya — bukanlah pertahanan, karena hook yang bermusuhan akan berbohong atau melakukan re-entry. BlazePhoenix tidak pernah menanyakan apa pun kepada hook. Sebagai gantinya, tiga lapisan independen berdiri, dimulai dari yang termurah, dan §14 menguraikannya: bit izin hook berada pada empat belas bit terendah dari alamatnya sendiri, ditetapkan saat deployment, dan dua bit yang mengizinkan pengubahan delta swap ditolak oleh satu operasi AND sebelum token apa pun berpindah (`hookAltersDeltas`, `RouterE(9)`); hook hanya dapat dirutekan selama berada dalam daftar izin dan selama kode runtime-nya masih cocok dengan codehash yang disematkan pada saat penerimaan (`isHookLive`); dan proyektor Ξ menghapus hook yang mengubah delta dari himpunan kandidat Solver sebelum pemeringkatan, sehingga rute tersebut bahkan tidak pernah dapat direpresentasikan. Residunya dinyatakan bersama mekanismenya: hook yang ada dalam daftar izin dan bebas delta masih dapat revert di tengah swap dan memboroskan gas dari percobaan tersebut — harga dari penolakan, secara prinsip, untuk memanggil kode yang tidak tepercaya demi mengetahui apa yang akan dilakukannya. ### §5.6 Nilai dari integrasi ini Setiap mekanisme di atas adalah primitif Core yang sudah digunakan di tempat lain, diterapkan pada tata letak state yang baru, atau primitif yang benar-benar baru yang dapat digeneralisasi melampaui V4 — penemuan berbasis bukti keberadaan. Tidak ada yang berupa integrasi per pool, dan tidak ada yang berupa daftar kurasi yang harus terus diperbarui oleh manusia. Pool V4 ditemukan tanpa direktori, dibuktikan terhadap storage yang tidak dapat ditulis oleh pihak lain, diberi harga dengan bentuk tertutup yang sama seperti setiap venue terkonsentrasi lainnya, dijaga biayanya melalui pengukuran dengan penolakan gagal tertutup ketika pengukuran tidak eksak, disaring dari hook yang bermusuhan melalui aritmetika alamat yang tidak dapat diubah, diselesaikan melalui protokol lock milik singleton itu sendiri, dan dapat dijangkau dengan ETH native tanpa Router menyimpan satu wei pun darinya dalam keadaan diam. §17 memuat hasil pengukurannya: dalam sensus factory di Arbitrum, famili V4 memenangkan lebih banyak pasangan hop dibandingkan venue terdaftar lainnya, dan di Optimism sensus tersebut mencatat apa yang, sejauh pengetahuan kami, merupakan agregasi berute V4 pertama di chain tersebut. Kami tidak mengetahui agregator publik lain yang menurunkan, membuktikan, memberi harga, menyaring, dan menyelesaikan pool V4 sepenuhnya di dalam transaksi yang sedang dieksekusi, termasuk ETH native, tanpa daftar pool yang dikurasi; jika Anda menemukannya, klaim ini keliru dan kami ingin mengetahuinya. ## §6 Solver Solidly Sebagian invarian tidak memiliki bentuk tertutup yang cukup sederhana untuk direproduksi dengan aman, dan mereproduksinya justru merupakan risiko replikasi yang ditolak protokol ini di tempat lain. Untuk venue semacam itu, dispatcher bertanya kepada pool, melalui saluran jujur tersempit yang disediakan venue tersebut — dan menyimpan sebuah replika sebagai cadangan untuk fork yang tidak menjawab. Famili Solidly — Aerodrome, Velodrome, dan fork-fork mereka — melayani aset yang berkorelasi pada pasangan stabil dengan invarian kuartik yang menempel pada diagonal jauh lebih rapat daripada constant product sambil tetap memungkinkan divergensi: $$ k(x, y) \;=\; x^{3}y \;+\; x\,y^{3} \;=\; x\,y\left(x^{2}+y^{2}\right) $$ ^e5 Di dekat titik keseimbangan, kurva ini menghasilkan output yang hampir sama dengan seluruh input — slippage minimal tepat di tempat aliran stablecoin dan liquid-staking berkumpul. Pasangan Solidly volatil adalah constant product, dan lengan volatil Core *adalah* `outV2` — satu produsen, yang dikunci oleh relasi metamorfik MR7 (§15).  **Jalur utama: tanyakan kepada pool.** `getAmountOut(amountIn, tokenIn)` dihitung oleh bytecode milik pasangan itu sendiri — termasuk biaya aktual, kurva, dan pembulatan — sehingga swap yang meminta tepat angka tersebut memenuhi pemeriksaan invarian pool secara konstruksi, dan tidak diperlukan margin. Pemicu fallback adalah jawaban sebesar paling banyak 1 wei, diselaraskan di ketiga saluran yang bertanya (Solver, Router, Quoter) setelah sebuah pool yang menjawab tepat 1 pernah mengirim dua di antaranya ke cabang yang berbeda. **Fallback: replikasi, lalu minta lebih sedikit.** Ketika sebuah fork tidak menyediakan selector tersebut, dispatcher membaca biaya aktual dari factory pasangan itu (`getFee(pool, stable)`; biaya fallback yang dideklarasikan hanya dipercaya dalam batas plafon 100 bps yang sama dengan lengan V2, jika tidak maka 30 bps), menyelesaikan invarian pada cadangan yang dinormalisasi desimalnya, lalu mengalikan hasilnya dengan 9,800 / 10,000 — potongan (haircut) 200 bps agar pembulatan pool, yang tidak dapat diamati oleh replika, selalu memiliki kelonggaran. Potongan tersebut hanya berlaku pada fallback dan tidak pernah ketika pool menjawab sendiri. **Penyelesaian persamaan.** Diberikan saldo input pasca-perdagangan $x$ dan invarian target $K$ dari cadangan pra-perdagangan, Core mencari akar dari $f(y) = x^{3}y + xy^{3} - K$, dengan $f'(y) = x(x^{2} + 3y^{2}) > 0$, melalui iterasi Newton yang diawali pada $y_{0} = Y$, yaitu cadangan pra-perdagangan sisi seberang (`_solY`): $$ k(x, y_{n}) < K:\ \ y_{n+1} = y_{n} + \max\!\left(1,\ \left\lfloor \tfrac{K - k(x,y_{n})}{f'(y_{n})} \right\rfloor\right); \qquad k(x, y_{n}) \ge K:\ \ y_{n+1} = y_{n} - \delta_{n},\ \ \delta_{n} = \begin{cases} \lfloor y_{n}/2 \rfloor & d_{n} \ge y_{n} \\ \max(1, d_{n}) & \text{otherwise} \end{cases},\ \ d_{n} = \left\lfloor \tfrac{k(x,y_{n}) - K}{f'(y_{n})} \right\rfloor $$ ^e6 Nilai awal yang tampak wajar — aproksimasi constant-sum — keliru dengan cara yang diam-diam merusak harga: untuk pool yang menyerap input beberapa kali lipat cadangannya, nilai awal itu mendarat jauh di atas akar pada wilayah tempat $f$ sangat curam, langkahnya dibulatkan ke bawah menjadi nol, dan solver terpaku pada angka yang meyakinkan, masuk akal, namun salah. Memulai dari cadangan sisi seberang dan melangkah ke dua arah menghasilkan konvergensi baik untuk pool yang seimbang maupun yang sangat timpang. Langkah turun yang akan melewati nol diganti dengan setengah dari iterasi saat itu; setiap langkah memaksa kemajuan paling sedikit satu unit; iterasi berhenti ketika iterasi-iterasi berturutan berbeda paling banyak satu unit dan mendarat di sisi yang aman bagi invarian melalui penyesuaian akhir satu unit yang merugikan pengambil (taker). Loop dibatasi 64 iterasi dan batas itu bersifat gagal tertutup: solver mengembalikan nilai awal itu sendiri, yang dipetakan oleh penjaga $y \ge Y$ milik pemanggil menjadi kuotasi nol — pool diperlakukan sebagai tidak dapat diberi harga, sejalan dengan cara Aerodrome sendiri menolak alih-alih salah memberi harga. Turunan yang lenyap mengambil jalan keluar yang sama. **Normalisasi desimal.** Invarian tersebut homogen berderajat empat, sehingga ketika kedua token memiliki desimal yang sama, skalanya saling meniadakan dan cadangan mentah dapat langsung digunakan. Pasangan seperti DOLA (18 desimal) terhadap USDC (6) membawa ketidakcocokan tersebut ke dalam kuartik, sehingga Core menskalakan kedua sisi ke basis bersama $10^{18}$ sebelum menyelesaikan persamaan dan mengembalikan skalanya sesudahnya: $$ X = r_{\mathrm{in}}\cdot 10^{\,18-d_{\mathrm{in}}},\quad Y = r_{\mathrm{out}}\cdot 10^{\,18-d_{\mathrm{out}}},\quad A = \left\lfloor\frac{x\cdot 10^{\,18-d_{\mathrm{in}}}\,(\mathrm{BPS}-f)}{\mathrm{BPS}}\right\rfloor,\quad \mathrm{out} = \left\lfloor\frac{Y - y^{\star}(X+A,\,K)}{10^{\,18-d_{\mathrm{out}}}}\right\rfloor $$ ^e7 Token yang melaporkan lebih dari delapan belas desimal menghasilkan kuotasi nol alih-alih mengalami underflow pada penskalaan. Desimal token lainnya dibaca dari pool, bukan diambil dari pemanggil — primitif satu-produsen yang menerima koordinat dari pemanggilnya akan membuka kembali divergensi yang justru ingin ditutupnya. **Gagal tertutup pada seluruh domain.** Empat penjaga menentukan apakah kurva dievaluasi sama sekali, dan masing-masing mengembalikan nol alih-alih revert, karena revert di dalam kuotasi berarti `DELEGATECALL` pustaka yang membatalkan seluruh rencana Solver untuk pasangan tersebut: $X$ dan $Y$ tidak boleh melebihi $3.4 \times 10^{38}$; $X + A$ juga tidak boleh; dan `_solKFits` mensyaratkan bahwa invarian $k = xy(x^{2}+y^{2})/\mathrm{WAD}^{3}$ dan turunan $x(x^{2}+3y^{2})/\mathrm{WAD}^{2}$ keduanya muat dalam word 256-bit pada nilai awal, yang merupakan titik terbesar yang dikunjungi Newton. Uji terakhir itu diajukan tanpa pembagian — ia menghitung word tinggi dari hasil kali 512-bit dan membandingkannya dengan satu WAD (`_mulFitsWad`) — karena bentuk sebelumnya, $a \le \max \cdot \mathrm{WAD} / b$, justru mengalami overflow pada pool yang memegang kurang dari satu unit sebuah token. Jalur N-version pada §15 menemukan celah itu pada 2026-09-05; perbaikannya 35 byte lebih kecil daripada kode yang digantikannya dan dimasukkan dengan pendekatan red-first, dengan fuzz 5,000 run atas seluruh domain, sapuan 60,000 sampel atas aritmetika yang sama di Python, dan tiga mutan di dalam penjaga tersebut. **Residu terukur, dan margin 200 bps.** Replika tersebut diukur terhadap pool Aerodrome yang aktif dengan `getAmountOut` milik pool itu sendiri sebagai kebenaran acuan: | Pool | Keadaan | Kebenaran acuan | Output Core | Deviasi | |---|---|---|---|---| | USDC / USDbC | seimbang (6 / 6 des.) | 999,534,071 | 999,534,071 | 0.000 % | | DOLA / USDC | timpang (18 / 6 des.) | 985,528,437 | 987,998,286 | 0.251 % | | USDz / USDC | timpang (18 / 6 des.) | 899,325,141 | 901,565,830 | 0.249 % | Pasangan yang seimbang cocok hingga ke bilangan bulatnya; pasangan yang timpang berada dalam rentang 0.5 %, di sisi atas, karena pembulatan saldo pasca-biaya milik pool tidak terlihat dari luar. Residu itulah alasan fallback meminta 200 bps lebih sedikit: margin tersebut menjamin bahwa pemeriksaan invarian pasangan memiliki kelonggaran saat eksekusi, mengubah kemungkinan revert akibat kuotasi berlebih menjadi pengisian yang pasti, dan margin itu diterapkan secara identik pada permukaan pratinjau dan permukaan di dalam frame sehingga keduanya tetap seiring. Jalur oracle kanonis pada §15 membatasi kurva tersebut secara independen: terhadap implementasi yang ditulis dari spesifikasi venue, kuotasi stabil Core berada dalam selisih 4 wei pada 5,000 input hasil fuzz. ## §7 Penurunan Deterministik 𝒟 Sebelum sebuah pool dapat dikuotasi, pool itu harus ditemukan. Jawaban industri adalah bertanya: sebuah panggilan ke factory milik venue membaca mapping storage dan mengembalikan sebuah alamat, dan pemanggil menerima begitu saja perkataan factory tersebut. BlazePhoenix mendukung jawaban itu — empat mode panggilan factory mencakup venue yang deployment-nya tidak dapat direproduksi — dan lebih memilih jawaban yang lebih kuat di mana pun aritmetika memungkinkannya: hitung alamatnya, tanpa panggilan eksternal. Alamat yang dihitung dapat diverifikasi oleh siapa pun yang memiliki tiga input yang sama; alamat yang diambil hanya dapat dipercaya. Mekanismenya adalah CREATE2. EVM menjadikan alamat sebuah kontrak sebagai fungsi murni dari deployer-nya, sebuah salt, dan hash dari init code-nya: $$ \mathrm{pool} \;=\; \mathrm{addr}_{20}\!\left(\mathrm{keccak256}(\mathtt{0xff}\,\Vert\,\mathrm{origin}\,\Vert\,\mathrm{salt}\,\Vert\,\mathrm{initCodeHash})\right) $$ ^e8 dengan $\mathrm{addr}_{20}$ mengambil dua puluh byte terakhir dari hash tersebut. Core menuliskan preimage 85-byte itu secara eksplisit tepat satu kali (`create2Address`); `deriveAddress` memilih polinomial salt dan origin berdasarkan mode, dan penurunan Algebra teratestasi milik Hub menggunakan kembali produsen yang sama. | Mode | Famili | Resolusi | Detail salt / probe | |---|---|---|---| | 0 | V2 | panggilan factory `getPair(t0,t1)` — selector `0xe6a43905` | — | | 1 | V3 / Algebra | panggilan factory `getPool(t0,t1,fee)` — `0x1698ee82`; jika tidak ditemukan, `poolByPair(t0,t1)` — `0xd9a641e1` | — | | 2 | Solidly | panggilan factory `getPool(t0,t1,stable)` — `0x79bc57d5` | — | | 3 | Fork Solidly terkonsentrasi (Slipstream, Velodrome CL) | panggilan factory `getPool(t0,t1,tickSpacing)` — `0x28af8d0b` | — | | 4 | V2 CREATE2 | aritmetika murni | `keccak256(packed(t0,t1))`, origin = factory | | 5 | V3 CREATE2 | aritmetika murni | `keccak256(encode(t0,t1,fee))`; `fee == 0` adalah sentinel Algebra → `keccak256(encode(t0,t1))`, origin = `poolDeployer()` milik factory (`0x3119049a`), diatestasi pada saat penerimaan | | 6 | CREATE2 klon Solidly | aritmetika murni | `keccak256(packed(t0,t1,stable))`, origin = factory | | 7 | CL CREATE2 | aritmetika murni | `keccak256(encode(t0,t1,tickSpacing))`, origin = factory | | 8 | *dipensiunkan* | dibebaskan oleh pemangkasan Curve; sebuah nisan — `MODES_VALID = 0x2FF` menolaknya | — | | 9 | Derive-scan V4 | turunkan poolId tanpa hook dan buktikan keaktifannya di PoolManager (§5.1) | grid ≤ 99 tier, ≤ 40 di-probe dingin, berhenti pada 8 pool | Mode 0–3 masing-masing berupa satu `staticcall`; mode 4–7 berupa nol panggilan dan hanya memerlukan hash init-code yang benar; mode 9 melayani satu-satunya famili yang pool-nya tidak dapat ditemukan dengan kedua cara tersebut. **Teorema, klaim, dan bukti.** Alamat yang diturunkan adalah sebuah teorema atas pasangan tersebut: dengan origin, polinomial salt, dan hash init-code, alamat itu mengikuti dari keccak saja, dan siapa pun yang membantahnya dapat menghitungnya ulang. Alamat yang ditanyakan adalah klaim sebuah factory tentang storage-nya sendiri — dan sebuah factory dapat menjawab dengan pool untuk token lain. Sejak 2026-09, pool yang ditanyakan (mode 0–3) membuktikan pasangannya sendiri sebelum penemuan mencantumkannya: Hub membaca `token0()` dan `token1()` miliknya — dua pembacaan yang sama dengan yang dilakukan Router pada titik sambungan yang membayar — dan ketidakcocokan akan menggugurkan kandidat tersebut, sehingga pool yang akan ditolak oleh eksekutor tidak pernah dicantumkan, direncanakan, atau diperingkatkan. Matriks venue bermusuhan pada §15-lah yang mengubah hal ini: run pertamanya mencantumkan pool yang dijawabkan oleh sebuah factory yang diterima kurator, perencana memeringkatnya, dan eksekutor menolaknya pada titik sambungan yang membayar — dana tidak pernah berisiko, pasangan itu ditolak sementara si penipu memenangkan pembagian. **Dua kehalusan pada baris berbentuk V3.** Algebra (kelas Camelot) memungut biaya dinamis, sehingga biaya tidak pernah dapat menjadi bagian dari identitasnya: registrasi Algebra mendeklarasikan biaya nol sebagai sentinel, mode 5 menghilangkan biaya dari salt, dan origin CREATE2 adalah kontrak `poolDeployer` terpisah yang disediakan oleh factory Algebra. Origin tersebut adalah satu-satunya input penurunan yang masih dapat dikendalikan factory setelah penerimaan — sebuah proxy dapat mengubah jawabannya dengan codehash yang tetap utuh — sehingga Hub mengatestasinya satu kali pada `addFactory` (`factoryDeployer`) dan sesudahnya menurunkan dari origin yang teratestasi; setelah kendali dilepaskan, atestasi tersebut dibekukan. Di sisi panggilan factory, factory Algebra menyediakan `poolByPair` alih-alih `getPool`, sehingga pencarian mode 1 yang tidak mengembalikan apa pun dicoba ulang dengan selector tersebut sebelum menyerah. **Setiap penurunan melewati satu gerbang terakhir.** Hub membuang setiap alamat turunan yang tidak membawa bytecode runtime — `extcodesize` adalah seluruh pemeriksaannya (`hasCode`) — sehingga hash init-code yang salah, registrasi yang usang, atau chain tempat sebuah famili tidak pernah di-deploy tidak menghasilkan apa pun alih-alih venue hantu. Bytecode pada alamat tersebut membuktikan keberadaan, bukan kejujuran, itulah sebabnya penerimaan, pita kepercayaan, dan lantai tetap berdiri di antara pool yang ditemukan dan perdagangan yang terisi. Pool yang sama yang diturunkan melalui beberapa kombinasi `(fee, spacing)` dicantumkan sekali. **Batas antara menurunkan dan bertanya bersifat empiris.** Venue berbasis klon seperti Velodrome dan Aerodrome tetap menggunakan panggilan factory meskipun hash init-code-nya diketahui, karena origin CREATE2 mereka berada di dalam deployer klon deterministik internal, bukan di factory — alamatnya tidak dapat direproduksi dari input publik, sehingga protokol bertanya. Uniswap V3 adalah kasus unggulan pada arah sebaliknya: hash init-code-nya merupakan satu konstanta pada setiap chain karena bytecode pool yang sama di-deploy di mana-mana, dan identitas `derived == getPool` berlaku pada fork Ethereum, Arbitrum, Optimism, dan Base terhadap factory milik masing-masing chain (§17). Turunkan di mana aritmetikanya sahih, bertanyalah di mana tidak, dan verifikasi semuanya dengan cara mana pun. **Penemuan mengonsumsi tabel baris demi baris.** Untuk masing-masing dari paling banyak `MAX_FACTORIES = 16` factory terdaftar, Hub melakukan probe pada setiap kombinasi `(fee, spacing)` yang dideklarasikan — baris Solidly dalam varian stabil maupun volatil, baris V4 yang mencadangkan hingga delapan — sehingga kasus terburuk pemindaian ditentukan oleh registrasi, bukan oleh suasana hati chain. Permukaan konfigurasi dijaga di pintu (§9): venue yang mustahil secara struktural tidak dapat disimpan. ## §8 Monoslot Storage adalah biaya dominan untuk melakukan apa pun di EVM: `SLOAD` dingin bernilai 2,100 gas, dan registri yang menyebarkan atribut sebuah pool ke slot-slot terpisah akan membayarnya lagi untuk setiap atribut, untuk setiap pool, pada setiap rute yang dievaluasi. BlazePhoenix mengemas seluruh state perutean sebuah pool ke dalam satu word 256-bit — Monoslot — yang dibaca sekali dan didekode dengan aritmetika murni. | Bit | Field | Lebar | Makna | |---|---|---|---| | 0 | `active` | 1 | slot aktif | | 1–7 | dicadangkan | 7 | bit 5 = kurva stabil (dibaca dari `stable()` milik pool sendiri saat registrasi); bit 6 = sisi native ditukar; bit 7 dahulu flag jembatan, kini tidak lagi ditulis — bonus jembatan dibaca langsung dari pasangan (§9) | | 8–31 | `fee` | 24 | tier biaya, dalam satuan asli venue | | 32–39 | `kind` | 8 | jenis venue (§4) | | 40–47 | `tier` | 8 | 0 = dikurasi (diisi oleh operator), 2 = tanpa izin (dipelajari melalui perdagangan atau diklaim) | | 48–59 | `conc` | 12 | field konsentrasi, di-mask ke `0xFFF` sebelum dikemas | | 60–63 | `bucket` | 4 | bucket kedalaman logaritmik | | 64–95 | `lastUpdateTs` | 32 | timestamp jam dinding dari sentuhan terakhir | | 96–127 | `emaIn` | 32 | dicadangkan untuk EMA volume input; ditulis sebagai nol saat registrasi, tidak diperbarui oleh tick yang dirilis | | 128–159 | `emaOut` | 32 | dicadangkan untuk EMA volume output; sama seperti di atas | | 160–191 | `swapCount` | 32 | hitungan aktivitas, jenuh pada $2^{32}-1$ | | 192–223 | `regBlk` | 32 | blok registrasi | | 224–255 | `lastBlk` | 32 | blok sentuhan terakhir |  Pengodeannya berupa rangkaian operasi shift dan OR (`encodeSlot`): $$ s \;=\; a \;\vert\; f\!\ll\!8 \;\vert\; k\!\ll\!32 \;\vert\; r\!\ll\!40 \;\vert\; (c \wedge \mathtt{0xFFF})\!\ll\!48 \;\vert\; b\!\ll\!60 \;\vert\; t\!\ll\!64 \;\vert\; e_{\mathrm{in}}\!\ll\!96 \;\vert\; e_{\mathrm{out}}\!\ll\!128 \;\vert\; n\!\ll\!160 \;\vert\; B_{\mathrm{reg}}\!\ll\!192 \;\vert\; B_{\mathrm{last}}\!\ll\!224 $$ ^e9 Satu detail merupakan penjaga, bukan kemudahan: field konsentrasi di-mask ke dua belas bit *sebelum* di-shift, sehingga tidak akan pernah merembes ke bucket kedalaman pada bit [63:60] — pengemasan ini melarang kelas tumpang-tindih field diam-diam yang merusak state terkemas, alih-alih memercayai pemanggil untuk tetap berada dalam rentang. Pendekodean sama mekanisnya: setiap accessor berupa satu shift dan satu pemotongan; penulis bucket membersihkan keempat bitnya sebelum mengaturnya; hitungan swap menjadi jenuh alih-alih berputar balik, sehingga slot yang penuh tidak akan pernah memutar riwayat pool yang sibuk kembali ke nol. Timestamp jam dinding, yang dicap oleh Hub pada setiap tick dan registrasi, menggerakkan baik peluruhan vitalitas pada §9 maupun gerbang kesegaran penemuan milik Solver. Perhatikan apa yang tidak dimuat oleh word tersebut: harga. Monoslot membawa segala yang diperlukan untuk memeringkat sebuah pool — aktivitas, kelas kedalaman, biaya, jenis, flag, kebaruan — dan tidak ada yang dapat disangka sebagai kuotasi, sehingga memori registri secara struktural tidak mampu memberi harga pada sebuah perdagangan. Harga dihitung baru, dari cadangan aktual, di dalam frame yang melakukan perdagangan berdasarkan harga itu; word terkemas hanya pernah memutuskan pool mana yang layak ditanyai. Jalur pembaruan menghormati penghematan yang sama: swap melalui pool yang dikenal menulis ulang word tersebut sekali — hitungan, bucket, timestamp, satu `SSTORE` atas satu `SLOAD` — sehingga biaya marjinal untuk menjaga registri tetap mutakhir ikut menumpang di dalam transaksi yang memang sudah dikirim pengguna. Mengapa satu word itu penting adalah soal perkalian. Solver melakukan probe hingga `MAX_CANDIDATES = 8` venue per pasangan pada hingga tiga topologi, sehingga satu perdagangan yang diselesaikan dapat menilai beberapa lusin pool sebelum memindahkan satu token pun. Dengan 2,100 gas per slot dingin, tata letak lima slot per pool menghargai tahap penilaian itu dalam ratusan ribu gas; Monoslot menghargainya satu pembacaan per pool, dan `psisOf` milik Hub mengembalikan skor setiap kandidat dalam satu panggilan terkelompok. Monoslot bukanlah optimisasi yang diterapkan pada perutean on-chain; ia adalah alasan perutean on-chain terjangkau sama sekali. ## §9 Registri Swa-Pulih dan Medan Vitalitas Ψ Sebagian besar agregator mengenal venue mereka karena seorang keeper mengindeks pool secara off-chain dan mendorong daftar ke on-chain — sebuah proses yang harus dipercaya, sebuah jendela kedaluwarsa, dan sebuah ketergantungan operasional, tiga hal yang tidak dapat diterima oleh protokol yang menyelesaikan rute secara on-chain. BlazePhoenix mengambil sikap sebaliknya: registri mempelajari likuiditas dengan memperdagangkannya. ### §9.1 Belajar dengan berdagang, dan bukti pasangan Pada setiap leg yang dieksekusi, Router memanggil `recordSwap` milik Hub (`onlyRouter`, `whenLive`), dengan meneruskan pool, jenisnya (kind), biayanya (fee), pasangannya, jumlah-jumlahnya, dan kedalaman yang diukurnya. Hub pertama-tama menolak setiap jenis yang tidak mungkin dieksekusi oleh Router (`KINDS_EXECUTABLE`) — sebuah pertahanan lokal yang tidak bergantung pada Router tetap seperti saat di-deploy — lalu menempuh salah satu dari dua jalur. Monoslot milik pool yang sudah dikenal di-tick: jumlah swap naik dari basisnya yang *saat ini telah meluruh*, bucket kedalaman dihitung ulang, blok dan timestamp jam dinding maju — satu word terkemas ditulis ulang, tanpa panggilan eksternal. Pool yang tidak dikenal menempuh jalur dingin. Pool tersebut pertama-tama harus lolos admisi (`_canInsert`, di bawah). Kemudian pool itu harus membuktikan klaim yang akan disimpannya: untuk setiap jenis berbentuk pasangan (`KINDS_PAIR_PROOF` = V2, V3, Solidly, Algebra) Hub membaca `token0()` dan `token1()` milik pool itu sendiri dan mensyaratkan keduanya cocok dengan pasangan — paling banyak dua `staticcall`, hanya pada jalur dingin. Setiap argumen untuk `recordSwap` adalah calldata yang dikendalikan pemanggil dan dibawa dalam rute Router — pool, jenis, dan kedalaman — sehingga tanpa bukti ini seorang penyerang dapat mendaftarkan kontrak yang ditulisnya sendiri, di bawah pasangan yang dipilihnya, pada kedalaman yang dipilihnya, tanpa memegang satu pun dari kedua token. Untuk dua jenis V4, yang bidang `pool`-nya adalah id terpotong tanpa bytecode, buktinya adalah penurunan ulang: tick spacing dipulihkan dan id dihitung ulang lalu dicocokkan, hanya untuk pool tanpa hook, sehingga pool ber-hook tidak pernah dapat terdaftar melalui pintu ini; pool V4 native dicocokkan dalam kedua orientasi `(address(0), T)`. Ketidakcocokan *melewati* pendaftaran dan tidak pernah melakukan revert, karena swap pengguna telah diselesaikan dan tidak boleh gagal karena sebuah keputusan registri. Bukti pasangan saat pendaftaran adalah hal baru pada September 2026, dan pengukuran yang menghasilkannya berasal dari §15: lima belas mutasi sumber dijalankan terhadap setiap invarian stateful, dan mutan yang menghapus bukti ini bertahan di setiap kampanye pada percobaan pertama, karena belum pernah ada tes yang menawarkan kepada Hub sebuah pool yang memperdagangkan token lain. Kampanye Hub kini melakukannya pada setiap percobaan — pasangan dibalik, satu token sama, dua token asing — dan `invariant_ActiveEntriesTradeThePair` membaca `token0`/`token1` setiap entri aktif; mutan tersebut kini menjadi entri penjaga yang mati karenanya. Penemuan (discovery) membawa bukti yang sama untuk pool yang ditanyakan (§7). Tidak ada indexer yang harus dijalankan dan tidak ada saat ketika protokol menjadi buta karena sebuah server mati. Pintu operator `seedPool` mengisi pasangan sejak awal saat deployment (tier 0, terkurasi) dan pintu permissionless `claimV4` menerima pool V4 tanpa hook di bawah bukti mereka sendiri (§5.1); keduanya adalah optimisasi, bukan ketergantungan — registri yang kosong menyembuhkan dirinya menjadi registri yang terisi melalui perdagangan biasa. ### §9.2 Skor Medan Vitalitas Ψ memisahkan kualitas dari kapasitas, dengan hanya membaca Monoslot dan status jembatan terkini dari pasangan tersebut (Core `psi`): $$ \Psi(s, t) \;=\; V(s, t)\cdot 2^{\,b(s)} \cdot \left(1 + \tfrac{2{,}500}{10^{4}}\,\mathbf{1}_{\mathrm{bridge}}\right)\cdot\left(1 + \tfrac{500}{10^{4}}\,\mathbf{1}_{\mathrm{conc}}\right) $$ ^e10 Bucket kedalaman $b = \min(15, \lfloor \log_{10}(d / 10^{15}) \rfloor)$ masuk melalui bobotnya $2^{b}$: setiap dekade kedalaman menggandakan bobot, sehingga kedalaman dihitung secara sub-linear — pool yang dalam diunggulkan dengan tegas, tetapi pool yang sekadar sehat tidak terhapus oleh sebuah raksasa. Pool pada pasangan jembatan mendapat +25 %, karena jembatan adalah jaringan penghubung graf likuiditas; pool terkonsentrasi mendapat tambahan +5 %. Bonus jembatan dibaca secara langsung dari pasangan oleh satu produsen (`_pairBridged`), bukan dari sebuah bit yang dibekukan saat pendaftaran, dan di dalam satu pasangan bonus itu seragam, sehingga tidak pernah dapat mengubah urutan pool dari pasangan yang sama. **Peluruhan — satu mekanisme.** Aktivitas meluruh seiring lamanya pool diam melalui satu aturan jam dinding (`_decayedSwapCount`): $$ V(s,t) \;=\; \mathrm{swapCount}(s) \;\gg\; \left\lfloor \frac{t - t_{\mathrm{last}}}{24{,}576\ \mathrm{s}} \right\rfloor, \qquad V = 0 \ \text{once the shift exceeds } 31. $$ ^e11 Langkahnya adalah `VITALITY_DECAY_STEP_SECONDS = 24,576` — sekitar 6.8 jam — dan tiga puluh dua kali pembagian dua memadamkan skor apa pun, sehingga pool yang diam mencapai nol dan dapat sepenuhnya dikeluarkan setelah 786,432 s, sekitar 9.1 hari. Satu swap menghidupkannya kembali, dan kebangkitan itu jujur: hitungan dilanjutkan dari apa yang tersisa setelah peluruhan, tidak pernah dari total sebelum peluruhan, sehingga satu swap debu setelah keheningan panjang tidak dapat memulihkan peringkat akumulasi sebuah pool. Pemberi skor memisahkan dua jenis nol: slot yang *mati* — kosong, tidak pernah di-tick, atau melewati cakrawala — mendapat skor nol sejati dan keluar dari pemeringkatan, sedangkan slot yang *hidup* yang hitungannya kecil hanya terbulatkan hilang oleh pergeseran diberi lantai satu, sehingga pool nyata yang baru saja disentuh tidak pernah lenyap karena sebuah artefak pembulatan. Jendela itu sengaja dinyatakan dalam detik jam dinding: jendela yang dihitung per blok berarti durasi nyata yang berbeda di setiap chain, dan implementasi sebelumnya yang bergeser setiap 16 blok meluruh ke nol sekitar 128× lebih cepat daripada yang didokumentasikan.  ### §9.3 Pengeluaran (eviction) Setiap pasangan menampung paling banyak `MAX_SLOTS = 16` pool. Ketika pool ketujuh belas ingin masuk, Hub memberi skor setiap petahana dengan Ψ penuh — kedalaman, bonus, dan semuanya, sehingga pendatang baru yang dalam dapat menggeser penghuni yang dangkal-tetapi-hangat — dan menerima pendatang baru hanya jika skor proyeksinya melampaui petahana terlemah dengan suatu margin (`_canInsert`): $$ \Psi_{\mathrm{new}} \;>\; \Psi_{\mathrm{worst}} + \left\lfloor \Psi_{\mathrm{worst}}/4 \right\rfloor, \qquad \Psi_{\mathrm{new}} = 2^{\,b(d_{\mathrm{new}})} $$ ^e13 dengan pendatang baru diberi skor secara konservatif — vitalitas satu, bucket kedalamannya sendiri, tanpa bonus — dan pendatang baru berkedalaman nol ditolak mentah-mentah. Margin itu menutup sebuah vektor griefing: di bawah aturan polos geser-yang-terendah, seorang lawan dapat menahan enam belas slot dangkal yang nyaris aktif dan menghalangi pesaing yang dalam; dengan pemeringkatan berdasarkan Ψ disertai margin, pool yang benar-benar lebih dalam tetap menang. Batas konstanta ini dinyatakan di tempat ia ditegakkan: bobot pendatang baru adalah pangkat dua sedangkan skor petahana bersifat kontinu, sehingga margin efektif berkisar dari sekitar 100 % (petahana sedikit di atas satu) turun hingga sekitar 25 % (petahana pada 51, pendatang baru terkecil yang dapat diterima 64); 25 % dari aturan tersebut juga merupakan lantai perilakunya, tidak pernah dilampaui ke bawah. Petahana yang banyak diperdagangkan sulit digeser sampai peluruhan menjalankan tugasnya — dua hari diam membuatnya kehilangan tujuh kali pembagian dua. Klaim V4 permissionless melampaui margin yang sama dengan likuiditas terukur pool sebagai kedalamannya. ### §9.4 Penemuan, dan kenop gas-nya Penemuan adalah sebuah view publik: untuk pasangan apa pun Hub menelusuri daftar factory-nya, menurunkan kandidat menurut mode-mode pada §7, menerapkan `hasCode` dan bukti pasangan, dan Solver menggabungkan hasilnya dengan himpunan yang terdaftar, dideduplikasi berdasarkan alamat, sehingga tidak ada sumber yang dapat menekan sumber lainnya. Untuk membatasi gas, Solver menerapkan gerbang kesegaran (`_registryFresh`): ketika setidaknya `MIN_FRESH_VENUES = 3` venue terdaftar yang *terkurasi* untuk pasangan tersebut telah disentuh dalam `DISCOVERY_TTL_SECONDS = 3,600`, Solver memercayai registri dan melewati sapuan penurunan. Hanya baris terkurasi (tier 0) yang dapat menjamin: baris permissionless ditulis oleh siapa pun yang pertama melakukan swap, dan menghitungnya memungkinkan tiga pasangan debu yang didaftarkan sendiri, yang dijaga tetap segar oleh tiga swap debu per jam, mematikan penemuan untuk sebuah pasangan dan menyembunyikan setiap venue jujur yang tidak pernah terdaftar. Baris permissionless tetap menjadi kandidat; ia tidak lagi memilih jalurnya. Gerbang ini adalah kenop gas dan cakupan, tidak pernah parameter keamanan — lantai Iron-Law dan output minimum pengguna melindungi setiap pengisian (fill) terlepas dari seberapa usang registri, karena keduanya sama sekali tidak membaca registri. ### §9.5 Permukaan konfigurasi Pintu-pintu pendaftaran Hub dijaga di jalan masuk. `addFactory` menolak, sebelum state apa pun ditulis (`HubE(5)`): jenis di luar `KINDS_ROUTABLE`; mode di luar `MODES_VALID`; mode CREATE2 dengan hash init-code nol; slot V2-salt yang terikat pada apa pun selain jenis V2; slot clone yang terikat pada jenis non-Solidly; slot V3-salt yang terikat pada apa pun selain V3 atau Algebra, dengan pendaftaran Algebra diwajibkan mendeklarasikan setiap biaya sebagai sentinel nol; dan baris derive-scan V4 yang terikat pada jenis apa pun selain V4 atau dengan daftar biaya dan spacing yang berpasangan salah. Factory yang sudah dikenal diperbarui di tempat, tidak pernah diberi baris kedua, sehingga satu alamat tidak dapat menghabiskan enam belas kursi (`HubE(4)`); setelah kendali dilepaskan (renounce), factory yang kode runtime-nya berpindah tidak dapat dipersenjatai ulang, dan baris derive tidak dapat diubah menjadi baris ask. `allowHook` menyematkan codehash hook saat admisi, dan sebuah hook hanya dapat dirutekan selama masuk daftar izin *dan* tidak berubah (`isHookLive`); setelah pelepasan kendali, penghapusan dari daftar tidak lagi tersedia dan hook yang berpindah tetap dijeda untuk selamanya. Jembatan paling banyak `MAX_BRIDGES = 3`; `addBridge` adalah kewenangan kurator yang bertahan setelah pelepasan kendali, `removeBridge` adalah kewenangan kendali yang mati bersamanya. ### §9.6 Batas struktural Satu kalimat membatasi semua hal di atas: **Ψ dapat menyembunyikan sebuah venue; Ψ tidak pernah dapat salah memberi harga padanya.** Skor memeringkat dan memangkas himpunan kandidat — tidak ada kuotasi, tidak ada lantai, dan tidak ada alokasi yang membacanya, karena semua itu dihitung dari pengukuran di dalam transaksi; memori mencapai pemilihan rute hanya melalui penghilangan. Apa pun yang diyakini registri, hal terburuk yang dapat dimunculkannya adalah harga terkini yang lebih buruk-tetapi-nyata, dan nilai yang dapat dilewatkan oleh harga semacam itu dibatasi oleh yang paling ketat di antara pita kepercayaan, lantai Iron-Law yang diturunkan ulang di dalam frame, dan output minimum yang ditetapkan pengguna. Pokok (principal) berada di luar jangkauan secara konstruksi. Registri memutuskan apa yang terlihat; registri tidak punya suara atas apa yang dibayar. ## §10 Perutean dan Alokator Pembagian Pool constant-product memberi harga dengan satu aturan: kedua cadangannya, jika dikalikan, tidak boleh pernah menyusut. Tuangkan $\Delta$ dengan retensi biaya $\gamma$ (biaya venue 0.30 % berarti $\gamma = 0.997$) dan Anda menerima $y\,\gamma\Delta / (x + \gamma\Delta)$, dengan input Anda sendiri di dalam penyebut: semakin banyak yang Anda dorong melalui satu pool, semakin buruk bayaran untuk setiap token berikutnya. Slippage adalah aritmetika, demikian pula obatnya: membagi order yang sama ke beberapa pool dari pasangan yang sama menggerakkan setiap pool lebih sedikit. **Contoh terhitung 2 — pembagian ke dua pool.** Satu order sebesar 100 terhadap dua pool dari pasangan yang sama, keduanya pada 0.30 %: pool A menampung 1,000 per sisi, pool B menampung 4,000 per sisi. | Rute | Aritmetika | Anda menerima | |---|---|---| | Seluruh 100 ke A | $1{,}000 \times 99.7 / 1{,}099.7$ | 90.661 | | Seluruh 100 ke B | $4{,}000 \times 99.7 / 4{,}099.7$ | 97.275 | | 20 ke A, 80 ke B | $1{,}000 \times 19.94 / 1{,}019.94 \;+\; 4{,}000 \times 79.76 / 4{,}079.76$ | $19.550 + 78.201 = 97.751$ | Pembagian 20 / 80 adalah pilihan alokator itu sendiri, bukan tebakan: bobot sebanding dengan kedalaman terukur terhadap kandidat terdalam — A berbobot $1{,}000/4{,}000 = 2{,}500$ dari 10,000, B berbobot 10,000 — sehingga A mengambil $2{,}500 / 12{,}500 = 20$ % dari order. Pembagian itu mengungguli pool tunggal terbaik sebesar 0.476 token, yaitu 48.9 bps darinya. Gerbang pembagian kemudian menanyakan apakah keuntungan itu sepadan dengan leg keduanya: ambangnya adalah $97.275 \times (1 + 25 / 10^{6}) = 97.278$, dan 97.751 melampauinya, sehingga pembagian dipertahankan. Setiap baris dapat diperiksa dengan kalkulator, dan efeknya berlipat: dampak harga adalah respons setiap pool terhadap irisan *miliknya sendiri*, sehingga setiap leg yang dapat diterima yang ditambahkan ke sebuah rute menggerakkan setiap pool lebih sedikit.  ### §10.1 Bentuk rute dan anggaran Solver membangun tiga topologi dan mengembalikan yang memaksimalkan (`findBestRoutePlan`, dengan peringkat kedua sebagai cadangan): rute *langsung* dalam satu hop; rute *jembatan* melalui satu perantara; rute *jembatan ganda* melalui dua — tiga hop, bentuk terdalam yang dibangun Solver dan jumlah terbanyak yang diterima Router (`MAX_HOPS = 3`). Setiap hop terbagi ke beberapa leg paralel di bawah dua anggaran yang sengaja dipisahkan: `MAX_LEGS_PER_STAGE = 4` menjawab *berapa banyak leg yang muat dalam satu hop*, `MAX_LEGS = 11` menjawab *berapa banyak yang muat dalam satu rute*, dan bersama-sama keduanya menghasilkan 4, 4 + 4, dan 4 + 4 + 3 — hop terakhir dari rute tiga hop mendapat tiga karena plafon global menekannya, bukan karena ada yang menulis kasus khusus. Jembatan berasal dari himpunan berisi paling banyak tiga token yang dikonfigurasi operator di Hub; Solver memperluas setiap jembatan yang dikonfigurasi dan membiarkan `totalOut` terukur yang memutuskan, per transaksi. Rute yang dampak terukurnya melebihi `MAX_ROUTE_IMPACT_BPS = 9,000` sama sekali tidak dikembalikan, dan pasangan tanpa rute yang dapat diterima menolak dengan `SolverE(5)` alih-alih mengarang sebuah rute. Router menegakkan batas lima leg per hop miliknya sendiri pada setiap rute yang dipasok pemanggil (`MAX_LEGS_PER_HOP = 5`, `RouterE(3)`). ### §10.2 Corong Untuk setiap pasangan, Solver mengumpulkan pool yang terdaftar dan, kecuali registri dalam keadaan segar (§9.4), pool yang ditemukan; menyingkirkan setiap pool yang hook-nya mengubah delta (proyektor Ξ, diterapkan di sini agar pintu terencana tidak pernah dapat merakit rute yang akan ditolak Router); memeringkat gabungannya berdasarkan Ψ dalam satu panggilan batch dan mempertahankan `MAX_CANDIDATES = 8` — sengaja lebih lebar daripada anggaran leg hop mana pun, sehingga pool dalam yang tercantum di belakang beberapa venue tipis tetap terlihat, ditimbang, dan dapat menggeser venue-venue itu alih-alih tersisih karena urutan daftar. Seri yang persis dalam Ψ dipecahkan ke arah biaya yang lebih rendah, sehingga pada registri yang dingin corong merupakan fungsi dari harga, bukan dari riwayat. Setiap kandidat kemudian diuji (probe) satu kali, pada seperseratus order (`amountIn / 100`, atau seluruh order jika hasil itu dibulatkan ke bawah menjadi nol), dengan menangkap laju marginal dan kedalamannya dalam panggilan yang sama. Laju marginal memisahkan dengan bersih dua sinyal yang dicampuradukkan oleh laju ukuran penuh: pool dengan harga usang memiliki laju marginal yang salah berapa pun ukurannya, sedangkan pool kecil tetapi sehat memiliki laju marginal yang benar dan sekadar output ukuran penuh yang buruk. Untuk jenis berbentuk pasangan, kedalaman yang dideklarasikan dibatasi oleh apa yang secara fisik dipegang pool dari token output, sehingga pasangan sintetis yang mendeklarasikan $3 \times 10^{30}$ sambil memegang satu token di setiap sisi ditimbang sebesar apa yang dipegangnya. ### §10.3 Pita kepercayaan Sebelum alokasi, kandidat harus dipercaya, dan kepercayaan harus dijangkarkan pada suatu kuantitas yang mahal untuk dipalsukan. Pusat pita adalah **median berbobot kedalaman** dari laju marginal para penyintas (`_depthWeightedMedian`): laju diurutkan dengan kedalamannya ikut serta, dan median adalah laju ketika setengah *massa kedalaman* telah dilewati. Titik patahnya (breakdown point) adalah 50 % dari massa — untuk menggesernya, penyerang harus melampaui kedalaman setengah likuiditas nyata pasangan tersebut — dan kedalaman yang ditimbangnya adalah `getReserves` untuk pool cadangan, likuiditas aktif untuk pool terkonsentrasi, dan likuiditas terukur untuk V4: kuantitas yang tidak digerakkan oleh donasi biasa ke sebuah pool. Sifat terakhir itulah alasan jangkar tersebut bukan saldo nyata terbesar: transfer ke sebuah pool menggelembungkan `balanceOf` tanpa menggerakkan cadangan atau harga dan dapat dipulihkan oleh donatur, sehingga itu bukan modal yang dipertaruhkan — seorang peneliti eksternal mendemonstrasikan bahwa jangkar saldo sebelumnya dapat direbut melalui donasi, dan jangkar itu pun diganti. Kandidat yang laju marginalnya menyimpang dari pusat lebih dari `MEDIAN_FILTER_BPS = 500` (±5 %) dibuang sebelum apa pun dikirim; himpunan kandidat berisi satu sama sekali tidak difilter, dan himpunan yang pusatnya terbulatkan menjadi nol kembali ke median biasa agar hop yang sebenarnya dapat dirutekan tidak dimatikan oleh artefak pembulatan. Lebarnya adalah pilihan yang terkalibrasi: kurva stabil Solidly yang mengkuotasi pasangan liquid-staking biasanya berada 20–40 % dari laju sebenarnya dan dikecualikan; pool sehat yang pembacaannya untuk ukuran transaksi ini sedikit berbeda dari pusat tetap diterima. Jalur metamorfik pada §15 mengukur pita dari luar: dengan satu pool diberi harga $10^{10}$ jauh dari saudaranya, rencana membayar 35 % lebih sedikit daripada pencilan itu sendiri — median menolak memercayainya. ### §10.4 Alokator dan tiga penjaganya Bobot sebanding dengan kedalaman terukur, dinormalisasi terhadap kedalaman terbesar dalam himpunan (`_weights`) — satu normalisasi, tanpa mode, karena kedalaman setiap keluarga berdenominasi token (§4.2) dan oleh karena itu dapat dibandingkan. Alokasi proporsional adalah pilihan yang tangguh untuk lingkungan yang adversarial: ia tidak memerlukan iterasi maupun model kelengkungan per venue, dan ia menghindari kegagalan katastrofik yang dihasilkan oleh pembagian seragam — dalam satu kasus WETH/USDC yang diukur, membagi 50 / 50 ke pool 790-WETH dan pool debu 0.34-WETH menghasilkan 1,302 USDC, sedangkan memusatkan pada pool yang dalam menghasilkan 1,638; alokasi berbobot kedalaman menghasilkan 1,638. Ketika corong menampung lebih banyak penyintas daripada anggaran hop, penyintas teratas sebanyak anggaran *menurut bobot* yang dipertahankan, sehingga pool dalam yang tercantum belakangan menggeser pool tipis yang tercantum lebih awal. Tiga penjaga kemudian berdiri di antara alokasi dan rute yang dibentuknya. - **Penjepit kapasitas.** Rumus likuiditas terkonsentrasi satu-tick memodelkan likuiditas tick saat ini seolah-olah membentang di setiap harga, sehingga pada pool yang tipis rumus itu dapat menjanjikan lebih banyak daripada yang pernah dipegang pool — 117× lebih banyak dalam satu kasus yang teramati. Oleh karena itu, leg terkonsentrasi pada venue berbentuk pool (jenis 1 dan 6) dijepit pada `MAX_CONC_DRAIN_BPS = 3,000` — 30 % — dari saldo token output nyata pool yang *terukur*. Penjepit ini tidak menjangkau leg V4: singleton memegang token semua pool dalam satu saldo, sehingga Solver melewati pembacaan untuk jenis 4 dan 8 dan janji V4 tidak membawa batas fisik apa pun selain lantai pada §11.3 — lantai itulah batasnya. Penjepit ini bertingkat dua: ketika kuotasi melebihi seluruh kepemilikan pool, janji tersebut mustahil secara fisik, dan penjepit memotong *input yang dikomitmenkan* leg dengan rasio yang sama, mengalirkan input yang dibebaskan ke leg-leg yang tersisa dan membiarkan apa pun yang tidak dapat dirutekan disapu kembali ke pemanggil; ketika pengisian agresif tetapi mungkin, hanya janjinya yang dibatasi, karena memotong modal di sana terukur memaksa pengisian parsial pada pool yang sebenarnya dieksekusi dengan baik. Rumus yang dibatasi cadangan tidak dapat menjanjikan berlebihan dan tidak disentuh. Penjepit ini sengaja membaca `balanceOf` di tempat pita tidak melakukannya: pita mengajukan pertanyaan *relatif* yang dapat dicondongkan oleh donasi, penjepit mengajukan pertanyaan *fisik* — dapatkah pool ini membayar sebesar ini? — dan donasi memang menaikkan apa yang benar-benar dapat dibayar pool. - **Gerbang pembagian.** Setiap leg tambahan memakan gas nyata, dan alokator sengaja tidak memuat suku harga gas, karena membandingkan gas dalam token native dengan output dalam token transaksi akan memerlukan persis oracle harga yang ditolak oleh protokol. Proksi tanpa oracle-nya adalah sebuah ambang: pembagian dipertahankan hanya jika $\mathrm{out}_{\mathrm{split}} \ge \mathrm{out}_{\mathrm{single}} \cdot (1 + 25/10^{6})$ — `MIN_SPLIT_IMPROVEMENT_PPM = 25` — jika tidak, alokasi runtuh menjadi satu leg. Ambang itu adalah angka terukur: titik impas sebenarnya antara gas sebuah leg dan perbaikannya terukur 3 ppm di Base (320 byte calldata per leg tambahan pada 105.5 gas per byte), dan gerbang ditempatkan sekitar delapan kali nilai itu, berdenominasi part per million karena seperempat basis poin tidak ada dalam satuan basis poin; riwayatnya — 20 bps, lalu 5, lalu 0.25 — adalah catatan dari dua nilai yang belum pernah dikalibrasi terhadap pengukuran. Ketika gerbang meruntuhkan sebuah rute, ia mengukur dua kandidat satu-leg pada ukuran penuh, bukan satu — pool terdalam dan laju marginal terbaik — karena laju marginal menyanjung pool dangkal sedangkan kedalaman adalah proksi untuk menanggung seluruh ukuran; pengisian yang lebih baik menang. - **Asuransi melalui pengukuran, bukan melalui margin.** Desain sebelumnya memangkas setiap leg dari rute yang lebih panjang sebesar 5 bps pada waktu perencanaan sebagai asuransi terhadap drift antar-leg. Drift itu kemudian diukur pada sembilan pasangan Base dalam blok yang sama: kasus terburuk −2 bps, satu orde besaran di bawah asuransi tersebut, yang dibayar oleh setiap rute multi-leg yang jujur pada setiap transaksi — 27× bahaya terukurnya. Pemangkasan itu dipensiunkan; lantai-lantai, yang ditegakkan pada output yang terealisasi, menanggung risiko itu tanpa biaya perencanaan. Pengukuran diambil dalam jendela yang tenang dan argumen tandingannya tercatat di dalam kode sumber: jika konservatisme suatu saat dipulihkan, tempat yang tepat adalah lantai, yang diperiksa, dan bukan estimasi, yang hanya memeringkat. Rute yang dirakit membawa apa yang akan diturunkan ulang oleh Router: input yang dikomitmenkan dan output yang diharapkan dari setiap leg, dampak rute berbobot porsi, dan lantai Φ yang diatestasi Solver dari aritmetika yang sama yang ditegakkan Router (§11). Solver juga menaksir biaya eksekusi setiap leg menurut jenisnya dari tangga `THETA_GAS` dan memublikasikan totalnya sebagai `estGas`, sebuah angka anjuran yang dibawa rute dan tidak dibaca oleh apa pun di on-chain. Patokan praktis bagi pembaca tetap berlaku tanpa perubahan melewati seluruh mesin ini: bandingkan perbaikan yang diklaim router dengan gas yang ditampilkan dompet Anda, sebelum Anda mengonfirmasi. ## §11 Lapisan eksekusi dan lantai Iron-Law Φ Solver mengusulkan; Router yang memutuskan — secara atomik, atau tidak sama sekali. Router adalah satu-satunya kontrak yang memindahkan dana, tidak memegang dana apa pun di antara transaksi, dan dibangun di atas satu prinsip: satu mekanisme per persoalan, diterapkan secara universal. Router tidak mengasumsikan apa pun yang dapat diukurnya. ### §11.1 Empat pintu, satu eksekutor | Pintu | Signature (diringkas) | Otorisasi | Rute | |---|---|---|---| | `swapExactIn` | `(route, amountIn, userMinOut, recipient, deadline)` | `approve` + `transferFrom` klasik | dari calldata | | `swapExactInWithPermit2` | `(route, amountIn, userMinOut, recipient, deadline, permit, signature)` | transfer tanda tangan Permit2 satu langkah melalui kontrak Permit2 kanonis; tanpa allowance tetap kepada Router | dari calldata | | `swapExactInNative` | `(route, userMinOut, recipient, deadline)` payable | nilai native, dibungkus sekali di pintu; fail-closed sampai `weth` dihubungkan (`RouterE(3)`) | dari calldata | | `swapBestExactIn` | `(tokenIn, tokenOut, amountIn, userMinOut, recipient, deadline)` | klasik | diselesaikan di dalam frame oleh Solver (`findBestRoutePlan`), lalu dieksekusi melalui self-call dengan pembayar diteruskan secara eksplisit | Hanya `swapBestExactIn` yang memanggil Solver di dalam transaksi; tiga pintu lainnya mengambil rute yang dihitung pemanggil secara off-chain, secara gratis, melalui Quoter (§12). Keempatnya bertemu pada satu eksekutor privat (`_execute`), sehingga setiap pemeriksaan di bawah berjalan di setiap pintu. Akun terdelegasi EIP-7702 memanggil pintu yang sama seperti halnya sebuah kontrak; tidak ada jalan masuk terpisah untuknya. Dua penolakan berjalan sebelum apa pun bergerak. Minimum nol ditolak di setiap pintu — `RouterE(10)`, tanpa pengecualian, tanpa flag kompatibilitas — karena minimum adalah satu-satunya batas yang tidak dapat dihitung kontrak atas nama pengguna, dan penjaga yang boleh tidak ada bukanlah penjaga. Dan rute dengan lebih dari tiga hop, lebih dari lima leg dalam satu hop, atau hop yang token inputnya bukan output hop sebelumnya ditolak dengan `RouterE(3)`: kesinambungan hop itulah yang membuat saldo "asing" pra-swap dari setiap token perantara diketahui, sehingga rute rekaan tidak dapat menyebut token yang terdampar sebagai inputnya dan menskalakan seluruh saldo Router atas token itu ke dalam swap. ### §11.2 Pengukuran, sejak instruksi pertama Pintu mana pun yang digunakan, hal pertama yang dilakukan Router adalah mengukur apa yang tiba: Router membaca delta saldonya sendiri setelah penarikan alih-alih memercayai jumlah nominal, sehingga token yang mengirim kurang saat transfer masuk ke rute dengan ukuran sebenarnya. Baseline lahir sekali: saldo pra-swap token input (`baseIn`) dan saldo token output (`toutStart`) diambil saat masuk, dan setiap pengukuran berikutnya adalah delta terhadap keduanya, sehingga token yang sudah berada di dalam kontrak — debu, donasi, token terdampar dari riwayat yang tidak terkait — dikecualikan dari apa yang dapat dibayarkan oleh sebuah swap. Rute yang berhasil membelanjakan di bawah baseline-nya sendiri gagal pada aritmetika terperiksa (checked arithmetic) — hasil yang aman, karena dana itu memang tidak pernah menjadi hak swap ini untuk dibelanjakan. Rute multi-hop adalah sebuah rencana, dan rencana bertemu kenyataan di setiap batas hop. Router menskalakan ulang leg setiap hop terhadap saldo yang *benar-benar* tiba — hop 0 terhadap input pasca-penarikan yang terukur, dibatasi oleh apa yang dikomitmenkan rute (sehingga Router tidak pernah memaksakan order yang telah dipotong sebelumnya ke dalam pool yang tipis); setiap hop berikutnya terhadap saldo jembatan terukur di atas baseline asingnya — dengan setiap leg mengeksekusi $\mathrm{amt} = \mathrm{amountIn}_{\mathrm{leg}} \cdot \mathrm{real}/\mathrm{planned}$ (`_hopScaleImpactAndQuote`). Leg yang diskalakan menjadi nol dilewati; input yang tidak terpakai dan residu jembatan disapu kembali ke pembayar, tidak pernah ke Router. Lintasan yang sama membaca state pool setiap leg sekali dan menghasilkan, dari satu pembacaan itu, jumlah leg yang telah diskalakan, dampak terukurnya, dan kuotasi di dalam frame-nya — tiga kuantitas yang dikonsumsi oleh lantai — sehingga keluarga cadangan dan terkonsentrasi tidak membayar `staticcall` tambahan untuk pengukurannya. ### §11.3 Tiga lantai di bawah setiap leg **Lantai per leg.** Kontribusi terukur setiap leg terhadap saldo output Router harus mencapai `LEG_FLOOR_BPS = 8,000` — 80 % — dari batasnya, atau seluruh swap melakukan revert dengan `RouterE(5)` (`_execScaled`), sehingga satu pool yang terkena sandwich atau dimanipulasi menggagalkan transaksi seketika alih-alih menyembunyikan kerugiannya di dalam total yang sebenarnya sehat. Batasnya adalah kuotasi yang diatestasi pemanggil, pro-rata terhadap jumlah yang benar-benar dibelanjakan — *diangkat* ke kuotasi yang diukur di dalam frame setiap kali atestasi mencakup kurang dari `MIN_QUOTE_COVERAGE_BPS = 5,000` darinya. Itu adalah maksimum, bukan minimum, dengan sengaja: pada sebuah lantai, `min(claimed, measured)` dengan klaim yang dikempiskan mengembalikan klaim yang dikempiskan itu dan melonggar, dan itulah serangan yang ditutup oleh gerbang ini. Penjaga berjalan setiap kali ada basis lantai apa pun — atestasi pemanggil atau kuotasi di dalam frame — sehingga menulis nol ke dalam rute tidak lagi mematikan lantai milik pemanggil sendiri. Batasannya: venue tanpa kuotasi yang dapat diukur dan tanpa atestasi jatuh ke lantai agregat dan minimum pengguna, yang tetap membatasinya. **Lantai agregat per hop.** Lantai per leg bersifat lokal sedangkan komposisi bersifat global: penyerang yang memegang satu leg dari $L$ dapat mengekstraksi sekitar $20\,\% \cdot (L-1)/L$ dari sebuah hop tanpa menggagalkan satu lantai pun. Jadi setiap hop boleh kehilangan paling banyak apa yang dapat hilang secara sah dari satu leg teratestasi *rata-rata*: $\sum \mathrm{got} + \lfloor (\mathrm{BPS} - \mathrm{LEG\_FLOOR\_BPS}) \cdot \lfloor \sum \mathrm{attested} / n \rfloor / \mathrm{BPS} \rfloor \ \ge\ \sum \mathrm{attested}$ — kelonggarannya adalah 20 % dari leg teratestasi rata-rata, jika tidak `RouterE(5)`. Rata-rata dan bukan maksimum, karena di bawah maksimum penyerang menggelembungkan leg-nya sendiri untuk menggelembungkan anggaran bersama. Untuk satu leg aturan ini runtuh tepat menjadi lantai per leg — nol kekakuan baru, secara konstruksi. **Lantai rute Φ** dibahas pada §11.5. ### §11.4 Satu callback, satu unlock Setiap venue berbentuk V3 — Uniswap V3, Algebra, fork Solidly terkonsentrasi, Pancake V3, Sushi V3 — menggunakan pola flash-accounting yang sama di bawah nama callback yang berbeda: pool memanggil balik di tengah swap dengan delta untuk token0, delta untuk token1, dan data arbitrer, sambil menuntut pembayaran. Alih-alih satu callback bernama per fork, Router mengekspos satu `fallback` yang menjawab semuanya — **Doktrin Satu Callback**: ia membaca kedua delta, mengidentifikasi token mana yang terutang dari tanda keduanya, dan membayar tepat sejumlah itu, dengan mengambil konteks leg yang sedang berjalan dari transient storage (`TSLOT_POOL`, `TSLOT_TOKEN`, `TSLOT_AMT`). Karena fallback dapat dijangkau oleh siapa pun, ia dijaga pada tiga sisi: ia hanya membayar pool yang dikomitmenkan untuk leg saat ini, ia menolak bertindak ketika tidak ada leg yang sedang berjalan (konteks transien bernilai nol di antara swap), dan ia tidak pernah melepaskan lebih dari anggaran tercatat leg tersebut — tuntutan kedua dalam satu leg ditolak dengan `RouterE(6)`. Fork V3 yang baru diluncurkan dengan nama callback yang baru sudah didukung sejak hari ia di-deploy. Singleton V4 dibungkus di balik antarmuka hop yang sama: `unlock`, lalu swap, `sync → settle → take`, kunci ulang, dengan currency dibawa dalam transient storage dan sambungan native pada §5.3. Sebelum leg V4 mana pun dieksekusi, Router membaca alamat hook dan menolak leg tersebut jika bit-bitnya mendeklarasikan izin yang mengubah delta (`RouterE(9)`); hook yang disaring adalah hook yang dieksekusi, karena PoolManager kanonis menggemakan data unlock secara verbatim (`test/V4SievedHookIsTheExecutedHook.t.sol`). Aturan bentuk rute adalah urutan kanonis, di seluruh rute: begitu leg ber-hook telah dieksekusi, tidak ada leg tanpa hook yang dieksekusi setelahnya di hop ini atau hop berikutnya mana pun (`sawHooked`), sehingga hook tidak dapat mengamati leg tanpa hook yang lebih belakang dari rute yang sama sebelum leg itu diselesaikan; leg ber-hook boleh berada di hop yang lebih awal hanya jika setiap leg setelahnya juga ber-hook. **Fee-on-transfer, pada leg yang mampu menanggungnya.** Sebagian token mengirim kurang pada setiap transfer. Pada leg constant-product, Router menangani hal ini dengan pola kanonis — transfer terlebih dahulu, kemudian baca cadangan pool dan saldonya dalam state pasca-transfer yang sama, dan beri harga output berdasarkan selisih yang benar-benar dilihat pool — sebuah kuantitas yang benar secara konstruksi, karena itulah persis kuantitas yang akan diperiksa oleh invarian pool itu sendiri. Cabang ini aktif hanya ketika sebuah token terukur kurang (`TSLOT_FOT`), dan konsekuensi pengaktifannya dinyatakan bersamanya: lantai rute yang diturunkan dari kuotasi dihitung tanpa mengetahui pajak tersebut dan dibuang untuk swap itu; lantai protokol diskalakan ulang dengan rasio bersih terukur (dibulatkan ke atas, arah yang konservatif); batas per leg diberi harga ulang dengan rasio yang sama; dan minimum pengguna menjadi kendala yang mengikat. Leg terkonsentrasi tidak mendukung fee-on-transfer secara desain — flash accounting harus membayar tepat apa yang terutang — sehingga token berpajak pada rute khusus V3 ditolak di awal dengan `RouterE(13)` alih-alih melakukan revert di dalam sebuah pool. ### §11.5 Lantai Iron-Law Φ, secara lengkap Tidak setiap rute yang dapat dieksekusi layak dieksekusi — rute yang mengembalikan 60 % dari nilai wajar lebih buruk daripada tidak bertransaksi sama sekali — sehingga di bawah semua hal di atas terdapat lantai yang diturunkan protokol untuk dirinya sendiri. Lantai itu adalah fraksi retensi dalam basis poin (Core `ironFloorBpsShv`, `legShaveBps`): $$ \mathtt{floorBps} \;=\; \max\!\left(\;9{,}600 - \mathtt{legShv} - \min(\delta,\, 10^{4}) - \sigma_{\ln}/10^{14},\;\; 8{,}000\;\right) $$ ^e15 $$ \mathtt{legShv} \;=\; \sum_{\mathrm{hops}} \left\lfloor 200 \cdot \frac{(\sum_{i} a_{i})^{2} - \sum_{i} a_{i}^{2}}{\sum_{i} a_{i}^{2}} \right\rfloor \;=\; \sum_{\mathrm{hops}} \left\lfloor 200\,(n_{\mathrm{eff}} - 1) \right\rfloor $$ ^e23 Tiga konstanta menentukannya: `FLOOR_BASE_BPS = 9,600`, `FLOOR_PER_LEG_BPS = 200`, `FLOOR_HARD_MAX_LOSS_BPS = 2,000`. Lantai dimulai pada 96 % untuk swap satu leg yang bersih, melonggar satu basis poin per basis poin dampak terukur $\delta$ dan 200 bps per leg tambahan yang *efektif*, dan dijepit sehingga tidak pernah jatuh di bawah 8,000 bps: protokol tidak akan pernah dengan sadar menerima rute yang mempertahankan kurang dari 80 % dari referensinya, apa pun inputnya. Pemangkasan leg dihitung dari *konsentrasi* transaksi di seluruh leg — $(\sum a)^{2}/\sum a^{2}$, jumlah leg efektif, tepat $N$ untuk $N$ porsi yang sama dan tepat 1 untuk satu leg dominan — sehingga sebuah pembagian memperoleh pelonggaran sebanding dengan seberapa sungguh-sungguh ia terbagi, dan leg yang membawa porsi yang nyaris hilang memperoleh jumlah yang nyaris hilang, baik ia mendeklarasikan nol maupun satu wei. Menurut Cauchy–Schwarz, pembilangnya tidak pernah underflow. Suku dampak adalah rata-rata berbobot porsi dari dampak terukur para leg di sepanjang rute. Dua sifat dicetak sebagai bagian dari definisi: suku volatilitas $\sigma_{\ln}$ ada dalam signature dan diteruskan sebagai nol literal di setiap lokasi pemanggilan — sebuah hook untuk estimator di masa depan, saat ini tidak aktif — dan dampak keluarga cadangan tidak mencakup biaya sedangkan dampak keluarga terkonsentrasi mencakup biaya, masing-masing dalam bentuk yang diberikan oleh spesifikasi keluarganya. Yang menjadikan Φ sebuah penegakan alih-alih heuristik adalah di mana dan atas apa ia dijalankan. Rute yang diserahkan kepada Router membawa bidang-bidang anjuran — total yang dikuotasi, lantai yang diatestasi — dan Router tidak memercayai keduanya: di dalam frame eksekusi ia mengukur dampak nyata setiap leg, menghitung pemangkasan leg dari jumlah yang diserahkan kepadanya, menghitung ulang `floorBps`, dan menerapkannya pada **kuotasi di dalam frame dari hop terakhir pada jumlah yang benar-benar tiba di sana** — sebuah referensi berdenominasi token output, diturunkan dari state pool yang dibaca selama eksekusi ini, tidak dapat dipalsukan melalui calldata. Pilihan referensi itulah yang memungkinkan penjaga ini terpicu sama sekali: sebuah fraksi dari output yang *terealisasi* tidak pernah dapat melebihi output yang terealisasi. Ketika hop terakhir tidak dapat dikuotasi di dalam frame — celah likuiditas pada tick saat ini, sentinel biaya — referensi kembali ke kuotasi yang diatestasi untuk hop tersebut, yang telah diangkat oleh gerbang cakupan dan diberi harga ulang oleh pengukuran fee-on-transfer, sehingga celah likuiditas just-in-time (JIT) pada pool yang tipis tidak dapat melumpuhkan lantai; jangkar lantai selalu merupakan hop yang memindahkan nilai dan menghasilkan output rute. Pemeriksaan berjalan pada output bruto, sebelum biaya sisi output apa pun. Minimum efektif adalah maksimum tiga arah, $$ \mathtt{effMin} \;=\; \max\!\left(\mathtt{userMinOut},\;\; \mathtt{route.singleOutFloor},\;\; \left\lceil \mathtt{finalHopQuote} \cdot \mathtt{floorBps}/10^{4} \right\rceil\right) $$ ^e16 dan asimetrinya itulah intinya: bidang yang dipasok pemanggil dapat memperketat perlindungan dan tidak pernah dapat melonggarkannya. Solver mengatestasi `singleOutFloor` dari `legShaveBps` dan `ironFloorBpsShv` yang sama pada jumlah yang sama, sehingga untuk rute yang dibangun Solver, lantai yang diatestasi dan lantai yang ditegakkan sesuai secara konstruksi (`test/FloorParitySolverRouter.t.sol`), dan harness rezim pada §15 mengunci kedua frame pada setiap baris yang dihasilkan: dengan biaya diambil dari input, lantai yang ditegakkan berada dalam $[\mathrm{attested} \times (1 - \mathrm{fee}),\ \mathrm{attested}]$; dengan biaya diambil dari output, lantai itu sama dengan lantai yang diatestasi.  **Contoh terhitung 3 — lantai pada rute dua hop.** Sebuah rute A → WETH → B: hop 0 membagi 600 A ke pool P dan 400 A ke pool Q; hop 1 mengirim WETH yang dihasilkan melalui satu pool R. Terukur di dalam frame: leg-leg hop 0 menunjukkan dampak 100 dan 60 bps, leg hop 1 40 bps, dan rata-rata berbobot porsi di sepanjang rute adalah 80 bps. Kuotasi di dalam frame hop 1 pada jumlah WETH yang benar-benar tiba adalah 1,000.000 B. 1. Konsentrasi hop 0: $(600 + 400)^{2} = 1{,}000{,}000$; $600^{2} + 400^{2} = 520{,}000$; $n_{\mathrm{eff}} = 1.923$; pemangkasan $= \lfloor 200 \times 480{,}000 / 520{,}000 \rfloor = \lfloor 184.6 \rfloor = 184$ bps. 2. Hop 1 memiliki satu leg: $(\sum a)^{2} - \sum a^{2} = 0$; pemangkasan 0. Total `legShv` = 184. 3. $\mathtt{floorBps} = \max(9{,}600 - 184 - 80 - 0,\ 8{,}000) = 9{,}336$: rute harus mempertahankan 93.36 % dari referensinya. 4. $\mathtt{protocolFloorOut} = \lceil 1{,}000.000 \times 9{,}336 / 10{,}000 \rceil = 933.600$ B. 5. Dengan `userMinOut` = 990 B yang ditetapkan oleh trader dan `singleOutFloor` = 933.6 B yang diatestasi oleh Solver, `effMin` = 990 B — batas milik pengguna sendirilah yang mengikat, sebagaimana mestinya pada rute yang jujur. Pengiriman sebesar 998.4 B diselesaikan; pengiriman sebesar 985 B ditolak dengan `RouterE(5)`, dan seluruh transaksi, termasuk swap di setiap pool, tidak pernah terjadi. Seandainya trader menetapkan `userMinOut` = 900 B, lantai protokol akan mengikat pada 933.6 B: pengisian pada 930 B, 7 % di bawah referensi di dalam frame, ditolak meskipun melampaui angka milik pengguna. ### §11.6 Penyelesaian (settlement), dan cara membacanya Penyelesaian menutup frame dengan cara yang sama seperti ia dibuka: melalui pengukuran. Router mengambil delta token outputnya terhadap baseline saat masuk sebagai output bruto (`RouterE(8)` jika nilainya nol), menjalankan pemeriksaan lantai di atas, membebankan biaya di tempat yang ditentukan rezim (§13), mentransfer jumlah bersih kepada penerima dan mengukur delta saldo *penerima*, menegakkan `userMinOut` pada jumlah yang dikirimkan itu — sehingga token output fee-on-transfer tidak dapat membuat pengguna tergelincir di bawah batasnya — dan membaca buku besar biaya sekali: penyelesaian yang tidak membayar apa pun kepada protokol ditolak (`RouterE(15)`), dan pada rute berjangkar pembayaran kedua ditolak (`RouterE(16)`). Kemudian, dan hanya pada jalur sukses, Router memanggil `recordSwap` milik Hub sekali per leg yang dieksekusi (`_recordHits`) dengan jumlah yang mampu dibelanjakan hop tersebut — rasio terukur-terhadap-dideklarasikan diterapkan pada setiap leg — yang merupakan satu-satunya penulisan eksternal yang dilakukan sebuah swap; tidak ada yang ditulis ketika lantai menolak. Setiap penyelesaian memancarkan `ExecutionProof(user, tokenOut, quoted, realized, floorUsed, blockNumber)`: kuotasi referensi yang dihasilkan dalam frame yang sama dengan eksekusi, dipublikasikan sebagai deret on-chain yang dapat diturunkan ulang oleh siapa pun melalui `eth_call` ke `findBestRoutePlan` pada blok tersebut. Bidang-bidangnya, tanpa klaim berlebihan: `user` adalah pembayar, tidak pernah `msg.sender`; `quoted` adalah kuotasi hop terakhir — ia membuktikan hop terakhir, bukan rute; `realized` adalah apa yang dikirimkan, diukur pada penerima; `floorUsed` adalah lantai protokol yang harus dilampaui. Setiap event `Fee(token, amount, toT1, toT2)` menyebutkan token dan pembagiannya. **Contoh terhitung 6 — membaca sebuah penyelesaian.** Rute dari Contoh 3 diselesaikan dan memancarkan `ExecutionProof(0xUSER, B, 1,000.000, 998.400, 933.600, N)` dan satu `Fee(WETH, 0.014, 0.0042, 0.0098)`. | Kuantitas | Nilai | Pembacaan | |---|---|---| | `quoted` | 1,000.000 B | kuotasi di dalam frame dari hop terakhir pada WETH yang benar-benar tiba | | `realized` | 998.400 B | dikirimkan kepada penerima, diukur di sana; 9,984 bps dari kuotasi | | `floorUsed` | 933.600 B | `floorBps` 9,336 diterapkan pada kuotasi; pengisian berada 64.8 B di atasnya | | `Fee` | 0.014 WETH dalam satu event | rezim berjangkar: 28 bps dari 5.000 WETH yang dihasilkan hop 0, dibayar pada input hop 1, 30 % ke treasury pertama; tidak ada yang diambil dari B | | jarak ke `userMinOut` | 8.4 B | batas 990 B milik pengguna menyisakan kelonggaran 0.84 % | Selisih antara yang dikirimkan dan yang dikuotasi adalah jawaban pasar, bukan jawaban protokol: biaya telah keluar lebih awal, dalam WETH, dan tidak ada potongan sisi output pada rute ini. Event `Fee` yang berdenominasi token output hanya muncul pada rute langsung menuju koin jembatan (§13). ### §11.7 Penolakan oleh Router | Kode | Arti | Lokasi | |---|---|---| | `RouterE(1)` | panggilan kendali yang tidak berwenang | `onlyControl` | | `RouterE(2)` | dijeda, atau pelepasan kendali dicoba saat dijeda | `whenLive`, `renounceControl` | | `RouterE(3)` | input buruk — alamat nol, pintu native yang belum dihubungkan, jumlah hop, leg per hop, diskontinuitas hop | titik masuk, `_execute` | | `RouterE(4)` | tenggat telah lewat | titik masuk | | `RouterE(5)` | output di bawah sebuah lantai — per leg, agregat per hop, lantai rute, atau `userMinOut` | `_execScaled`, `_execute` | | `RouterE(6)` | callback tidak berwenang — pool yang salah, tidak ada leg yang sedang berjalan, tuntutan kedua | `fallback` | | `RouterE(7)` | re-entrancy | `nrEntrant` (kunci transien) | | `RouterE(8)` | swap gagal — output nol, jenis tidak dikenal, biaya sama dengan atau di atas jumlahnya | `_execute`, `_execScaled`, `_chargeHopFee` | | `RouterE(9)` | hook V4 mengubah delta | pra-komitmen leg V4 | | `RouterE(10)` | `userMinOut == 0` dengan `amountIn > 0` | setiap pintu | | `RouterE(13)` | token fee-on-transfer pada rute yang khusus terkonsentrasi | `_execute` | | `RouterE(14)` | rescue belum diantrekan atau masih di dalam penundaan 48 jamnya | `executeRescue` | | `RouterE(15)` | diselesaikan tanpa membayar biaya protokol | buku besar biaya, akhir `_execute` | | `RouterE(16)` | biaya dibayar dua kali pada rute berjangkar | buku besar biaya, akhir `_execute` | Kode 11 dan 12 tidak ditetapkan. Permukaan revert yang dapat dienumerasi selengkap API itulah yang memungkinkan larik rezim pada §15 menilai setiap baris dengan satu aturan — selesaikan, atau tolak dengan selector milik kami — dan menyebut apa pun selain itu sebagai jalan ketiga. ## §12 Permukaan kuotasi, dan bagaimana sebuah kuotasi menua Ada dua tempat asal sebuah angka yang disebut "kuotasi Anda", dan keduanya adalah jalur kode yang berbeda: **Quoter**, kontrak pratinjau baca-saja yang dipanggil antarmuka sebelum Anda menandatangani, dan **jalur dalam-frame**, tempat Solver dan Router menghitung kuotasi di dalam transaksi yang sedang dieksekusi. §4.4 memberikan kebenaran per jenis; bagian ini memberikan permukaannya dan mengukur selisih di antara keduanya. ### §12.1 Permukaan Quoter | Fungsi | Mengembalikan | Catatan | |---|---|---| | `previewPlan(tIn, tOut, amountIn)` | sebuah `Preview` | rencana Solver, dikemas bersama biaya (fee) dan penyangga keamanan | | `previewPlanWithMinOut(…, userMinOut)` | sebuah `Preview` | sama, dengan `canExecute` dinilai terhadap minimum pemanggil | | `previewAndEncode(…)` / `previewAndEncodeWithMinOut(…)` | sebuah `Preview` dan calldata untuk `swapExactIn` | cara integrator mengambil kuotasi — studi §12.2 menggunakan persis cara ini | | `batchQuote(entries[])` | hingga `MAX_BATCH = 32` pratinjau | pasangan yang tidak dapat direncanakan meninggalkan entri berinisialisasi nol | | `previewPlanExact(tIn, tOut, amountIn)` | rute dan output bersih yang eksak | Exact Pass: setiap leg terkonsentrasi diuji-coba (dry run) terhadap swap milik pool itu sendiri | **Apa itu pratinjau.** Struct `Preview` bersifat anjuran menurut desainnya — pemeriksaan yang mengikat adalah pemeriksaan yang diturunkan ulang oleh Router di dalam frame — dan field-nya didokumentasikan di lokasi definisinya: `grossOut` menggemakan total rencana; `protocolFee` adalah efek biaya terhadap output, dimodelkan per rezim persis seperti Router membebankannya (§13) — sekali pada rute berjangkar, sekali per hop pada rute yang habis dicoba, dibulatkan ke atas sebagaimana Router membulatkan; `safetyBuffer` adalah penyangga antar-leg $$ s \;=\; \min\!\left(\max(0,\, n-2) + 5a,\;\; 10\right)\ \text{bps} $$ ^e21 nol pada dua leg atau kurang, satu basis poin per leg di atas dua, ditambah lima untuk setiap leg constant-product yang dihargai dengan biaya yang *diasumsikan* (biaya terdeklarasi yang diganti oleh Core di bawah plafonnya), di bawah satu batas bersama sebesar sepuluh, karena penyangga tanpa plafon berhenti menjadi penyangga dan menjadi lantai; `netOut` adalah $\mathrm{grossOut} - \mathrm{protocolFee} - s$; `ironFloor` menggemakan lantai yang diatestasi; `topology` dan `bridgeUsed` diturunkan dari jumlah hop dan dari jangkar biaya yang akan digunakan Router — pemindaian yang sama atas produsen yang sama, sehingga pratinjau dan eksekutor tidak dapat menyebut koin jembatan yang berbeda. Aturan bagi integrator muat dalam satu kalimat dan merupakan nasihat paling menentukan dalam makalah ini: turunkan minimum Anda dari ekspektasi harga Anda sendiri, jangan pernah dari field pratinjau. **Exact Pass.** Untuk pratinjau eksak-pool atas venue terkonsentrasi, Quoter memanggil entri swap sungguhan milik pool; pool melakukan callback menuntut pembayaran; callback Quoter, alih-alih membayar, melakukan revert — membawa delta yang dihitung di dalam payload revert. Revert itu membatalkan seluruh state, tidak ada yang dibayar, dan output yang didekode adalah swap milik venue itu sendiri atas state langsung, dijalankan lalu dibatalkan; V4 ditangani secara identik melalui unlock yang callback-nya melakukan revert dengan delta yang dikemas. Pool yang menolak uji coba mempertahankan klaim rencana itu sendiri yang diskalakan oleh tali busur di bawahnya — tidak pernah di atasnya, karena output AMM bersifat cekung. Hop 0 dibatasi pada apa yang dikomitmenkan rencana, sehingga rute yang dijepit kapasitasnya tidak diuji-coba pada ukuran yang tidak akan pernah dibelanjakan Router. Sejak 2026-09-03 skalar yang dikembalikan sudah bersih dari biaya protokol, dipotong sekali sebagaimana pratinjau memotongnya, sehingga minimum yang diturunkan darinya dihormati oleh lantai (`test/QuoterExactNetOut.t.sol`). Ini adalah instrumen sisi pratinjau milik Quoter; permukaan yang mengikat adalah penurunan ulang di dalam frame. ### §12.2 Bagaimana sebuah kuotasi menua Sebuah kuotasi adalah janji tentang blok di masa depan. Studi ini mengambilnya sebagaimana integrator melakukannya — `previewAndEncode` mengembalikan pratinjau dan calldata — membiarkan dunia bergerak (nol hingga tiga perdagangan oleh pihak lain melalui pool yang sama, masing-masing hingga 3 % dari cadangan yang dangkal, semuanya searah dengan pengguna sehingga setiap perdagangan merugikan), membiarkan nol hingga sepuluh detik berlalu, lalu mengeksekusi calldata tanpa perubahan. 240 sampel pada semesta tiga token berupa mock constant-product (A, B = koin jembatan, C; langsung ke koin jembatan, dua hop melaluinya, dua hop ke arah sebaliknya), setiap hasil diklasifikasikan (`test/QuoteDelayStatistics.t.sol`): | Pergeseran antara kuotasi dan eksekusi | Sampel | Terselesaikan | Ditolak oleh lantai (`RouterE(5)`) | Diterima / diprediksi — rata-rata | min | |---|---|---|---|---|---| | tidak ada | 64 | 64 | 0 | 10,000 bps | 10,000 | | 1 – 100 bps | 43 | 43 | 0 | 9,952 bps | 9,803 | | 100 – 300 bps | 133 | 102 | 31 | 9,966 bps | 9,653 | | Jeda antara kuotasi dan eksekusi | Sampel | Terselesaikan | Ditolak (`RouterE(5)`) | Diterima / diprediksi — rata-rata | min | |---|---|---|---|---|---| | 0 dtk | 17 | 15 | 2 | 9,989 bps | 9,857 | | 1 – 5 dtk | 99 | 89 | 10 | 9,959 bps | 9,653 | | 6 – 10 dtk | 124 | 105 | 19 | 9,983 bps | 9,659 |  Waktu tidak menggeser kuotasi; pergeseran harga yang melakukannya. Ditegaskan pada setiap sampel: kuotasi tanpa pergeseran terselesaikan pada setiap jeda dan menyerahkan persis prediksinya (64 dari 64); penyelesaian tidak pernah menyerahkan di bawah lantai yang diatestasi pratinjau; tidak ada hasil ketiga. Setelah tenggat (`deadline = now + 5`, dieksekusi pada `+10`) 20 dari 20 ditolak dengan kode milik tenggat itu sendiri, `RouterE(4)`, dan tidak satu pun terselesaikan. Di bawah pergeseran merugikan hingga 1 % setiap kuotasi masih terisi, dalam rentang 2 % dari prediksinya; di bawah 1–3 % lantai menolak satu dari empat alih-alih mengisinya di bawah output yang diatestasi, dan pengisian mendarat dalam rentang 3.5 % dari prediksi — kurva sandwich dari §14 dilihat dari sisi kuotasi. **Base langsung** (`test/fork/QuoteDelayFork.t.sol`, 1,000 USDC → WETH, pool sungguhan, protokol di-deploy pada fork di blok saat ini): dieksekusi 0, 3, 6 dan 10 dtk kemudian tanpa ada hal lain yang bergerak, kuotasi menyerahkan persis prediksinya keempat kalinya. Dengan 10,000 · 50,000 · 200,000 · 1,000,000 · 5,000,000 USDC diperdagangkan mendahuluinya melalui rute yang sama dan calldata basi dieksekusi 10 dtk kemudian, kelimanya terselesaikan di dalam lantai pada 9,999 · 9,998 · 9,994 · 9,974 · 10,000 bps dari prediksi: satu juta dolar yang mendahului seribu dolar membebani seribu dolar itu seperempat persen, dan perdagangan lima juta dirutekan melalui pool yang tidak disentuh oleh rute seribu dolar. Distribusi di atas berasal dari mock; Base langsung memberikan jangkauan pada satu pasangan di satu blok, bukan distribusi. ### §12.3 Berapa biaya sebuah kuotasi melalui ABI Gas diukur di sekitar panggilan eksternal, masing-masing empat puluh ukuran pada semesta tiga token (`test/QuoterGasStatistics.t.sol`) dan lima ukuran pada Base langsung (`test/fork/QuoterGasFork.t.sol`): | Dunia | `previewPlan` rata-rata | min | maks | σ | `previewAndEncode` rata-rata | σ | |---|---|---|---|---|---|---| | mock — penemuan: pasangan hanya dikenal oleh factory, satu pool ditemukan | 121,313 | 116,468 | 123,491 | 1,433 | 123,317 | 1,851 | | mock — registri segar: tiga pool yang disemai dihargai | 235,574 | 227,205 | 237,843 | 1,815 | 239,647 | 1,937 | | Base langsung — dingin: registri kosong, factory yang diterima disapu | 1,524,221 | | | | 1,525,341 | | | Base langsung — hangat: segar setelah satu eksekusi, dua pool terdaftar | 1,414,633 | | | | 1,416,037 | | | Base langsung — dingin lagi setelah TTL penemuan | 1,359,925 | | | | 1,361,582 | | `batchQuote` berisi sepuluh entri pada mock: 2,055,390 gas, 205,539 per entri. Mock registri segar lebih mahal daripada penemuan karena ia menghargai tiga pool sementara penemuan menemukan satu; perbandingan yang jujur adalah yang langsung, di mana sapuan penemuan sekitar 7 % dari sebuah kuotasi — dan kuotasi adalah panggilan view yang tidak pernah dibayar integrator secara on-chain. ## §13 Kebijakan biaya: dua rezim dan Aturan Surplus *Sederhana:* protokol mengambil 0.28 % satu kali, dari satu jumlah yang diukur, dalam koin yang ingin disimpan oleh perbendaharaan (treasury), dan menghitung bahwa ia telah melakukannya. *Presisi:* `PROTOCOL_FEE_BPS = 28` adalah konstanta waktu-kompilasi di Core tanpa setter di mana pun dalam bytecode yang di-deploy; biayanya adalah `mulDivUp(base, 28, 10,000)` — dibulatkan ke atas, sehingga biaya nol tidak dapat dicapai untuk basis bukan-nol mana pun — dibagi `TREASURY1_SHARE = 3,000` bps ke perbendaharaan pertama dan sisanya ke perbendaharaan kedua (dihitung sebagai `fee − t1`, sehingga keduanya selalu berjumlah sama dengan biaya tanpa sisa debu), dengan perbendaharaan ditetapkan saat konstruksi dan dapat dibekukan selamanya oleh Pintu Satu Arah. Tidak ada kunci yang dapat menaikkan tarif terhadap seorang pedagang dan tidak ada kunci yang dapat menurunkannya bagi integrator yang diistimewakan: pertanyaan biaya telah dijawab pada waktu kompilasi dan dihapus dari daftar hal yang dapat dilakukan sebuah kunci. ### §13.1 Di mana biaya dibebankan: dua rezim, keduanya diberi nama Aturan sejak 2026-08-22 adalah satu kalimat: **bebankan sekali, pada koin jembatan pertama yang dipegang Router.** Router memindai rute untuk hop pertama yang token input-nya adalah koin jembatan terdaftar (`hub.isBridgeToken`, menurut urutan hop) — hop itu adalah `feeHop` — dan membebankan 28 bps dari input hop tersebut yang *diukur*: pada hop 0 tarikan yang diukur dibatasi oleh apa yang dikomitmenkan rute, pada hop berikutnya saldo koin jembatan milik Router di atas baseline asingnya, besaran yang sudah tahan terhadap fee-on-transfer dan saldo nyasar. Router kemudian tidak membebankan apa pun lagi pada rute itu. Rute langsung yang tujuannya sendiri adalah koin jembatan (TOKEN → WETH) membebankan biaya pada output sebagai gantinya, setelah pemeriksaan lantai — lantai memvalidasi kualitas swap, potongan protokol diambil dari jumlah yang sudah divalidasi, dan minimum pengguna dibandingkan dengan apa yang sebenarnya mereka terima. Inilah **rezim berjangkar**. Mengapa pada koin jembatan dan bukan pada tujuan: koin jembatannya adalah WETH dan USDC, dan perbendaharaan menerima koin likuid yang ingin disimpannya alih-alih debu dari token ekor apa pun yang menjadi tujuan. Mengapa pada input hop 1 dan bukan output hop 0: keduanya token yang sama dan jumlah yang sama, tetapi input hop 1 diukur dengan saldo sungguhan, yaitu pengukuran yang memang sudah dilakukan Router. Aturan ini memiliki rezim kedua yang tidak disebutkan oleh kalimat tersebut hingga 2026-09-05. Rute yang dirakit manual melalui pool yang tidak akan dipegang registri, tanpa koin jembatan sebagai input hop mana pun, tidak pernah menemukan `feeHop`; predikat yang membebankan biaya kemudian bernilai benar untuk *setiap* hop, dan setiap hop membayar 28 bps atas input terukurnya sendiri. Inilah **rezim habis dicoba (exhaustion)**, dan ini adalah aturan yang disengaja, bukan kelalaian: membebankan rute seperti itu sekali saja, pada hop 0, telah dicoba di dalam suite pada tanggal itu dan membuka kembali celah lolos yang justru ditutup oleh kebijakan habis dicoba — hop pertama tanpa nilai membawa titik biaya ke atas debu dan hop sungguhan tidak membayar apa pun (`test/FeeEscapeViaJunkPrefix.t.sol`); lima tes yang dipatok menolak perubahan itu di dalam run yang sama. Tidak ada indeks tempat menyisipkan debu yang lolos dari setiap hop, dan itulah makna "kekebalan karena habis dicoba". Solver membangun setiap rute multi-hop melalui koin jembatan terdaftar, sehingga rute buatan Solver selalu membayar tepat sekali; rezim habis dicoba adalah apa yang ditemui pemanggil ketika mereka merutekan di luar registri, dan Quoter memodelkannya (`_pack` membebankan `hops.length` kali ketika tidak ada input hop yang merupakan koin jembatan, sekali jika sebaliknya), sehingga pratinjau dan penyerahan sepakat di kedua rezim (`test/ExhaustionRegimePreviewParity.t.sol`).  ### §13.2 Komitmen memiliki satu produsen, dan kontrak menghitung Dua segel menyertai rezim-rezim tersebut. Jumlah input leg yang dideklarasikan pada sebuah hop — basis biaya pada hop 0 dan penyebut skala — dihitung oleh satu fungsi, `_legSum`; sebelum 2026-09-05 masing-masing menjumlahkan leg dalam loop-nya sendiri, dua produsen untuk satu angka. Dan buku besar biaya: `_payFee`, satu-satunya fungsi yang mentransfer biaya, menghitung ke dalam slot transien (`TSLOT_FEE`); setiap penyelesaian membaca slot itu sekali, menolak penyerahan yang tidak membayar apa pun (`RouterE(15)`) dan, pada rute berjangkar, pembayaran kedua (`RouterE(16)`), lalu mengosongkannya. Dua pemeriksaan buku besar itu adalah *sabuk pengaman*: secara terisolasi tidak ada tes yang dapat memicunya, karena predikat di depannya tidak menyisakan jalur yang terselesaikan tanpa membayar atau membayar dua kali pada rute berjangkar. Keduanya adalah kontrak yang menolak pada waktu jalan apa yang ditolak oleh tes pada waktu tinjauan, pada jalur yang belum ada; keduanya dicantumkan sebagai sabuk pengaman, tidak dihitung sebagai tercakup di mana pun, dan tidak ada dalam penjaga mutasi, yang hanya menerima mutan yang dibunuh oleh tes yang bernama. ### §13.3 Aturan Surplus **Aturan Surplus** adalah argumen keselarasan dari desain biaya, dinyatakan sebagaimana kode mengimplementasikannya: bagian protokol adalah 28 bps dari satu basis yang diukur, sekali pada rute berjangkar dan sekali per hop pada rute yang habis dicoba, dan tidak ada suku di mana pun dalam penyelesaian yang berskala dengan selisih antara yang dikuotasikan dan yang diserahkan. Ketika basisnya adalah input — setiap rute multi-hop dan setiap rute langsung yang tujuannya bukan koin jembatan — output tidak disentuh: semua yang diserahkan pool di atas kuotasi sampai ke penerima secara utuh, dan biaya tidak dapat naik karena sebuah pengisian berlangsung menguntungkan. Ketika basisnya adalah output — rute langsung ke koin jembatan — biayanya adalah 28 bps dari penyerahan bruto, termasuk surplus, dan tidak lebih. Sumbu tempat agregator paling tergoda untuk menyunat adalah selisih antara kuotasi dan pengisian; desain ini sama sekali tidak memberi selisih itu suku biaya, sehingga tarif utama adalah tarif yang sebenarnya dan satu-satunya. Basis tidak pernah dibaca dari calldata: `route.totalOut` sampai ke Router sebagai klaim orang asing dan tidak dibaca oleh apa pun (`test_FeeBase_IgnoresLiedAboutTotalOut`). **Contoh terhitung 5 — dua rezim pada satu rute.** Koin jembatannya adalah {WETH, USDC}; pedagang menjual 10,000 A. *Berjangkar, dua hop.* A → WETH → B. Hop 0 tidak dibebani biaya (input-nya, A, bukan koin jembatan). Pool hop 0 membayar 5.000 WETH, diukur sebagai saldo WETH Router di atas baseline asingnya. `feeHop` = 1: biayanya adalah $\lceil 5.000 \times 28 / 10{,}000 \rceil = 0.014$ WETH, dibagi 0.0042 ke perbendaharaan pertama dan 0.0098 ke perbendaharaan kedua, dan hop 1 membelanjakan 4.986 WETH ke B. Satu event `Fee`; buku besar membaca 1 dan terpenuhi; pratinjau memotong 28 bps sekali. *Berjangkar, langsung ke koin jembatan.* A → WETH dalam satu hop. Tidak ada yang dibebankan pada input. Pool menyerahkan 5.000 WETH bruto; lantai diperiksa pada 5.000; kemudian biaya sisi output $\lceil 5.000 \times 0.0028 \rceil = 0.014$ WETH dibayar dan 4.986 WETH diserahkan; `userMinOut` dibandingkan dengan 4.986. Satu event `Fee`, didenominasikan dalam token output. *Habis dicoba, dua hop.* A → C → B di mana tidak satu pun dari A, C atau B adalah koin jembatan — rute yang tidak dibangun oleh Solver mana pun. Hop 0 membayar $\lceil 10{,}000 \times 0.0028 \rceil = 28$ A dan mengirim 9,972 A ke pool-nya, yang membayar 2,000 C; hop 1 membayar $\lceil 2{,}000 \times 0.0028 \rceil = 5.6$ C dan mengirim 1,994.4 C ke B. Dua event `Fee`; buku besar membaca 2 tanpa `feeHop`, sehingga `RouterE(16)` tidak berlaku; tarif efektifnya adalah $1 - 0.9972^{2} = 55.9$ bps, dan pratinjau menyatakan demikian. ### §13.4 Biaya, diukur dari luar Router `test/FeeSeals.t.sol` tidak membaca satu pun angka Router: token biaya berasal dari aturan dan daftar koin jembatan, basis dari delta saldo pool (apa yang keluar dari Router ke hop biaya, atau apa yang dibayarkan pool hop sebelumnya) atau milik penerima, biaya dari delta perbendaharaan, hitungan dari event `Fee` — atas setiap bentuk yang diterima Router (satu hingga tiga hop; koin jembatan di posisi tidak ada, pertama, tengah atau terakhir; satu atau dua leg per hop), jumlah yang di-fuzz dari $10^{12}$ hingga $10^{21}$ wei, 2,000 run, tanpa kegagalan, dengan Router tidak memegang apa pun setelah setiap penyelesaian. | Bentuk rute | Rezim | Di mana biaya mendarat | Terukur | |---|---|---|---| | A → B (keduanya bukan koin jembatan) | habis dicoba, satu hop | input hop 0, sekali | biaya = ⌈28 bps × input⌉, satu event | | W → A (koin jembatan masuk) | berjangkar | input hop 0 | sama | | A → W (koin jembatan keluar, langsung) | berjangkar, sisi output | output | biaya = ⌈28 bps × output bruto⌉, diserahkan = bruto − biaya | | A → C → B (tanpa koin jembatan) | habis dicoba, dua hop | input terukur setiap hop | dua event | | W → A → B | berjangkar pada hop 0 | input hop 0 | satu event | | A → W → B | berjangkar pada hop 1 | koin jembatan yang dihasilkan hop 0 | satu event, ⌈28 bps × apa yang dibayarkan pool hop 0⌉ | | A → C → W (koin jembatan hanya sebagai output dari dua hop) | habis dicoba | input setiap hop | dua event | | A → C → D → B · A → W → C → B · A → C → W → B | seperti di atas | seperti di atas | 3 · 1 · 1 event | **Seberapa sering tes biaya mendeteksi cacat** diukur, bukan diasumsikan (`docs/assurance/fee-seal-detection.json`): setiap mutan biaya — predikat rezim yang digeser ke salah satu arah, produsen komitmen, dua pemeriksaan buku besar, dan tiga mutan biaya dari studi invarian — dijalankan dengan dua puluh seed fuzz per tes yang di-fuzz dan sekali per tes deterministik; laju deteksi dilaporkan dengan interval Wilson 95 % dan, ketika tidak ada yang terlewat, batas aturan-tiga (rule of three) pada probabilitas terlewat. | Mutan | Fuzz FeeSeals | Kampanye Router (2 hop, 2 leg) | Covering array t = 2 | Lolos via awalan sampah | Paritas pratinjau habis dicoba | |---|---|---|---|---|---| | habis dicoba hanya membebani hop 0 | 20/20 [0.84, 1.00] | 20/20 [0.84, 1.00] | tidak | ya | ya | | habis dicoba melewati hop 0 | 20/20 [0.84, 1.00] | 20/20 [0.84, 1.00] | tidak | ya | ya | | komitmen hanya menghitung leg pertama | 20/20 [0.84, 1.00] | 20/20 [0.84, 1.00] | tidak | tidak | tidak | | biaya digandakan | 20/20 [0.84, 1.00] | 20/20 [0.84, 1.00] | ya | ya | ya | | biaya sisi input tidak pernah dibebankan | 20/20 [0.84, 1.00] | 20/20 [0.84, 1.00] | tidak | ya | ya | | biaya dibebankan di kedua sisi | 20/20 [0.84, 1.00] | 20/20 [0.84, 1.00] | tidak | ya | ya | | sabuk pengaman: penyelesaian tanpa biaya tidak lagi ditolak | 0/20 [0.00, 0.16] | 0/20 [0.00, 0.16] | tidak | tidak | tidak | | sabuk pengaman: pembayaran ganda berjangkar tidak lagi ditolak | 0/20 [0.00, 0.16] | 0/20 [0.00, 0.16] | tidak | tidak | tidak |  Baca menyusuri baris: tes mana yang melihat cacat ini. Baca menuruni kolom: apa yang dapat dan tidak dapat dilihat sebuah tes. Pengukuran pertama mendapati kampanye Router buta terhadap mutan habis dicoba yang membebaskan hop 0 dan terhadap produsen komitmen, karena kampanye itu hanya membangun rute langsung satu leg; kampanye diperluas pada hari yang sama untuk menelusuri dua hop dan membagi hop 0 ke dua pool, dengan koin jembatan di dalam semesta sehingga satu kampanye mencakup setiap rezim, dan keduanya kini terlihat 20 dari 20. Covering array hanya melihat biaya yang digandakan, karena baris-barisnya selalu melintasi koin jembatan. Dua puluh seed pada 20 dari 20 membatasi probabilitas terlewat satu kampanye pada 15 %, itulah sebabnya penjaga mutasi menjalankan tes yang bernama dan kampanye sekaligus. Merangkum bagian ini dalam bentuk yang digunakan makalah ini — klaim, lokasi penegakan, batas: tidak seorang pun dapat menggeser tarif atau pembagiannya, karena keduanya tidak memiliki setter dalam bytecode yang di-deploy; pemanggil tidak dapat mengecilkan biaya dengan merendahkan kuotasi, karena basisnya adalah saldo yang diukur dan `route.totalOut` tidak dibaca oleh apa pun; pemanggil tidak dapat menghindari biaya dengan awalan tanpa nilai, karena rute tanpa input berjembatan membayar di setiap hop; dan penyelesaian tidak dapat tidak membayar atau membayar dua kali pada rute berjangkar, karena Router menghitung — dengan batas bahwa dua pemeriksaan milik penghitung itu sendiri adalah sabuk pengaman yang tidak dapat dipicu oleh tes mana pun. ## §14 Model keamanan *Sederhana:* Router tidak memegang apa pun di antara transaksi, setiap swap bersifat semua-atau-tidak-sama-sekali, dan setiap kelas serangan yang telah dipertimbangkan repositori ini dijawab oleh pemeriksaan yang bernama atau dinyatakan di luar cakupan. *Presisi:* katalog ancaman adalah `docs/assurance/threats.json`, 23 kelas yang diambil dari catatan publik eksploit; masing-masing menyebut simbol penjaga yang menolaknya, dan sebuah skrip CI menggagalkan build jika simbol itu keluar dari `src/` atau tes yang disebut keluar dari `test/`. Cakupan sebuah katalog adalah lantai dari apa yang telah dipertimbangkan, tidak pernah plafon dari apa yang ada. ### §14.1 Serangan dan pemeriksaan yang menolaknya | Kelas (id) | Pemeriksaan yang menolaknya | Di mana ditegakkan | Status | Tes yang menunjukkan pemeriksaan dapat gagal | |---|---|---|---|---| | Reentrancy (DASP-1) | kunci transien `nrEntrant` pada setiap pintu yang memindahkan nilai; permukaan callback mengautentikasi pemanggilnya | Router `nrEntrant` → `RouterE(7)`; `fallback` → `RouterE(6)` | diblokir | `invariant_reentrancyBlocked` (`test/RouterAdversarialV4FromV1.t.sol`) | | Kontrol akses (DASP-2) | empat peran; setiap pintu istimewa dijaga; tingkat kontrol dapat dilepaskan selamanya | Hub `onlyAdmin` / `onlyControl` → `HubE(1)`; Router `onlyControl` → `RouterE(1)` | diblokir | `test/HubAllowHookAfterRenounce.t.sol`, `test/ControlEvents.t.sol` | | Overflow/underflow aritmetika (DASP-3) | aritmetika terperiksa di seluruh kode; setiap blok `unchecked` membawa batas tertulis; keterwakilan kurva keras diuji pada batasnya (`MAX_SQRT_PRICE_MINUS_ONE`) | Core | diblokir | `test/BoundaryEquality.t.sol`, `test/CompilerPanicSurface.t.sol` | | Penolakan layanan melalui iterasi tak terbatas (DASP-5) | setiap dimensi rute dibatasi: `MAX_HOPS = 3`, `MAX_LEGS_PER_HOP = 5`, `MAX_LEGS = 11`, `MAX_CANDIDATES = 8`, `MAX_SLOTS = 16`, `MAX_FACTORIES = 16` | Router `_execute` → `RouterE(3)`; Solver; Hub → `HubE(4)` (factory), `_canInsert` (slot) | diblokir | `test/RouteHopCeiling.t.sol` | | Ketergantungan urutan transaksi / sandwich (DASP-7) | lantai Iron-Law, dijepit keras pada `FLOOR_HARD_MAX_LOSS_BPS = 2,000`, ditegakkan secara independen dari minimum pemanggil, yang hanya boleh memperketatnya | Core `ironFloorBpsShv`; Router `_execute` → `RouterE(5)` | diblokir (dibatasi, §14.3) | `test/regime/SandwichCurve.t.sol`; `invariant_DeliveredNeverBelowTheProtocolFloor` | | Reentrancy lintas fungsi melalui venue (SWC-107) | kunci transien yang sama mencakup seluruh swap, termasuk callback pool | Router `nrEntrant` | diblokir | `test/V4LockedRegionReentrancy.t.sol` | | Manipulasi oracle harga (SOK-ORACLE) | tidak ada feed: kuotasi acuan dihasilkan di dalam frame eksekusi dari venue yang diperdagangkan, dan lantai diturunkan darinya (`ironFloorBps`) | Core; Router `_execute` | diblokir | `test_Parity_SplitRoute_AttestedFloorEqualsEnforcedFloor` (`test/FloorParitySolverRouter.t.sol`) | | Besaran yang dipasok pemanggil menggantikan besaran terukur (SOK-FEE-BASE) | basis biaya adalah saldo yang diukur (`_chargeHopFee`); `route.totalOut` tidak dibaca oleh apa pun | Router `_chargeHopFee` | diblokir | `test_FeeBase_IgnoresLiedAboutTotalOut` (`test/BlazePhoenixRouter.t.sol`) | | Token fee-on-transfer dan rebasing (SOK-FOT) | setiap jumlah yang penting adalah delta saldo yang diukur (`balanceOf`), tidak pernah jumlah transfer yang diasumsikan | Router, setiap sambungan | diblokir | `test/FotFloorReprice.t.sol`, `test/PartialFotAtPrePulledDoors.t.sol` | | Venue bermusuhan diterima ke registri (SOK-VENUE-ADMISSION) | penerimaan hanya oleh kurator, satu baris per alamat; asal penurunan diatestasi saat penerimaan (`factoryDeployer`) dan dibekukan setelah pelepasan | Hub `addFactory`, `_probe` | diblokir | `test_C4_FirstPin_AfterRenounce_MustNotAttestTheLiveAnswer` (`test/T19ReadmissionEdge.t.sol`) | | Venue yang diterima yang logikanya berpindah di balik proxy (SOK-PROXY-VENUE) | penerimaan ulang setelah pelepasan ditolak ketika runtime berpindah (`factoryCodehash`); ketika sebuah proxy dapat mengubah jawabannya tanpa mengubah kodenya, jawabannya yang dipatok sebagai gantinya | Hub `addFactory` → `HubE(1)` | diblokir | `test/FactoryCodehashPin.t.sol`, `test/RenouncedFactoryRearm.t.sol` | | Baris venue diubah dari diturunkan menjadi ditanyakan setelah osifikasi (SOK-MODE-FLIP) | baris derive tidak dapat menjadi baris ask begitu `controlRenounced`; pengetatan ke arah sebaliknya tetap diizinkan | Hub `addFactory` | diblokir | `test_C4_S3_DeriveRowMustNotBecomeAnAskRowAfterRenounce` (`test/T19ReadmissionEdge.t.sol`) | | Metrik yang dipublikasikan melaporkan deklarasi pemanggil (SOK-VOLUME) | registri diberi jumlah yang mampu dibelanjakan hop, dari rasio terukur-atas-terdeklarasi (`hopScale`) | Router `_recordHits` | diblokir | `test_INV_F4_VolumeInEqualsTheMeasuredPoolDelta` (`test/VolumeEventFidelity.t.sol`) | | Pratinjau yang tidak memprediksi eksekusi (SOK-QUOTE-EXEC) | pratinjau dan penyerahan ditegaskan sama di kedua rezim biaya (`previewRoute`, `_pack`) | Quoter; Router | diblokir | `test_INV_F2_PreviewPredictsDeliveryWithNoBridge` (`test/ExhaustionRegimePreviewParity.t.sol`) | | Penurunan deterministik diarahkan ke alamat penyerang (SOK-V4-DERIVE) | preimage CREATE2 memiliki satu produsen (`create2Address`); id pool diturunkan dari key-nya sendiri; `hasCode` dan bukti keaktifan membuang apa yang tidak terselesaikan | Core; Hub `_probe`, `_scanV4` | diblokir | `test/ConditionAdequacyCore.t.sol`, `test/KindIsDerivedNotDeclared.t.sol` | | Hook berbahaya pada venue ber-hook (SOK-HOOK) | tiga lapisan, §14.2: bit alamat yang tidak dapat diubah, allow-list dengan patokan codehash (`hookAllowed`, `isHookLive`), proyektor Ξ | Router → `RouterE(9)`; Hub `allowHook` → `HubE(8)`; Solver `_topKPools` | diblokir | `test/V4SievedHookIsTheExecutedHook.t.sol`, `test/SeedPoolHookMustBeAllowed.t.sol`, `test/RenouncedHookRearm.t.sol` | | Penghabisan registri melalui penerimaan berulang (SOK-GRIEF-SEATS) | satu baris per alamat; penambahan berulang menyegarkan di tempat alih-alih memakan kursi (`MAX_FACTORIES`) | Hub `addFactory` → `HubE(4)` | diblokir | `test/RenouncedFactoryRearm.t.sol` | | Panggilan eksternal sembarang atau sink transfer-from (SOK-ARBITRARY-CALL) | eksekutor tidak pernah menerima target panggilan yang dipasok pemanggil; interaksi venue dikirim dari himpunan bentuk tertutup yang dipilih menurut jenis (`_execScaled`), dan jenis yang tidak dikenal melakukan revert | Router `_execScaled` → `RouterE(8)` | diblokir | `test/regime/HostileVenueMatrix.t.sol` | | Replay tanda tangan pada persetujuan terdelegasi (SOK-SIG-REPLAY) | persetujuan terdelegasi ditangani oleh Permit2 kanonis (`permitTransferFrom`); sistem tidak memiliki skema tanda tangan sendiri | Router `swapExactInWithPermit2` | diblokir | `test/RouterPermit2OneStep.t.sol` | | Perebutan tata kelola (SOK-GOV) | tidak ada tata kelola: tidak ada pemungutan suara token, tidak ada timelock, tidak ada proxy; satu-satunya kewenangan istimewa adalah penerimaan venue dan penjedaan, keduanya dapat dilepaskan | — | di luar cakupan | — | | Upgrade berbahaya (SOK-UPGRADE) | kontrak-kontraknya tidak dapat diubah; tidak ada proxy dan tidak ada slot implementasi | — | di luar cakupan | — | | Kompromi atas bridge atau venue eksternal (SOK-BRIDGE-EXT) | venue pihak ketiga dikomposisikan, bukan dikendalikan; kegagalannya dibatasi di sini oleh lantai dan minimum pemanggil, dan keamanan internalnya tidak diklaim | — | di luar cakupan | — | | Kompromi atas kunci privat pengguna (SOK-KEY) | di luar batas kepercayaan; dicatat karena data insiden yang dipublikasikan mengaitkan sebagian besar kerugian dengannya | — | di luar cakupan | — | Sembilan belas dari dua puluh tiga kelas dijawab oleh penjaga yang bernama; empat berada di luar cakupan dengan alasan yang dicatat. Katalog ini diperiksa silang dari arah sebaliknya oleh sebuah penutupan aset (`assets.json`): enam hal yang dipegang atau diputuskan sistem — dana dalam perjalanan, allowance terdelegasi, biaya protokol, integritas registri, saldo terdampar, gas pemanggil — disilangkan dengan lima cara sesuatu dapat hilang, tiga puluh sel, masing-masing berujung pada sebuah kelas ancaman, alasan di luar cakupan, atau status *terbuka* yang eksplisit. Sembilan belas sel tercakup, tiga di luar cakupan, lima tidak berlaku, dan tiga terbuka serta dipublikasikan demikian: mengganggu (griefing) denominasi biaya, menelantarkan debu agar pemulihan tidak ekonomis, dan pemanggil yang menemui salah satu dari tiga panic kompiler yang dapat dicapai alih-alih penolakan yang bernama. Tidak satu pun sel terbuka itu merupakan jalur menuju dana orang lain. ### §14.2 Hook bermusuhan: tiga lapisan, yang termurah lebih dulu Hook adalah kode sembarang yang berjalan di dalam penyelesaian yang sedang dilakukan Router, dan pertahanan naif — menanyakan apa yang akan dilakukannya — bukanlah pertahanan, karena hook bermusuhan berbohong atau melakukan re-entry. Sebagai gantinya berdiri tiga lapisan independen, disusun sehingga yang termurah dan paling pasti berjalan lebih dulu; ketiganya membatasi perubahan delta, dan satu-satunya residu yang tidak dijangkaunya — hook bebas-delta yang mengganti biaya dinamisnya (§5.4) — dibatasi oleh Φ dan minimum pemanggil sebagai gantinya. **Lapisan 1 — bit izin berada di dalam alamat, dan alamat tidak dapat berbohong.** V4 mengodekan izin sebuah hook di 14 bit rendah alamat kontraknya sendiri; bit-bit itu ditetapkan saat deployment oleh salt CREATE2, dan PoolManager sendiri memeriksa bit yang sama sebelum memanggil hook, sehingga hook tidak dapat memiliki izin yang tidak dideklarasikan alamatnya. Tepat dua bit mengizinkan hook mengubah akuntansi swap, dan Router menyaringnya dengan satu operasi AND sebelum token apa pun bergerak (`hookAltersDeltas`): $$ \left(\mathrm{uint160}(\mathrm{hook})\ \&\ \mathtt{0x3FFF}\right)\ \&\ \left((1 \ll 3) \mid (1 \ll 2)\right) \ne 0 \;\;\Longrightarrow\;\; \text{leg refused, } \mathtt{RouterE(9)} $$ ^e18 Tidak ada panggilan ke kode yang tidak tepercaya, tidak ada yang dapat ditipu, dan penghindaran akan membutuhkan alamat yang bit-bitnya bertentangan dengan penegakan milik manager itu sendiri. Sebuah proxy dapat mengganti setiap baris logikanya dan tetap tidak memperoleh bit yang tidak pernah dimiliki alamatnya — itulah sebabnya penolakan ini berada pada jarak proyeksi nol (§15.9) sementara patokan codehash di bawahnya tidak. **Lapisan 2 — allow-list, tertutup secara default, dengan kode yang dipatok.** Hook dengan bit bersih masih dapat melakukan revert secara jahat untuk mengganggu atau membakar gas, sehingga pool V4 hanya dapat dirutekan jika hook-nya masuk allow-list kurator, dan Hub mematok codehash hook saat penerimaan: hook yang runtime-nya kemudian berubah dijeda otomatis tanpa dikeluarkan (`isHookLive` false) dan hanya dilanjutkan jika diterima ulang — kewenangan yang, setelah pelepasan, ditolak untuk hook mana pun yang kodenya berpindah. Batas patokan ini dinyatakan di lokasinya: ia mengikat kode runtime, sehingga ia menangkap deploy ulang atau mutasi langsung dan tidak menangkap proxy delegasi yang implementasinya ditukar sementara runtime-nya sendiri tetap identik byte demi byte, karena EVM tidak memberi kontrak cara untuk membaca storage kontrak lain. Menerima hook yang dapat di-upgrade adalah penilaian manusia yang tidak dapat digantikan oleh patokan ini. Lapisan-lapisan yang tidak bergantung padanya tetap berdiri apa pun yang terjadi. **Lapisan 3 — rute itu bahkan tidak pernah ditampilkan.** Proyektor Ξ menghapus setiap pool yang hook-nya mengubah delta dari himpunan kandidat Solver sebelum pemeringkatan (`_topKPools`), dan kanal baca Hub hanya menyajikan hook yang aktif; rute yang menyentuh hook yang tidak dapat diterima tidak ikut serta dalam maksimisasi. Sebuah aturan bentuk rute melengkapinya: urutan kanonis, di seluruh rute — tidak ada leg tanpa hook yang pernah dieksekusi setelah sebuah hook berjalan (§11.4).  Mengalahkan tumpukan ini membutuhkan hook yang tidak membawa bit delta, berada di allow-list tanpa berubah, dan tetap menumbangkan penyelesaian — kombinasi yang dikesampingkan untuk perubahan delta oleh sandaran Lapisan 1 pada penegakan V4 sendiri yang tidak dapat diubah; residu penggantian biaya dari §5.4 tetap ada, dan lantai membatasinya. Residunya dinyatakan dalam tabel: hook bebas-delta yang masuk allow-list masih dapat melakukan revert di tengah swap dan membuang gas dari upaya tersebut. Dan satu-satunya tuas saringan disebutkan: hook yang tersaring mengikat swap yang dieksekusi karena PoolManager kanonis menggemakan data unlock apa adanya dan hanya melakukan callback ke pemanggil unlock-nya; `setV4Manager` milik Hub, sebuah kewenangan kontrol, adalah satu-satunya alamat tempat asumsi itu bersandar, dan manager yang tidak jujur meruntuhkan output yang diukur sehingga batas milik pemanggil sendiri menolak swap tersebut (kampanye `HostileV4Manager`) — dibatasi, bukan tidak ada. ### §14.3 Dibatasi, bukan dihilangkan: kebasian, pengurutan, dan kurva sandwich Sebuah kuotasi adalah pernyataan tentang masa lalu, dan perdagangan terjadi di masa depan. Pintu penyelesaian dalam-frame menutup sepenuhnya separuh selisih itu yang berada di sisi operator — rute diturunkan di dalam transaksi yang mengeksekusinya, dari cadangan sebagaimana adanya di blok tersebut. Yang tersisa adalah separuh milik rantai itu sendiri: pool dapat bergerak antara saat Anda menandatangani dan saat transaksi Anda dimasukkan. Tidak seorang pun dapat mencegah hal ini dari dalam kontrak, karena pengurutan diputuskan sebelum kode berjalan; protokol yang mengklaim telah menghilangkan front-running entah telah memindahkan perdagangan Anda dari antrean publik, dengan memercayai siapa pun yang kini memegangnya, atau sedang menggambarkan sesuatu yang lebih sempit daripada kedengarannya. Yang dilakukan protokol ini adalah membatasinya, dua kali dan secara independen: minimum Anda membatasi kerugian pada angka yang Anda pilih, dan lantai Iron-Law — diturunkan ulang oleh Router dari dampak yang diukur dan kuotasi dalam-frame hop terakhir, bukan dari apa pun yang dipasok penyerang atau rute — membatasinya lagi atas tanggungan protokol sendiri. Batas ini diukur dari sisi penyerang (`test/regime/SandwichCurve.t.sol`): rute dan lantai korban ditetapkan pada saat kuotasi, seperti pada transaksi yang tertunda; penyerang memperdagangkan sebagian dari kedalaman pool mendahului korban, korban mengeksekusi, penyerang memperdagangkan kembali. Venue-nya adalah pasangan constant-product — bentuk yang digunakan setiap model sandwich — sehingga kurva tersebut adalah sifat dari lantai. Pada perdagangan sebesar 1 % dari kedalaman (10,000 terhadap 1,000,000 di setiap sisi): | Penyerang menggeser | Korban | Kerugian korban vs kuotasi | Perjalanan pulang-pergi penyerang | |---|---|---|---| | 0.1 % dari kedalaman | terselesaikan | 0.47 % | +13.9 | | 0.5 % | terselesaikan | 1.26 % | +68.9 | | 1 % | terselesaikan | 2.22 % | +136.7 | | 2 % | terselesaikan | 4.12 % | +268.7 | | 3 % dan lebih | **ditolak** | 0 | −174.5 … −544.9 |  Jaminan yang ditegaskan di setiap titik: korban yang terselesaikan tidak pernah menerima kurang dari lantai yang diatestasi pada saat kuotasi, sehingga kerugian dibatasi oleh jarak antara kuotasi yang diatestasi dan lantai yang diatestasi; dan wilayah penolakan tertutup ke atas — melewati tepinya setiap manipulasi yang lebih besar ditolak dan penyerang ditinggalkan memegang harga yang ia geser. Angka yang layak dikutip adalah baris terakhir yang terselesaikan: lantai membatasi apa yang dapat diambil sandwich dari perdagangan 1 % pada sekitar 2.7 % darinya, dan mengubah perdagangan penyerang menjadi kerugian begitu ia akan mengambil lebih. Rute dalam-frame menambahkan penangkal yang lebih senyap: tidak ada jalur yang dipublikasikan sebelumnya untuk dipelajari searcher, karena jalur itu tidak ada sampai blok yang mengeksekusinya. Minimum yang longgar adalah undangan; minimum yang ketat adalah satu-satunya kendali paling efektif di bagian ini yang menjadi milik Anda. ### §14.4 Venue bermusuhan Patologi venue memiliki matriksnya sendiri (§15.5): sepuluh perilaku menyimpang — pool yang tidak membayar apa pun, membayar setengah, mengembalikan bom returndata 64 KiB, membakar semua gas saat membaca atau saat swap, token yang `decimals()`-nya tidak pernah kembali, callback pembayaran yang dipicu dua kali, pool yang melakukan re-entry ke Router sebelum membayar, `slot0()` yang melakukan revert, factory yang menjawab dengan pool atas token lain — disilangkan dengan pintu calldata dan pintu penyelesaian, 20 dari 20 sel terselesaikan dengan jumlah yang diserahkan sama dengan delta saldo dan tidak ada yang tertinggal di Router, atau menolak dengan selector milik kami. Swap yang membakar semua gas yang diteruskan adalah satu-satunya sel yang tidak dapat diputuskan pemanggil mana pun bagi pihak yang dipanggilnya; transaksi melakukan revert secara utuh dan saldo pengguna tidak tersentuh. Setiap pembacaan terjaga yang dilakukan Core ke sebuah venue dibatasi pada `GAS_CAP = 100,000` gas, sehingga venue yang membakar gas pada *pembacaan* menelan biaya yang terbatas dan dibuang, tidak fatal. ### §14.5 Front end yang bermusuhan Pada setiap agregator yang pernah dibangun, antarmuka mengusulkan minimum, dan antarmuka yang ceroboh mengusulkannya dengan buruk — tidak ada kontrak yang dapat mengetahui apa yang akan Anda pilih. Yang dapat dilakukan kontrak adalah membuat usulan itu dapat dibuktikan: setiap swap memancarkan `ExecutionProof` — kuotasi yang digunakan, jumlah yang diserahkan, lantai yang diterapkan — secara permanen, on-chain, sehingga kualitas eksekusi antarmuka mana pun menjadi catatan publik per transaksi yang dapat diaudit siapa pun, termasuk Anda. Antarmuka yang secara konsisten mengusulkan minimum yang buruk menuliskan dakwaannya sendiri ke dalam log event. Pertahanan yang melengkapi mekanisme ini adalah sebuah kebiasaan: lihatlah minimum sebelum Anda menandatangani; itulah satu-satunya field yang sepenuhnya milik Anda. ### §14.6 Apa yang dapat dan tidak dapat dilakukan kunci yang bermusuhan Sebelum pelepasan, kunci administratif ada, dan cara jujur untuk menggambarkannya adalah menurut kapabilitas, dengan mengasumsikan pemegang yang bermusuhan; enumerasi lengkap kewenangannya ada di §16.4. **Apa yang dapat dilakukan kunci Router yang bermusuhan:** mengalihkan tujuan biaya (`setTreasuries`); menjeda swap (`setPaused`); mengarahkan ulang kontrak WETH dan Permit2 yang dipanggil oleh pintu native dan pintu Permit2 (`setWeth`, `setPermit2`), yang membuat kedua pintu itu hanya sepercaya alamat yang ditetapkan; mengantrekan dan, 48 jam kemudian, mengeksekusi penyelamatan token yang terdampar di Router (`queueRescue`, `executeRescue`, `RESCUE_DELAY = 48 hours`, diumumkan on-chain oleh `RescueQueued`). **Apa yang tidak dapat dilakukannya:** menggeser tarif biaya, pembagian, atau lantai, karena semuanya adalah konstanta waktu-kompilasi tanpa setter; mengambil pokok dana, karena tidak ada proxy, tidak ada jalur upgrade, tidak ada `selfdestruct`, tidak ada persetujuan permanen atas dana pengguna kepada Router, dan Router tidak memegang apa pun saat diam — fungsi-fungsi yang akan melakukannya bukan dinonaktifkan, melainkan tidak ada. **Apa yang dapat dilakukan kunci Hub yang bermusuhan:** mencantumkan venue atau hook (`addFactory`, `allowHook`), menyemai pool (`seedPool`, melalui kursi operator), menjeda pembelajaran registri (`setPaused`), mengarahkan ulang pandangan Hub atas Router, Solver dan Quoter (`setRoles`), dan mengarahkan ulang manager V4 (`setV4Manager`, satu-satunya tuas saringan). **Apa yang tidak dapat dilakukannya:** salah menghargai sebuah pengisian, karena registri hanya memutuskan apa yang terlihat (§9.6) — hal paling tajam yang dapat dijangkau pencantuman bermusuhan adalah selisih antara kuotasi dan *minimum Anda*; pokok dana berada di luar jangkauan, toleransi slippage Anda tidak, yang merupakan satu alasan lagi bahwa minimum adalah milik Anda untuk ditetapkan secara ketat. ### §14.7 Pintu Satu Arah Otoritas administratif berakhir secara tidak dapat dibatalkan, di dalam bytecode, bukan dengan janji. Hub maupun Router sama-sama menyediakan `renounceControl`, dan masing-masing menolak dipanggil saat sedang dijeda (`RouterE(2)`, `HubE(2)`): protokol yang dijeda lalu dilepaskan akan menjadi keadaan terminal yang tidak diinginkan siapa pun dan tidak dapat ditinggalkan siapa pun, dan penjedaan layak dilakukan justru karena kontrol dipertahankan untuk bertindak. Flag pelepasan ditulis `true` di tepat satu lokasi di setiap kontrak dan ditulis `false` di tidak satu lokasi pun, sehingga tidak ada fungsi dalam bytecode yang di-deploy yang dapat membuka kembali pintu itu — perbedaan antara "kami tidak akan" dan "kami tidak bisa". Apa yang tertutup dan apa yang tetap terbuka dienumerasi, bukan dirangkum. Pada Router, semua yang berada di bawah `onlyControl` mati: `setAdmin`, `setTreasuries`, `setPermit2`, `setWeth`, `setPaused`, jalur penyelamatan — perbendaharaan, pengkabelan, dan flag jeda membeku pada nilai saat ini selamanya, dan Router terus mengeksekusi swap di bawah konfigurasi tetap tersebut. Pada Hub, **tingkat kontrol** mati: `setRoles`, `setOperator`, `setPaused`, `setV4Manager`, `removeBridge`, dan *penghapusan* hook dari daftar. **Tingkat kurator** bertahan, dan hanya menumbuhkan registri: `addFactory` (menolak, setelah pelepasan, factory mana pun yang runtime-nya berpindah atau baris derive mana pun yang akan menjadi baris ask), `addBridge` (hanya-tambah, paling banyak tiga, idempoten), `allowHook(h, true)` (menolak hook terdaftar yang kodenya berpindah); kursi operator yang sudah ada mempertahankan `seedPool` dan `addV4`, dan tidak ada kursi baru yang dapat diberikan. Pencantuman berbahaya setelah pelepasan tidak dapat menguras dana: pool divalidasi saat kuotasi dan saat eksekusi serta dibatasi oleh lantai dan minimum pemanggil. Registri terus belajar melalui perdagangan. Siapa pun yang mengulang kata "dilepaskan" tentang protokol ini seharusnya dapat menyebutkan pintu mana yang tetap terbuka — penerimaan, koin jembatan, pencantuman hook, penyemaian terkurasi — dan mana yang tertutup: setiap kewenangan yang mengalihkan atau membekukan. ### §14.8 Apa yang diminta model ini dari Anda Protokol menutup apa yang dapat ditutup sebuah kontrak: pemalsuan alamat, pemalsuan callback, pemalsuan akuntansi, hook bermusuhan, aritmetika. Ia membatasi apa yang tidak dapat dihilangkan kontrak mana pun: kebasian dan pengurutan, melalui minimum Anda dan lantai. Dan ia memublikasikan bukti terhadap apa yang bahkan tidak dapat dibatasinya: front end yang mengusulkan minimum buruk atas nama Anda. Setiap baris bermuara pada field yang sama. Tetapkan minimum Anda sendiri, dengan sengaja, setiap kali — itulah satu-satunya perlindungan di bagian ini yang kualitasnya tidak bergantung pada kecakapan siapa pun selain Anda. ## §15 Aparatus verifikasi, terukur *Sederhana:* setiap angka di sini dicetak di samping penyebut yang menjadi dasar pengukurannya, dihitung ulang dari checkout bersih oleh sebuah skrip atau perintah `forge` yang disebutkan namanya (Lampiran C), dan diikuti oleh apa yang tidak dibuktikannya. *Presisi:* pohon yang diukur adalah `main` pada `8949a9d` beserta branch yang menjadi asalnya, pada profil rilis (`optimizer_runs = 300`, `via_ir`), 2026-09-05. ### §15.1 Suite dalam angka | Apa | Jumlah | Cara menghitungnya | |---|---|---| | tes yang dideklarasikan | 1,609 fungsi `test*` / `invariant*` / `check*` di 236 berkas `.t.sol` | `grep` atas `test/` | | hijau pada profil rilis, suite fork dikecualikan | 1,319 lulus · 0 gagal · 1 dilewati, dari 1,320 | `forge test --no-match-path 'test/fork/**'` | | hijau pada likuiditas langsung | 119 dari 119 pada 39 suite di jalur fork, lima chain; ditambah tiga tes Base langsung dari §12 | `forge test --match-path 'test/fork/**'` dengan RPC arsip | | invarian stateful | 43 fungsi `invariant_*` dalam 14 kampanye | `grep -rc 'function invariant_' test` | | mutan terkurasi, semuanya terbunuh | 268 dari 268 | `.github/scripts/mutants.py`; `check_targets.py` | | covering array regime | kekuatan 2: 63 baris, seluruh 258 pasangan · kekuatan 3: 168 baris, seluruh 1,636 tripel · dari 5,184 kombinasi | `covering_array.py --check` | | ukuran yang dirilis (byte runtime; batas EIP-170 24,576; gerbang proyek 24,000) | Hub 23,648 · Router 23,781 · Solver 19,686 · Quoter 11,429 · Core 6,442 | `FOUNDRY_PROFILE=release forge build --sizes` | ### §15.2 Rantai bukti, dan penjaga mutasi terkurasi Sebuah properti hanya sebaik jalur terpendek dari sebuah ancaman menuju sesuatu yang akan gagal bila properti itu rusak: `threat → property → guard → test → mutant`. Sebuah penjaga disebut dengan simbolnya, sebuah tes dengan namanya, sebuah mutan dengan baris persis yang diubahnya; jika salah satu dari ketiganya hilang dari pohon, build gagal. Setiap tes regresi dalam suite telah terlihat gagal sekali, karena alasan yang menjadi namanya — sebuah perbaikan datang bersama tes yang merah terhadap kode tanpa perbaikan itu. Penjaga mutasi memuat 268 mutan yang ditulis tangan, masing-masing memasangkan satu baris sumber yang persis dengan satu-satunya tes yang harus gagal begitu baris itu diubah — sebuah penjaga dihapus, sebuah perbandingan dibalik pada batas yang menentukan sebuah penolakan, sebuah otorisasi diperluas, sebuah kode galat ditukar dengan kode tetangganya. Tiga properti menjadikannya penjaga, bukan sekadar skor: tes pasangannya dijalankan hijau terlebih dahulu pada pohon yang tidak dimutasi; mutasi yang dihapus oleh optimiser — bytecode runtime identik — dilaporkan sebagai *inert*, tidak pernah sebagai terbunuh; dan pemeriksaan statis satu detik memverifikasi bahwa setiap mutan masih menunjuk tepat satu baris. 203 dari 203 terbunuh. Angka ini adalah kecukupan terhadap register *ini*: skor yang jenuh adalah lantai, bukan langit-langit. ### §15.3 Mutan yang diarahkan pada invarian Hingga 2026-09-05 tidak satu pun mutan terkurasi menyebut sebuah invarian stateful sebagai tes yang harus mati karenanya. Ke-43 fungsi `invariant_*` di 14 kampanye berstatus hijau, dan tidak ada yang pernah menanyakan apakah salah satunya bisa menjadi merah: kampanye yang handler-nya tidak pernah mencapai keadaan yang dilindungi sebuah properti menyertifikasi properti itu atas semesta kosong, dan dari luar tampak identik dengan kampanye yang mencapainya. Pengukurannya adalah milik penjaga, diarahkan pada kampanye: ubah satu penjaga di sumber, jalankan setiap invarian pada satu seed, catat mana yang menyadarinya (`docs/assurance/invariant-mutants.json`). | Mutan | Apa yang dihilangkannya | Disadari oleh | |---|---|---| | transfer akhir membayar satu wei lebih sedikit | tidak-menyimpan-apa-pun | `RouterHoldsNothing`, `routerHoldsNothing`, `HoldsNothingBeyondTheSeed` | | biaya (fee) protokol menjadi dua kali lipat | plafon biaya | `FeeNeverExceedsProtocolMax` | | biaya sisi input tidak pernah dikenakan | lantai biaya | `FeeNeverEscapes`, `DeliveredNeverBelowUserMinOut` | | biaya dikenakan di kedua sisi | satu biaya, satu sisi | `FeeIsChargedOnExactlyOneSide` | | 30 % dari setiap biaya masuk ke alamat mati | konservasi | `conservationA/B/C/H`, `TokenConservation`, `LedgerConservationA` | | penjaga pasangan-leg menerima leg pada pasangan yang salah | hop homogen | `DivergentLegNeverSettles`, `HoldsNothingBeyondTheSeed`, `StrandedMoneyIsNeverSwept` | | `whenLive` tidak lagi memeriksa `paused` | jeda | `PausedRouterNeverSettles` | | kunci reentrancy tidak lagi menolak | kunci | `reentrancyBlocked` | | lantai protokol dibagi dua | lantai | `DeliveredNeverBelowTheProtocolFloor` — ditutup 2026-09-05 | | `MAX_SLOTS` menjadi 17 | batas registri | `neverExceedsMaxSlots` | | bukti pasangan saat registrasi dihapus | keaslian pasangan | `ActiveEntriesTradeThePair` — ditutup 2026-09-05 | | sapuan residu input mengabaikan baseline-nya | dana terdampar | `StrandedMoneyIsNeverSwept`, `HoldsNothingBeyondTheSeed` | | sapuan residu jembatan mengabaikan baseline-nya | dana terdampar | pasangan yang sama — ditutup 2026-09-05 | | pengukuran output mengabaikan baseline-nya | dana terdampar | pasangan yang sama | | pemeriksaan `userMinOut` pasca-biaya dibagi dua | — | bertahan, memang dirancang demikian: sentinel regresi yang tidak terjangkau dalam semesta kampanye tanpa token output fee-on-transfer; dua mutan unit mengawasinya |  Sebelas dari lima belas disadari pada pengukuran pertama; dua puluh nama invarian yang berbeda menjadi merah setidaknya sekali. Tiga dari empat yang bertahan ditutup pada hari yang sama dengan memberi sebuah kampanye aksi yang belum dimilikinya — pool asing yang ditawarkan di bawah pasangan itu, rute dua hop melalui saldo perantara yang telah diisi sebelumnya, seekor paus yang menggeser pool 0–8 % melawan sebuah rute yang telah dikuotasi sebelum rute basi itu dieksekusi — masing-masing diverifikasi merah tanpa penjaganya; dua penjaga tanpa pengawas jenis apa pun adalah angka yang menjadi alasan pengukuran ini ada untuk dicetak, dan kini angka itu nol. Empat belas dari lima belas disadari; keempat belas itu adalah entri penjaga yang dipasangkan dengan invarian yang mati karenanya. Suite hijau yang di dalamnya terdapat penjaga tanpa pengawas adalah bentuk dari kedua regresi terdokumentasi dalam codebase ini; pengukuran yang menemukannya kini berjalan pada setiap penjaga yang diklaim oleh kampanye. ### §15.4 Covering array regime Kriteria cakupan mengindeks kode; mutasi mengindeks sebuah kesalahan yang disuntikkan; tidak satu pun mengindeks keadaan yang ditetapkan sebuah *fixture* sebelum pemanggilan. Sepuluh faktor semacam itu dienumerasi — keluarga venue (V2, V3, Solidly), hop (1–3), leg per hop (1–2), apakah token input adalah jembatan terdaftar, apakah token perantara demikian, bentuk fee-on-transfer (tidak ada, hanya saat tarik, setiap transfer), desimal token input (18, 6), pintu (rute calldata, penyelesaian di dalam transaksi, Permit2), kendali (aktif, dilepaskan) dan apakah pasangan itu penuh — 5,184 kombinasi. `covering_array.py` menghasilkan array yang di dalamnya setiap pasangan (kekuatan 2) atau setiap tripel (kekuatan 3) nilai faktor muncul dalam setidaknya satu baris, setiap baris berupa satu fixture melalui satu harness (`test/regime/RegimeHarness.sol`) dengan satu asersi: swap diselesaikan, dengan jumlah yang dikirimkan sama dengan delta saldo penerima, setidaknya sebesar lantai yang dipancarkan Router, dan tidak ada yang tersisa di Router — atau swap ditolak dengan selector milik kami. Panic, selector asing, pengiriman kurang, atau saldo terdampar adalah jalan ketiga dan menggagalkan baris itu. | Kekuatan | Baris | Tupel yang dipenuhi | Diselesaikan | Ditolak, milik kami | Tidak dapat dibangun | Jalan ketiga | |---|---|---|---|---|---|---| | 2 | 63 | 258 pasangan | 53 | 4 | 6 | 0 | | 3 | 168 | 1,636 tripel | 158 | 10 — `SolverE(5)` ×7, `RouterE(13)` ×3 | 0 | 0 |  Penolakan-penolakan itu adalah perencana yang tidak memiliki jalur berjembatan untuk dibangun dan eksekutor yang menolak token berpajak pada rute yang hanya terkonsentrasi; enam baris pada kekuatan 2 yang tidak dapat dibangun (token yang dipajaki hanya saat tarik tidak memiliki bentuk enam desimal) dicetak berdasarkan nama dan dihitung terhadap penyebut. Keluarga yang tidak ada dalam array — V4, V4 native, Algebra, pintu native, hook — dinyatakan dalam `regimes-covering.json`. Jalannya array yang pertama membuat eksplisit sebuah frame yang oleh tes paritas hanya dipatok pada satu sisi: lantai yang ditegakkan Router sama dengan lantai teratestasi ketika biaya diambil dari output, dan berada di dalam $[\mathrm{attested} \times (1 - \mathrm{fee}), \mathrm{attested}]$ ketika biaya diambil dari input — kedua frame kini diasersikan pada setiap baris. Berkas yang dihasilkan diperiksa terhadap generatornya di CI, sehingga array tidak dapat menyimpang dari faktor yang diklaim dicakupnya. ### §15.5 Matriks venue bermusuhan Patologi token memiliki tesnya; patologi venue tidak memiliki satu pun dalam sebuah matriks. `test/regime/HostileVenues.sol` memuat satu perilaku menyimpang per venue dan `HostileVenueMatrix.t.sol` menyilangkan masing-masing dengan pintu calldata dan pintu penyelesaian menurut aturan covering array: | Venue | Pintu calldata | Pintu penyelesaian | |---|---|---| | tidak membayar apa pun / membayar setengah | ditolak `RouterE(5)` | ditolak `RouterE(5)` | | bom returndata pada pembacaan cadangan | diselesaikan | diselesaikan | | pembacaan cadangan menghabiskan seluruh gas | ditolak `RouterE(8)` | perencana tidak pernah memilihnya | | swap menghabiskan seluruh gas | seluruh transaksi di-revert, saldo tidak tersentuh | seluruh transaksi di-revert, saldo tidak tersentuh | | `decimals()` menghabiskan seluruh gas | diselesaikan | diselesaikan | | callback pembayaran dipicu dua kali | ditolak `RouterE(6)` | ditolak `RouterE(6)` | | masuk kembali ke Router sebelum membayar | diselesaikan; swap bersarang tidak pernah berjalan | diselesaikan; swap bersarang tidak pernah berjalan | | `slot0()` di-revert | diselesaikan pada kuotasi teratestasi | perencana tidak pernah memilihnya | | factory menjawab dengan pool pada token lain | tidak pernah didaftarkan | tidak pernah didaftarkan | Dua puluh dari dua puluh sel: diselesaikan atau ditolak dengan selector milik kami, tidak pernah jalan ketiga. Baris terakhir adalah apa yang diubah oleh jalannya matriks yang pertama — penemuan mendaftarkan pool yang dijawabkan oleh factory yang diterima kurator, dan eksekutor menolaknya pada sambungan yang membayar; pool yang ditanyakan kini membuktikan pasangannya sendiri sebelum penemuan mendaftarkannya (§7). ### §15.6 Oracle kanonis Setiap mock dalam suite memberi kuotasi dengan rumus Core sendiri, sehingga cacat dalam sebuah rumus tidak terlihat oleh setiap tes paritas yang menggunakannya: oracle-nya adalah objek itu sendiri. `test/regime/CanonicalOracles.t.sol` memuat tiga implementasi yang ditulis dari invarian yang dipublikasikan oleh venue — produk konstan dengan biaya pada input, langkah harga akar kuadrat satu-tick V3 dengan pembulatan pool itu sendiri yang merugikan trader, kurva stabil Solidly yang diselesaikan dengan metode Newton — dan melakukan fuzzing terhadap Core melawan ketiganya, masing-masing 5,000 kali jalan, mengasersikan arah terlebih dahulu (Core tidak pernah menjanjikan lebih dari yang diberikan matematika venue) dan keketatan kemudian. | Keluarga | Arah | Keketatan yang diukur | |---|---|---| | Uniswap V2 | Core tidak pernah melampaui spesifikasi | tepat sampai ke wei | | Solidly stabil | Core tidak pernah melampaui kurva lebih dari langkah terakhir solver itu sendiri | dalam 4 wei | | Uniswap V3 | Core tidak pernah melampaui spesifikasi lebih dari satu unit di tempat terakhir (ulp) harga akar kuadrat, senilai $L / 2^{96}$ wei | di bawah satu wei untuk setiap pool dengan $L < 2^{96}$ | Batas V3 dinyatakan dalam besaran yang menyebabkannya — pool membulatkan harga barunya dengan merugikan trader dan Core membulatkannya sekali, sehingga keduanya dapat berbeda satu unit $\sqrt{P}$ — dan asersinya adalah batas itu, bukan sampelnya (13 wei pada output $6.5 \times 10^{34}$ pada $L = 10^{30}$). Oracle-oracle itu ditulis dari spesifikasi, bukan dari bytecode venue; itulah batasnya. ### §15.7 Relasi metamorfik Oracle yang ditulis dari rumus yang sama tidak dapat menangkap kesalahan rumus itu. Relasi metamorfik justru menanyakan bagaimana output harus *bergerak* ketika input bergerak, dan kurva venue itu sendiri menjawabnya tanpa implementasi referensi. `test/CoreMetamorphicRelations.t.sol` memuat empat belas relasi atas matematika kuotasi Core dan `test/RouteMetamorphicRelations.t.sol` lima relasi atas rencana Solver pada semesta dua pool dengan Hub sungguhan dan Solver sungguhan: | Tingkat | Relasi | Apa yang dinyatakannya | |---|---|---| | Core, V2 · V3 · stabil | MR1 monoton | lebih banyak masuk, tidak pernah lebih sedikit keluar | | Core, V2 · V3 · stabil | MR2 sub-aditif | memecah order di pool yang sama tidak pernah menguntungkan | | Core, V2 · stabil | MR3 tanpa perjalanan pulang-pergi | masuk, lalu kembali pada cadangan yang diperbarui, tidak pernah mengembalikan lebih dari yang masuk | | Core, V2 · V3 · stabil | MR4 ekuivariansi skala | menskalakan order dan pool bersama-sama menskalakan output, hingga pembulatan | | Core, V2 · V3 | MR5 biaya monoton | biaya yang lebih tinggi tidak pernah membayar lebih | | Core, V3 | MR6 simetri arah | pada harga 1.0 kedua cabang `outV3` sepakat hingga dua ulp | | Core, Solidly | MR7 identitas | cabang volatil *adalah* `outV2`, satu produsen | | rencana | MR-R1 | pembagian tidak pernah membayar lebih sedikit daripada yang akan dibayar oleh satu pool terbaik | | rencana | MR-R2 | monoton dalam `amountIn` | | rencana | MR-R3 | menambahkan pool di dalam pita harga tidak pernah menurunkan rencana | | rencana | MR-R4 | urutan registrasi menggeser rencana paling banyak satu unit bobot pembagian | | rencana | MR-R5 | lantai teratestasi tidak pernah melampaui output yang diharapkan | Tiga dari batas itu diukur sebelum ditulis, dan angka dalam asersi adalah mekanismenya, bukan sampelnya. MR6: pada $L = 8.5 \times 10^{37}$ dan 1,374 wei masuk, satu cabang memberi kuotasi 1,073,741,823 wei — tepat $L / 2^{96}$, satu ulp — sementara cabang lainnya memberi kuotasi nol, langkahnya terbulatkan menjadi tidak ada, gagal secara tertutup; relasi itu menyatakan dua ulp, satu per cabang. MR-R1 dan MR-R3: dengan satu pool yang harganya berjarak $10^{10}$ dari yang lain, rencana membayar 35 % lebih sedikit daripada pool pencilan itu sendiri — median berbobot kedalaman menolak memercayainya — sehingga relasi-relasi itu berlaku atas pool yang diterima pita, dan domainnya menjaga kedua harga dalam ±4 %. MR-R4: pool yang bobot kedalamannya terpotong ke minimum dipertahankan sebagai leg debu ketika didaftarkan lebih dahulu dan dipangkas ketika didaftarkan kedua, menggeser rencana sebesar $3 \times 10^{-7}$ dari output — keputusan pembagian untuk mempertahankan atau memangkas pool berbobot minimum bergantung pada posisinya, dan hal itu kini tertulis di tempat ia ditemukan. ### §15.8 N-version: sumber yang sama di bawah pembangkitan kode lain Suite mengeksekusi satu biner — biner yang dihasilkan oleh pengaturan rilis, dan `profile_parity.py` menjaga suite tetap pada pengaturan tersebut. Setiap pengaturan optimiser lain adalah program berbeda yang dikompilasi dari sumber yang sama, dan kompiler adalah sebuah komponen. `test/nversion/` mengompilasi matematika kuotasi Core di bawah dua profil tambahan — `optimizer_runs` 1 dan 20,000, selebihnya identik — dan `NVersionCore.t.sol` men-deploy ketiga biner berdampingan dan mengasersikan kesamaan pada input yang di-fuzz: `outV2`, `outV3`, `outSolidly`, `outSolidlyStable`, `mulDiv`, `mulDivUp`, masing-masing 3,000 kali jalan atas seluruh domain input. Jalur ini pertama-tama mengasersikan bahwa bytecode alternatif *berbeda* dari yang dirilis, sehingga ia tidak dapat lulus dengan membandingkan sebuah program dengan dirinya sendiri, dan artefak yang hilang adalah kegagalan, bukan dilewati. **Ketiga biner sepakat.** Kompiler bukanlah temuannya. Jalannya jalur ini yang pertama atas seluruh domain membuat *referensi* di-revert: pemeriksaan kecocokan kurva stabil membagi `max · WAD / b`, dan pembagian itu sendiri mengalami overflow pada pool yang memegang kurang dari satu unit sebuah token; celah kedua — cadangan input sebesar paus melawan cadangan output sebesar debu — lolos dari pemeriksaan invarian dan membuat turunannya overflow. Keduanya bukan angka yang salah; keduanya adalah revert di dalam sebuah kuotasi, dan `universalQuote` adalah `DELEGATECALL` library, sehingga pool terdaftar yang memegang satu wei token output membatalkan rencana Solver untuk pasangannya. Perbaikannya (§6) mengajukan pertanyaan yang selama ini diwakili oleh pembagian itu dan masuk dengan merah terlebih dahulu; sebuah penjaga tambahan — batas atas iterasi Newton — ditulis, ternyata tidak dapat diamati oleh tes mana pun begitu kedua pemeriksaan berlaku, dan dihapus alih-alih dibawa. Kelasnya adalah kelas yang pertama kali disebut repositori ini — gagal-terbuka (fail-open) — ditemukan oleh instrumen yang tidak sedang mencarinya. ### §15.9 Jarak proyeksi Setiap cacat yang dikonfirmasi dalam repositori ini, internal maupun yang dilaporkan, memiliki satu bentuk: sebuah pemeriksaan mengamati satu objek sementara objek yang *berbeda* menentukan perilakunya. Hal itu menjadikan properti menarik dari sebuah penolakan bukan kompleksitasnya melainkan jaraknya — seberapa jauh apa yang dibacanya dari apa yang menentukan. `projection_distance.py` mengklasifikasikan predikat yang menjaga setiap `revert` dalam kelima kontrak: konstanta, immutable, delta saldo, atau besaran yang dihitung di dalam frame dari salah satunya berjarak 0; field dari rute pemanggil, atau pencarian dalam storage mutable kontrak lain, berjarak 1; properti dari kontrak yang dapat mendelegasikan perilakunya tidak terbatas. Atas 99 situs penolakan: **86 pada jarak 0, 11 pada jarak 1, 2 tidak terbatas.** Kedua situs tidak terbatas itu sama-sama berupa pin `EXTCODEHASH` — kode hook yang diterima dan kode factory yang diterima — dan keduanya tidak simetris: untuk hook, residunya ditutup oleh bit alamat yang tidak dibawa pin (§14.2); untuk factory tidak ada padanannya, dan residunya dibatasi oleh penerimaan pool, lantai per-leg dan minimum pengguna, sehingga kerusakannya berupa degradasi rute alih-alih pengurasan, terdokumentasi di situs itu. Batas penyaringan ini: ia membaca satu predikat dan tidak dapat melihat bahwa sebuah nilai telah dibatasi tiga frame di atasnya; field yang dideklarasikan pemanggil yang sekaligus menjadi pemilih pool berada pada jarak 0 hanya karena satu penugasan mengikat keduanya, dan penugasan itu dipatok oleh `test/V4SievedHookIsTheExecutedHook.t.sol`. ### §15.10 Independensi bukti, register besaran bersama, dan artefak Untuk setiap penjaga yang menanggung beban, aparatus mencatat berapa banyak konfirmasi *independen* yang ada — berdasarkan sumber, oracle, alat, lingkungan dan metodologi — dan melaporkan minimumnya, karena rantai bukti gagal pada mata rantainya yang terlemah; properti yang menanggung beban dikonfirmasi oleh setidaknya dua rute yang tidak berbagi hipotesis. Register besaran bersama (`SHARED_QUANTITIES.md`) mengenumerasi setiap besaran yang memiliki lebih dari satu produsen atau konsumen, menyatakan *pertanyaan* yang dijawabnya, dan menilai apa yang mengikat salinan-salinannya — `SINGLE`, `PINNED`, `WEAK`, `OPEN`, `UNVERIFIED` — dengan aturan CI yang menurunkan peringkat baris yang tesnya tidak menjangkau apa yang diklaim dipatoknya; setiap besaran dua-produsen dalam register relasional (7 dari 7) diikat oleh tes yang disebutkan namanya. Dan artefak hasil kompilasi juga dibaca, bukan hanya sumbernya: opcode yang tidak boleh pernah muncul (`SELFDESTRUCT`, `CALLCODE`, `ORIGIN`); opcode transien yang masih ada di eksekutor, sehingga kunci reentrancy tidak diam-diam menjadi storage persisten; setiap fungsi yang dideklarasikan ada di dispatcher; tiga dari lima kontrak tidak memancarkan satu pun penulisan storage; 88.3 % aliran instruksi berbentuk rilis terbukti dieksekusi oleh batas bawah yang sahih, diverifikasi terhadap kontrak kebenaran-dasar yang harus diklasifikasikan dengan benar oleh instrumen sebelum ia mencetak; dan, untuk satu swap V2 jujur yang terekam dan diputar ulang pada Router rilis dengan opcode diperiksa di setiap langkah, 4,382 instruksi Router dan 407 instruksi Hub berjalan, nol ketidakcocokan — 28.2 % dan 2.5 % dari kedua bagian kode, sisanya adalah kode yang tidak dijalankan oleh skenario terekam mana pun, bukan kode mati. ### §15.11 Apa yang tidak dibuktikan oleh semua ini - **Tidak ada probabilitas kebenaran.** Literatur tentang validasi keandalan ultra-tinggi secara eksplisit menyatakan bahwa pengujian tidak dapat menghasilkannya; tidak ada yang dinyatakan di sini. - **Kecukupan mutasi adalah kecukupan terhadap register ini.** Register ini dikurasi secara manual; skor yang jenuh adalah lantai. - **Cakupan ancaman dan regime adalah lantai atas apa yang telah dipertimbangkan.** Kelas dan faktor yang belum pernah disebut siapa pun berada di luar penyebut menurut konstruksinya. - **Distribusi pada §12 adalah atas mock.** Base langsung memberikan jangkauan, bukan distribusi. - **Tingkat deteksi adalah per tes pada 256 kali jalan fuzz per seed.** Tes yang meleset pada anggaran itu mungkin menangkap pada anggaran yang lebih besar. - **Repositori ini adalah V2, dan V2 belum di-deploy** (§19). Setiap instrumen di atas dikalibrasi sebelum angkanya dicetak: dijalankan terlebih dahulu terhadap cacat yang sudah diketahui melalui rute lain, dan dikoreksi bila ia melewatkannya — pencocok teks yang membaca dokumentasi sebagai perilaku karena mencocokkan teks di dalam komentar, regex cakupan yang tidak memperhitungkan blok call-option, pencarian padanan yang daftar polanya kosong. Sebuah instrumen tidak bernilai apa pun sampai ia menemukan instans yang sudah diketahui; vonis tanpa pencarian adalah kehampaan; dan apa pun yang ditentukan oleh kompiler diukur, tidak pernah diperkirakan. Kami tidak mengetahui codebase DeFi publik lain yang memublikasikan penjaga mutasi terkurasi dan bernama dengan tes pembunuh per mutan dan pelaporan mutasi inert; register besaran bersama dengan aturan CI yang menurunkan peringkatnya; mutan yang diarahkan pada invarian stateful-nya dengan yang bertahan dipublikasikan; covering array berkekuatan 3 atas faktor-faktor regime-nya di bawah satu asersi; pengujian N-version atas matematika kuotasinya; kurva terukur tentang bagaimana kuotasinya menua; atau tingkat deteksi mutan biayanya sendiri beserta selang kepercayaannya. Artefak-artefaknya ada di repositori; jika Anda menemukan instans sebelumnya, klaim ini salah dan kami ingin mengetahuinya. ## §16 Arsitektur dan ukuran *Sederhana:* lima kontrak, salah satunya adalah matematika murni yang diimpor oleh empat lainnya, dan tidak ada bagian matematika yang didefinisikan dua kali. *Presisi:* Core adalah library tanpa state, tanpa storage, tanpa pemilik dan tanpa jalur upgrade; Hub, Solver, Router dan Quoter mengimpornya dan tidak satu pun mendefinisikan ulang sebuah primitif, sehingga satu audit atas matematikanya mencakup setiap konsumen. ### §16.1 Lima kontrak: apa yang dipegang masing-masing, apa yang boleh dipanggil masing-masing | Kontrak | Memegang | Boleh memanggil | Menulis state persisten | Ukuran (byte runtime) | |---|---|---|---|---| | **Core** (library) | tidak ada — fungsi pure dan view: Ω, 𝒟, Φ, Ψ, codec Monoslot, transfer aman, `mulDiv` | pool dan token, hanya-baca, setiap `staticcall` yang dijaga dibatasi pada `GAS_CAP = 100,000` | tidak pernah — tanpa `tstore`, tanpa `sstore` | 6,442 | | **Hub** | registri (satu Monoslot per pool, ≤ 16 per pasangan), baris factory (≤ 16), jembatan (≤ 3), allow-list hook dengan pin codehash, entri V4, peran; ber-namespace ERC-7201 | pool dan factory, hanya-baca, melalui Core; PoolManager V4 melalui `extsload` | pada `recordSwap` (hanya Router), pada penerimaan dan konfigurasi | 23,648 | | **Solver** | tidak ada — hanya `view` | Hub (pembacaan registri, penemuan), pool melalui Core | tidak pernah | 19,686 | | **Router** | admin, treasury, `permit2`, `weth`, `paused`, `controlRenounced`, antrean penyelamatan; **tanpa saldo token saat diam** | token input, pool-pool rute, token output, Hub (`isBridgeToken`, `isHookLive`, `recordSwap`), Solver (hanya `swapBestExactIn`, `view`), WETH dan PoolManager untuk V4, Permit2 untuk pintunya, treasury, penerima — tidak pernah target yang dipasok pemanggil | konfigurasinya sendiri; satu-satunya penulisan eksternal per swap adalah `Hub.recordSwap` pada jalur sukses | 23,781 | | **Quoter** | tidak ada | Solver (`view`), Hub (`isBridgeToken`, hanya-baca), pool untuk dry-run Exact Pass (dipanggil lalu di-revert) | tidak pernah | 11,429 |  Kepercayaan mengalir satu arah. Hub memercayai Router untuk memanggil `recordSwap` (`onlyRouter`) dan tidak memercayai siapa pun lainnya; Router memercayai Hub untuk tiga fakta yang dibutuhkan sebuah rute — apakah token ini jembatan, apakah hook ini aktif, dan penulisan registrasi — dan tidak untuk apa pun yang menentukan harga sebuah perdagangan. Solver memercayai registri Hub hanya sebagai daftar koordinat untuk diukur. Quoter memperlakukan rencana Solver sebagai saran dan menghitung ulang harga leg terkonsentrasi terhadap pool itu sendiri. Tidak ada yang memercayai calldata: sebuah rute tiba di Router sebagai klaim orang asing. ### §16.2 Riwayat hidup satu swap  1. **Pratinjau** (off-chain, gratis): `previewAndEncode` menjalankan `findBestRoutePlan` — registri dan, jika tidak segar, penemuan; Ξ; peringkat Ψ; probe; pita; alokasi; clamp; gerbang pembagian; lantai teratestasi — dan mengembalikan `Preview` beserta calldata. Trader menetapkan `userMinOut` dari ekspektasi harganya sendiri. 2. **Pintu**: `swapExactIn` (atau saudaranya) memeriksa tenggat (`RouterE(4)`), menolak minimum nol (`RouterE(10)`), menarik input dan mengukur deltanya. 3. **`_execute`**: jumlah hop, leg per hop dan kesinambungan hop (`RouterE(3)`); pemindaian biaya; baseline lahir sekali. 4. **Per hop**: skalakan ulang terhadap kedatangan yang diukur; kenakan biaya jika ini hop biaya (atau setiap hop saat habis); baca setiap pool sekali untuk jumlah, dampak dan kuotasi; eksekusi setiap leg melalui bentuk yang dipilih oleh jenisnya (`RouterE(8)` untuk jenis yang tidak dikenal, `RouterE(9)` untuk hook yang mengubah delta); lantai per-leg dengan gerbang cakupan dan agregat hop (`RouterE(5)`); callback hanya membayar pool yang telah dikomitmenkan (`RouterE(6)`). 5. **Sapuan**: input yang tidak terpakai dan residu jembatan di atas baseline-nya dikembalikan kepada pembayar. 6. **Penyelesaian**: output bruto sebagai delta (`RouterE(8)` jika nol); `floorBps` dari dampak dan konsentrasi yang diukur; lantai rute terhadap kuotasi dalam-frame dari hop terakhir dan maksimum tiga arah (`RouterE(5)`); biaya sisi output pada rute langsung ke koin jembatan; transfer, pengiriman diukur di penerima, `userMinOut` atas jumlah yang dikirimkan (`RouterE(5)`); buku besar biaya (`RouterE(15)`, `RouterE(16)`). 7. **Satu-satunya penulisan**: `Hub.recordSwap` per leg yang dieksekusi, dengan jumlah yang diukur; lalu event `ExecutionProof`, `Swap` dan `Fee`. Tidak ada yang ditulis ketika ada pemeriksaan yang menolak; transaksi itu, termasuk swap di setiap pool, tidak pernah terjadi. ### §16.3 Ukuran terhadap EIP-170 | Kontrak | Byte runtime | Di bawah gerbang 24,000 byte | Di bawah EIP-170 (24,576) | |---|---|---|---| | Router | 23,781 | 219 | 795 | | Hub | 23,648 | 352 | 928 | | Solver | 19,686 | 4,314 | 4,890 | | Quoter | 11,429 | 12,571 | 13,147 | | Core | 6,442 | 17,558 | 18,134 | | Total | 84,986 | | |  Gerbang ini diasersikan di dalam suite itu sendiri (`DeployedSizeGate`) pada profil yang sama dengan yang digunakan suite, yang dijaga oleh `profile_parity.py` agar identik dengan profil rilis — suite yang menguji biner yang tidak dapat diterima chain akan menguji objek yang salah. Ukuran diukur, tidak pernah diperkirakan: sebuah penjaga yang diperkirakan berukuran puluhan byte pernah terukur beberapa ratus byte karena bentuk yang dipilih memperpanjang rentang hidup sebuah variabel. Router dan Hub berada dalam jarak beberapa ratus byte dari dinding, itulah sebabnya bukti pasangan pada §9 memakan 179 byte dan perbaikan kurva stabil pada §6 berukuran 35 byte *lebih kecil* daripada kode yang digantikannya: setiap byte yang ditambahkan dibayar dengan byte yang dihapus. ### §16.4 Permukaan serangan, dihitung Permukaan serangan adalah apa yang dapat ditulis oleh seorang lawan, apa yang dipegang sebuah kontrak, siapa yang dipanggilnya, dan siapa yang memegang kuasa atasnya. Masing-masing adalah besaran yang dapat dihitung di sini. **Apa yang dapat ditulis pemanggil.** Sebuah rute adalah struktur bertipe — paling banyak 3 hop × 5 leg, setiap leg sepuluh field (`pool`, `hooks`, `kind`, `fee`, `tickSpacing`, `zeroForOne`, `stable`, `amountIn`, `expectedOut`, `auxId`) — dan tidak ada field yang menyebut target pemanggilan atau membawa blob calldata. `docs/assurance/fields.json` mengklasifikasikan setiap field yang dapat ditulis pemanggil yang mencapai state, event atau penjaga, total 23: | Kelas | Jumlah | Makna | Contoh | |---|---|---|---| | **terkonfirmasi** | 14 | eksekusi membaca field itu *dan* sebuah pemeriksaan membandingkannya dengan sebuah pengamatan | `leg.kind` diturunkan ulang dari bentuk pool (Hub `recordSwap`); `leg.fee` pada pool terkonsentrasi, tempat pool menjawab; `leg.amountIn`, diskalakan ulang oleh kedatangan yang diukur; `leg.expectedOut`, dinaikkan oleh gerbang cakupan; `hop.tokenIn`/`tokenOut`, dijaga terhadap `token0`/`token1` milik pool itu sendiri; `leg.hooks` dan `leg.auxId` pada V4, yang masuk ke id pool yang dieksekusi | | **pengarah** | 5 | field itu mengarahkan perpindahan token, sehingga nilai palsu menghukum pemanggil dan tidak memerlukan pemeriksaan terpisah | `leg.pool` pada venue pair dan terkonsentrasi (token didorong ke sana); `leg.zeroForOne` pada V4 (arah yang salah gagal secara tertutup dalam akuntansi manager); `route.singleOutFloor` (monoton — hanya dapat memperketat); field rute yang bersifat saran (`totalOut`, `estGas`, …), tidak dibaca oleh siapa pun | | **dideklarasikan** | 4 | field itu mencapai state, event atau penjaga, dan tidak ada yang mengamatinya — masing-masing dengan alasannya tercatat | `leg.fee` pada pair V2 (tidak ada pair yang mengekspos `fee()`; dibatasi oleh plafon 100 bps dan digunakan oleh kuotasi maupun eksekusi, sehingga keduanya tidak dapat menyimpang); `leg.hooks` pada leg non-V4 (hanya memengaruhi pengurutan hook-terakhir; kebohongan merugikan rute pemanggil itu sendiri); `leg.expectedOut` sebagaimana dipublikasikan dalam event `Volume` (dibatasi di sekitar +25 % oleh lantai per-leg yang mengonsumsi field yang sama; tidak ada konsumen on-chain); `leg.stable` (Hub mengukur `stable()` saat registrasi dan kedua konsumen membaca deklarasi yang sama) | Peringkat registri, lantai protokol dan basis biaya dihitung hanya dari besaran yang terkonfirmasi. Hub mengonfirmasi `kind`; Router mengonfirmasi jumlah, token dan biaya terkonsentrasi; penurunan mengonfirmasi field V4 menurut konstruksinya. **Apa yang dipegang Router di antara transaksi.** Saldo token nol — `INV-1`, diasersikan oleh `invariant_RouterHoldsNothing`, `invariant_routerHoldsNothing` dan `invariant_HoldsNothingBeyondTheSeed` di seluruh kampanye, dan diawasi oleh empat mutan penjaga (transfer yang kurang satu wei, dan masing-masing dari tiga baseline dihapus). Biaya mengalir ke treasury di dalam swap; residu kembali kepada pembayar di dalam swap; satu-satunya hal yang dapat tersimpan di Router adalah kiriman yang salah alamat, yang dikembalikan melalui mekanisme penyelamatan 48 jam dan yang dikecualikan dari pembayaran oleh baseline setiap swap. Tiga dari lima kontrak — Core, Solver, Quoter — sama sekali tidak memancarkan penulisan storage. **Siapa yang dipanggil sebuah swap.** Pihak lawan dari satu swap membentuk himpunan tertutup delapan kelas: token input; token output; pool yang disebut oleh rute (paling banyak 15); Hub; Solver, hanya melalui `swapBestExactIn` dan hanya sebagai view; WETH dan PoolManager, hanya untuk leg V4 dan native; Permit2, hanya melalui pintunya; treasury dan penerima. Tidak ada kelas kesembilan: eksekutor tidak menerima target pemanggilan yang dipasok pemanggil (SOK-ARBITRARY-CALL), dan mengirimkan interaksi venue dari himpunan bentuk tertutup yang dipilih oleh jenis yang disimpan registri. Setiap pembacaan yang dijaga dibatasi pada 100,000 gas. Jumlah instruksi persis dari sebuah swap dicatat alih-alih diasersikan: 4,382 instruksi Router untuk satu swap V2 jujur pada biner rilis, dengan opcode diperiksa di setiap langkah (§15.10). **Siapa yang memegang kuasa.** Sembilan fungsi kendali pada Router dan enam pada Hub, masing-masing dienumerasi dalam §14.6–§14.7 beserta apa yang dapat dan tidak dapat dijangkaunya; tidak satu pun dapat memindahkan pokok, biaya, pembagian, atau lantai; semuanya berakhir pada `renounceControl`, dan yang tersisa adalah tingkat kurator yang hanya-bisa-bertambah berisi empat fungsi ditambah kursi operator yang sudah ada. Tidak ada `selfdestruct`, tidak ada proxy, tidak ada initialiser setelah `initialize` satu kali milik Hub, dan satu-satunya `delegatecall` dalam artefak adalah milik kompiler sendiri ke library Core publik. **Apa yang harus ada agar sebuah perdagangan diselesaikan.** Anggaran pada §3.1: tidak ada layanan perutean, tidak ada oracle, tidak ada jaringan solver, tidak ada keeper, tidak ada proxy — lima nol di tempat desain petahana mencantumkan "wajib", "umum" atau "bervariasi". **Perbedaan yang dihitung.** Terhadap desain yang mengambil rutenya secara off-chain dan mengeksekusi daftar pemanggilan generik, atau yang memegang inventaris: | Permukaan | Desain ini | Eksekutor yang diselesaikan off-chain | Venue atau router yang memegang inventaris | |---|---|---|---| | field yang dapat ditulis pemanggil yang mencapai penjaga | 23, dengan 14 terkonfirmasi terhadap pengamatan dan 0 menyebut target pemanggilan | daftar pasangan `(target, calldata)`: tidak terbatas, dan setiap target adalah pemanggilan yang dilakukan kontrak atas perkataan pemanggil | — | | saldo token saat diam di eksekutor | 0 (`INV-1`) | biasanya 0 | inventaris itu sendiri | | kontrak yang menulis storage selama swap | 1 (`Hub.recordSwap`, satu penulisan per leg yang dieksekusi, hanya jalur sukses) | bervariasi | akuntansi venue | | siapa yang menghitung rute | chain (`findBestRoutePlan`, `view`) atau pemanggil, diukur ulang di dalam frame dalam kedua kasus | sebuah server; kontrak memeriksa, tidak memilih | — | | oracle, keeper, proxy, jalur upgrade | 0 | umumnya ≥ 1 dari masing-masing | umumnya sebuah proxy | | fungsi istimewa yang dapat menjangkau pokok | 0 | admin proxy dapat mengganti logika | bervariasi | | byte ter-deploy yang harus dibaca auditor | 84,986, lima kontrak, semuanya di bawah EIP-170 | kontrak penyelesaian, ditambah sebuah server yang ukurannya dalam baris yang dapat diaudit tidak dapat diketahui | — | Perbandingan ini dihitung, bukan diperdebatkan: perbedaannya adalah rute yang terbatas, bertipe dan terkonfirmasi melawan daftar yang tidak terbatas; nol melawan inventaris; satu penulisan melawan banyak; dan rute yang diturunkan oleh chain — atau diturunkan oleh pemanggil lalu diukur ulang oleh chain — melawan rute yang diturunkan oleh server dan hanya diperiksa oleh chain. ## §17 Kinerja terukur *Sederhana:* semua yang ada di bagian ini diukur pada fork chain sungguhan — venue sungguhan, cadangan sungguhan yang disetorkan oleh orang-orang yang tidak dikenal, satu bytecode — dan diberi label persis seperti itu. *Presisi:* sebuah angka hanya muncul di sini jika sebuah harness publik di repositori mereproduksinya; harness, chain, dan tanggalnya dicetak di sampingnya. Pengukuran fork adalah bukti tentang perilaku, bukan catatan deployment; catatan deployment ada di §19. Pengukuran §12 dan §15 berasal dari 2026-09-05; kampanye bagian ini dijalankan pada Agustus 2026 dan harness-nya berada di `test/fork/`. ### §17.1 Identitas lintas chain Bytecode yang sama diuji pada fork Ethereum, Arbitrum, Optimism, dan Base, menyesuaikan diri dengan bauran venue setiap chain — Aerodrome dan Pancake di samping V4 di Base, Camelot di Arbitrum, Velodrome di Optimism — tanpa perubahan kode per chain. Keempat chain itu dipilih karena bersama-sama mereka menguji setiap keluarga venue yang diterima registri, sehingga sebuah kasus khusus per chain, seandainya ada, memiliki empat kesempatan untuk muncul. Di setiap chain, dua identitas diukur terhadap kebenaran dasar (ground truth): untuk penurunan CREATE2, setiap alamat pool yang dihitung oleh 𝒟 dibandingkan dengan alamat yang dilaporkan oleh factory milik chain itu sendiri untuk pasangan dan parameter yang sama, dengan `hasCode` mengonfirmasi adanya bytecode di setiap alamat yang diturunkan; untuk Exact Pass, swap milik venue itu sendiri dipanggil atas state live dan delta-deltanya dibawa keluar dalam payload revert, per chain, bertahan melewati konvensi callback setiap keluarga, termasuk milik Algebra. Kedua identitas berlaku di keempat chain, dan kolom selisih yang akan dibutuhkan tabel itu kosong. ### §17.2 Fidelitas pratinjau → pengiriman di empat chain Tesis ini memungkinkan pengukuran langsung: berikan kuotasi untuk sebuah swap, eksekusi, lalu bandingkan. Harness fork `FidelityMatrix` memberikan kuotasi, mengeksekusi, dan menyelesaikan pasangan-pasangan sungguhan di Arbitrum, Base, Optimism, dan Robinhood Chain pada blok yang dipatok, dan mencetak pratinjau terhadap pengiriman untuk setiap pasangan yang disentuhnya; harness ini membawa alarm permanen pada 50 bps, sehingga regresi fidelitas akan mengumumkan dirinya sendiri. Diukur 2026-08-24: | Chain | Pratinjau → pengiriman | Dicatat bersamaan | |---|---|---| | Arbitrum | 0–1 bps pada setiap pasangan yang dieksekusi | rute Solver cocok dengan grid pembagian dua arah yang menyeluruh dalam langkah 10 % | | Base | 0–1 bps | dalam 0.13 bps dari maksimum grid; fill sungguhan 222,000–326,000 gas secara keseluruhan | | Optimism | 0–1 bps | eksekusi dengan perutean V4 pertama yang diukur di fork oleh mesin ini di Optimism | | Robinhood Chain | 0–1 bps | tepat sesuai grid; eksekusi terukur pertama di chain ini | Matriks ini mengeksekusi leg constant-product, terkonsentrasi, V4 — termasuk native — dan Solidly dari ujung ke ujung. Pitanya adalah satu basis poin pada setiap pasangan yang dieksekusi, dengan alarm 50 bps di belakangnya; perbandingan Solver-versus-grid dari §17.1 adalah satu-satunya hasil yang cocok pada tingkat satuan, dan hal itu dinyatakan apa adanya. Dua hasil perilaku menyertainya: perantara koin jembatan dipilih secara adaptif per pasangan sebagai pemaksimal Meta-Persamaan, dan sebuah pasangan yang sengaja diisolasi tidak menghasilkan rute alih-alih rute yang dibuat-buat. ### §17.3 Sensus factory Pendaftaran venue adalah sebuah klaim, dan klaim itu memiliki instrumennya sendiri. Harness sensus (`FactoryCensus`) mewarisi wiring deployment produksi — ia melakukan deployment melalui skrip yang sama yang diterima chain-chain tersebut, di balik gerbang kesetaraan yang menolak berjalan jika harness dan deployment menyimpang. Harness ini berada bersama skrip tersebut di pohon deployment privat dan tidak ada di repositori publik, sehingga tabel di bawah ini dilaporkan, bukan dapat direproduksi dari checkout ini; sapuan publik yang berbagi fixture dan gerbang anti-kekosongan (anti-vacuity) dengannya adalah `test/fork/TokenSweep.t.sol`. Harness ini melaporkan, untuk setiap factory terdaftar di setiap chain atas korpus token yang tetap, tiga kolom: terdaftar, memiliki pool untuk pasangan tersebut, memenangkan pasangan tersebut (menyediakan sebuah leg dari rute pemenang). Kolom-kolom itu berbagi satu penyebut, pasangan-hop, dengan kelompok tak terselesaikan yang eksplisit yang terukur nol di keempat chain: setiap leg yang dirutekan mesin diatribusikan ke factory yang bernama. | Arbitrum, 88 pasangan-hop | Memiliki pool | Memenangkan pasangan | |---|---|---| | Uniswap V4 (native + wrapped) | 67 | 48 | | Uniswap V3 | 86 | 33 | | Pancake V3 | 77 | 13 | | Camelot V3 | 66 | 10 | Sebuah pasangan memberi kredit kepada setiap venue yang menyediakan sebuah leg dari rute pemenangnya, sehingga kolom tersebut dapat melebihi jumlah pasangan — atribusi, bukan partisi. Di Arbitrum, keluarga V4 memenangkan lebih banyak pasangan daripada venue terdaftar lainnya, termasuk factory V3 kanonis — konfirmasi dari luar atas urutan probe native-terlebih-dahulu dari §5.1. Sensus ini juga merupakan instrumen pemangkasan: factory yang terdaftar, memiliki pool, dan tidak memenangkan apa pun selama ratusan pasangan terukur adalah kandidat pensiun yang dinilai berdasarkan atribusi, bukan reputasi, dan setiap sapuan membawa gerbang anti-kekosongan — pasangan yang dilaporkan memiliki kedalaman juga harus memberikan kuotasi bukan nol. ### §17.4 Gas Setiap angka dapat ditelusuri ke harness yang bernama, dengan kondisi dingin (cold) dan hangat (warm) dilaporkan secara terpisah. | Pengukuran | Nilai | Sumber | |---|---|---| | solve dingin (penemuan pertama, 4 factory) | 169,093 gas | `test/fork/DiscoveryColdWarm.t.sol`; `REPORTS.md` | | solve hangat (Monoslot dalam cache, penemuan dilewati) | 132,691 gas | run yang sama | | penghematan hangat | −36,402 gas (−21 %) | selisih | | biaya marginal per leg tambahan | ≈ 28,700 gas | `LifecycleMetrics` (Agustus 2026) | | hop kedua melalui koin jembatan | ≈ 59,000 gas | `LifecycleMetrics` (Agustus 2026) | | `previewPlan` di Base live, dingin / hangat / dingin setelah TTL | 1,524,221 / 1,414,633 / 1,359,925 gas | `test/fork/QuoterGasFork.t.sol` (§12.3) |  Tiga pembacaan struktural berlaku tanpa pengukuran apa pun, karena semuanya mengikuti dari arsitektur. Penghematan hangat berskala dengan keluasan registri, bukan dengan ukuran transaksi: yang dibayar oleh jalur dingin adalah penyapuan factory, dan pembacaan dari cache yang menggantikan sapuan itu tetap satu `SLOAD`. Leg adalah satuan biaya marginal, itulah sebabnya gerbang pembagian ada (§10.4). Dan hop adalah dimensi yang mahal: rute koin jembatan harus menang dengan selisih yang cukup di pool untuk membayar dirinya sendiri di pompa. Pemanggil memilih titik mereka pada permukaan ini per transaksi — melakukan solve di dalam frame dan membayar pencariannya, atau menyediakan rute dan hanya membayar eksekusinya — dan gerbang kesegaran §9.4 menyisihkan sapuan untuk pasangan yang belum dikenal protokol. Biaya sebuah kuotasi live adalah 1.4–1.5 juta gas komputasi *view*, yang tidak dibayar oleh siapa pun di on-chain. ### §17.5 Eksekutor dibandingkan dengan para pesaing Tabel gas tanpa rujukan eksternal adalah pujian diri sendiri, sehingga lapisan eksekusi di-benchmark pada fork yang sama, pada blok yang sama, dengan calldata produksi sungguhan: `MetaAggregationRouterV2` milik KyberSwap (`0x6131B5fae19EA4f9D964eAc0408E4408b66337b5`), pada fork Base yang dipatok ke blok tempat setiap rute dibangun, pada 2026-08-22, dengan Paraswap dikuotasi bersamaan sebagai pembanding kedua: rute-rute terenkode milik Kyber sendiri, diminta dari API publiknya dan diputar ulang terhadap kontraknya yang telah di-deploy, dengan rute kami dieksekusi di sampingnya dan pengiriman kedua belah pihak diukur sebagai delta saldo. Harness ini memvalidasi dirinya sendiri terlebih dahulu: pengiriman terukur milik pesaing cocok dengan janji API-nya hingga ke wei, sehingga revert di sisi mana pun tidak dapat menyamar sebagai hasil. Per leg, eksekutor terukur 2.4× hingga 10.9× lebih efisien gas dibandingkan rujukan — pada pasangan yang paling jelas 322,172 gas untuk empat leg dibandingkan 879,553 untuk satu leg, 2.7× per transaksi — oleh sebuah harness (`BenchExec.t.sol`) yang berada bersama calldata yang ditangkap di pohon privat, sehingga angka-angkanya dilaporkan, bukan dapat direproduksi dari checkout ini, yang dikompilasi pada `optimizer_runs = 999999` — sehingga perbedaannya adalah desain, bukan pengaturan compiler; router mereka menafsirkan daftar panggilan generik yang diputuskan oleh sebuah server, router kami mengeksekusi struktur bertipe, dan penafsiran itu memakan biaya. Pada pasangan yang paling jelas, rute satu leg mereka memakan 879,553 gas; empat leg kami memakan 322,172. Di sembilan pasangan terukur, pintu yang melakukan solve sepenuhnya dan pintu calldata menghasilkan output yang identik. Batas galat metode ini adalah bagian dari hasil: kuotasi dipatok ke blok tempat kuotasi itu dibangun, dan estimasi gas dari sisi API dibuang setelah eksekusi sungguhan mengukur salah satunya 148 % terlalu rendah. ### §17.6 Kurs byte–gas ρ* Pintu mana yang sebaiknya digunakan pemanggil — membawa rute dalam calldata, atau membiarkan chain melakukan solve? Biaya sebuah transaksi bersifat afin dan dapat dipisahkan — $21{,}000 + \mathrm{bytes} \cdot p_{\mathrm{byte}} + \mathrm{gas} \cdot p_{\mathrm{gas}}$ — sehingga seluruh pertukaran antara calldata dan eksekusi tereduksi menjadi satu skalar: **ρ\***, gas eksekusi yang dapat dibeli oleh satu byte calldata. Diukur dengan `test/EquationBench.t.sol` pada profil rilis, ρ* berkisar dari 66.9 gas per byte pada rute satu leg hingga 105.5 pada rute empat dan lima leg, untuk transaksi utuh. Di hadapannya berdiri harga byte live setiap chain, dibaca dari predeploy biaya milik chain itu sendiri — oracle harga gas OP-Stack, `ArbGasInfo` milik Arbitrum — tanpa kunci dan tanpa feed pihak ketiga. | Chain, harga dibaca live 2026-08 | $p_{\mathrm{byte}}$ (gas/byte) | Porsi data dari sebuah swap | Pintu yang murah | |---|---|---|---| | Base | 7.2 | 0.9 % | rute calldata | | Arbitrum | 12.8 | 3.4 % | rute calldata | | Optimism | 33.9 | 14.0 % | rute calldata | | ZK rollup yang membayar ketersediaan data berharga calldata | 243,256 | 99.9 % | solve di dalam frame — 14× lebih murah dari ujung ke ujung | Ketika $p_{\mathrm{byte}} < \rho^{*}$, pintu calldata adalah yang murah; ketika $p_{\mathrm{byte}} > \rho^{*}$, solve di dalam frame-lah yang murah. Di chain OP-Stack dan Arbitrum, suku data adalah 0.9–14 % dari biaya sebuah swap, sehingga eksekusilah tempat uang dihabiskan — dan di situlah efisiensi eksekutor di atas berlipat ganda. Empat pintu Router bukanlah fitur kenyamanan; keempatnya adalah model biaya afin yang dijadikan antarmuka. ## §18 DEX, dikupas hingga ke tulangnya Tujuh belas bagian mekanisme tereduksi menjadi satu halaman. Jika Anda tidak membaca bagian lain, bacalah ini. **Satu tugas.** Ambil dua token, sebuah jumlah, minimum Anda, seorang penerima, dan sebuah tenggat. Kembalikan output terbanyak yang dapat dihasilkan likuiditas publik chain tersebut — atau tolak, dengan kode yang menjelaskan alasannya. Tidak ada hasil ketiga: dalam matriks venue-bermusuhan, dua puluh dari dua puluh fixture patologi-venue-dan-pintu menyelesaikan transaksi di dalam lantai atau menolak dengan selector milik kami (§15.5). **Lima kontrak, satu matematika.** | Kontrak | Apa itu, dalam satu baris | |---|---| | **Core** | Pustaka tanpa state: bentuk tertutup setiap venue, penurunan 𝒟, lantai Φ, skor vitalitas Ψ. Didefinisikan sekali, diimpor oleh empat kontrak lainnya. | | **Hub** | Registri yang mempelajari likuiditas dengan memperdagangkannya — dan membuktikan setiap pasangan sebelum menyimpannya. Ia tidak memberi harga apa pun. | | **Solver** | Membangun rute dan pembagian dari output marginal dan kedalaman yang *terukur*. Hanya `view`. | | **Router** | Satu-satunya kontrak yang memindahkan dana. Mengukur setiap delta saldo, menegakkan lantai, tidak menyimpan apa pun saat diam. | | **Quoter** | Pratinjau gratis — evaluator yang sama dengan yang digunakan Router untuk penyelesaian, sehingga pratinjau dan pengiriman selaras. | **Enam jenis venue, empat keluarga.** Uniswap V2, V3, dan V4 (termasuk ETH native), pool biaya dinamis Algebra, serta pasangan stable dan volatile Solidly — masing-masing diberi harga oleh satu bentuk tertutup di Core, satu dispatcher Ω untuk semuanya (§4). Curve dan Balancer telah dikeluarkan, dan nomor jenis mereka dipensiunkan untuk selamanya (§4.1). **Empat pintu, satu eksekutor.** `swapExactIn`, `swapExactInWithPermit2`, dan `swapExactInNative` menerima rute dalam calldata; `swapBestExactIn` melakukan solve dan eksekusi secara atomik di on-chain. Keempatnya mencapai `_execute` yang sama, lantai yang sama, dan biaya yang sama (§11.1). **Tiga lantai di bawah setiap transaksi.** Lantai per leg, agregat hop, dan lantai rute Φ yang diturunkan ulang dari dampak terukur di frame eksekusi — lalu `userMinOut` *Anda* atas apa yang benar-benar tiba di penerima. Pengiriman adalah yang lebih besar antara lantai protokol dan lantai Anda (§11.5). **Satu biaya, dikompilasi di dalamnya.** 0.28 %, dikenakan sekali pada koin jembatan pertama yang dipegang Router, dibulatkan ke atas sehingga tidak pernah nol, dan tidak ada apa pun yang tumbuh seiring selisih antara kuotasi dan pengiriman (§13). **Apa yang ditolaknya untuk dipercaya.** Likuiditas yang diiklankan. Biaya yang dideklarasikan. Kedalaman dari calldata. Pengakuan pool sendiri tentang token mana yang diperdagangkannya. Masing-masing diukur dari pool atau diturunkan secara aritmetis sebelum dapat mencapai state bersama (§7, §9, §16.4). **Berapa biayanya.** Gas: menurunkan rute di dalam frame lebih mahal daripada menyelesaikan jawaban yang dihitung di tempat lain, dan §17.6 memberi tahu Anda per chain pintu mana yang paling murah. Imutabilitas: cacat diungkapkan dan diberi bounty, tidak pernah ditambal (§21). ## §19 Status deployment Makalah ini mendokumentasikan repositori, dan repositori itu bersifat kanonis: ketika teks ini dan kode sumber tidak sepakat, kode sumberlah yang menang. Ada dua generasi dan keduanya tidak pernah dicampuradukkan. **V1 adalah yang live di on-chain.** Ini adalah basis kode yang berbeda dan lebih awal, diarsipkan di repositorinya sendiri — bukan commit yang lebih awal dari repositori ini. Diukur melalui RPC pada 2026-09-04, router V1 yang telah di-deploy adalah kontrak 14,624 byte yang sama di Base, Ethereum, Optimism, dan Arbitrum. `test/fork/DeployedParity.t.sol` dan `test/fork/DeployedCodehashPin.t.sol` mematok apa V1 itu, di setiap jaringan yang disebut SDK — codehash setiap kontrak yang telah di-deploy, dicatat dalam `test/fork/deployed-codehash.json` — sehingga perubahan pada apa yang di-deploy akan diketahui, dan keduanya menegaskan properti yang berlaku terlepas dari generasinya: tidak ada `SELFDESTRUCT`, tidak ada `CALLCODE`, tidak ada otoritas `tx.origin`, kunci reentrancy transien, ukuran runtime yang tetap, wiring live, dan kendali yang belum dilepaskan. **Repositori ini adalah V2, dan V2 belum di-deploy.** Pohon yang diukur dalam makalah ini membangun Router berukuran 23,781 byte dan memuat fungsi eksternal yang tidak dimiliki V1 — di antaranya pintu nilai native, sambungan wrap/unwrap, jalur penyelamatan, dan pintu Permit2. Kontrak V2 di-deploy ke fork likuiditas live dan diuji dari ujung ke ujung pada setiap run fork (§15.1, §17). Tidak ada apa pun di §15 atau §17 yang melindungi kontrak V1 yang telah di-deploy; setiap klaim dalam makalah ini adalah klaim tentang V2 sebagaimana adanya pada `8949a9d`. Karena itu, dua kebijakan melindungi pembaca. Makalah ini tidak memuat alamat kontrak — alamat hidup lebih lama daripada dokumen yang mengutipnya, dan permukaan alamat live dipelihara di tempat yang dapat diperbarui dan diperiksa mesin: catatan repositori serta halaman verifikasi dan manifest situs. Dan catatan deployment memiliki format yang ditentukan — chain, alamat, commit yang melakukan deployment, dan hash bytecode runtime, ditulis pada saat broadcast, dengan langkah verifikasi yang menurunkan ulang hash dari build yang bersih — sehingga ketika V2 di-deploy, setiap klaim alamat adalah aritmetika, bukan kepercayaan. ## §20 Token — BZPX Satu miliar BZPX, tetap untuk selamanya, sebagai ERC-20 biasa: 18 desimal, tanpa jalur mint, tanpa biaya-saat-transfer, tanpa rebasing, tanpa hook transfer, tanpa jeda atau daftar hitam — enam invarian deployment, diperiksa terhadap bytecode token pada saat wiring. Pasokan terdilusi penuh diketahui sejak genesis; kelangkaan adalah properti kontrak, bukan kebijakan. | Alokasi | Token | Porsi | Catatan | |---|---|---|---| | Likuiditas pasar | 520,000,000 | 52.0 % | float yang dirutekan oleh agregator | | Emisi staking | 180,000,000 | 18.0 % | dicadangkan; desain emisi V4 ada di §25 | | Airdrop & Bounties | 130,000,000 | 13.0 % | satu pool: bekas airdrop 50,000,000, bekas pool riset 50,000,000 dari §21, dan 30,000,000 yang dipindahkan dari likuiditas pasar | | Tim dan operasional | 103,000,000 | 10.3 % | satu-satunya tranche orang dalam yang dikunci; vesting linear 30 bulan | | Mitra dan ekosistem | 60,000,000 | 6.0 % | integrasi, kemitraan venue | | Pemasaran | 7,000,000 | 0.7 % | membangun kesadaran saat peluncuran | **Apa yang berubah pada September 2026.** Airdrop dan pool riset keamanan dahulu merupakan dua baris yang membayar orang yang sama untuk hal yang sama — membaca protokol secara keras dan menggunakannya secara sungguhan. Keduanya kini menjadi satu baris sebesar 130,000,000 BZPX: 50,000,000 dari airdrop, 50,000,000 dari pool riset, dan 30,000,000 yang diambil dari likuiditas pasar, yang berubah dari 550,000,000 menjadi 520,000,000. Tidak ada yang diambil dari baris milik pihak lain, dan pasokannya tetap tepat satu miliar. Catatan on-chain kontrak token, setelah dipublikasikan, adalah versi kanonis dari tabel ini. Pada saat penulisan, token ini belum memiliki likuiditas yang disediakan dan belum ada peristiwa pembuatan token (token generation event); volume on-chain sebesar nol adalah keadaan yang diharapkan pada tahap ini, bukan sinyal tentang kodenya. ## §21 Program riset dan catatan keamanan Sebelum proyek ini memiliki program riset yang layak disebut demikian, para peneliti independen membaca kode sumbernya secara bermusuhan — tanpa diminta, tanpa dijanjikan apa pun — dan mengungkapkan apa yang mereka lihat secara privat. Kode yang dijelaskan makalah ini adalah kode yang bertahan dari pembacaan mereka. Apa yang dilaporkan masing-masing dari mereka, dan apa yang terjadi dengannya, berada di tempat catatan semacam itu seharusnya berada: di `SECURITY.md` dan `SECURITY_HALL_OF_FAME.md` milik repositori, di samping kode, tempat setiap entri dapat diperiksa ke dua arah. Bagian ini mencatat siapa mereka, berapa bayaran untuk pembacaan yang bermusuhan, dan bentuk dari apa yang ditemukannya. **Para peneliti.** NetGakarot · duxun · AmanDara1 · amitbhakar · auditor_1b3f2c · siam siddik · Thomas · llen · destinyae · superagent · Mohd Huzaifa · Raditya · bai bo · Josh W · Borutobro · mohaseenkatika · mohaseenbasha · Karan Rathod · Seavia Resources · acit aja · Brian Wahyu · M2000 Slash · Binod Bk · CHARIR ABDELHAMID · dan satu peneliti yang memilih untuk tetap anonim. Dua puluh lima peneliti telah diberi kredit; belum ada laporan yang mencapai kelas Critical. Atribusi tidak pernah dibulatkan ke bawah: nama-nama dipublikasikan persis sebagaimana diberikan. **Pool: Airdrop & Bounties, 130,000,000 BZPX — 13 % dari pasokan tetap** (§20). Penghargaan keamanan diambil darinya sesuai rentang di bawah ini, yang tidak berubah. | Tingkat keparahan | Penghargaan | |---|---| | Critical — pencurian langsung atau pembekuan permanen dana pengguna; keadaan insolven yang dapat dicapai | 2,500,000 – 7,500,000 BZPX | | High — pencurian dalam kondisi tertentu; redistribusi yang secara sistematis membayar pihak yang salah | 625,000 – 2,500,000 BZPX | | Medium — griefing, penolakan layanan sementara, residu yang dapat dipulihkan | 125,000 – 625,000 BZPX | | Low — dampak yang didemonstrasikan di bawah tingkat di atas | hingga 125,000 BZPX | Penghargaan dibayarkan dalam BZPX — kuantitas dan jadwalnya dijanjikan, nilai pasarnya tidak — dengan pembayaran dimulai setelah Oktober 2026 dan laporan ditriase sekarang. Satu klausul disengaja: sebuah laporan tidak perlu melanggar hukum kekekalan untuk menjadi Critical — redistribusi yang secara sistematis membayar pihak yang salah sementara pembukuan tetap seimbang dihargai seperti pencurian, karena itulah kelas yang hanya tertangkap oleh pembaca yang bermusuhan. **Apa isi catatan tersebut, menurut kelasnya.** Setiap temuan yang dikonfirmasi menjadi sebuah properti bernama, sebuah uji regresi yang gagal terhadap kode sebelum perbaikan, dan sebuah mutan yang harus dibunuh oleh uji tersebut; kelas-kelasnya, masing-masing satu kalimat, dengan rujukan ke register: - *Dua produsen untuk satu kuantitas* — sebuah perencana dan sebuah eksekutor, sebuah pratinjau dan sebuah pengiriman, menjawab satu pertanyaan dalam dua frame (agregasi dampak pada lantai, koin jembatan yang disebut oleh pratinjau dibandingkan dengan hop tempat biaya berjangkar, anggaran leg di dua kontrak, bit koin jembatan yang dibekukan dibandingkan dengan predikat live): ditutup dengan meleburkannya menjadi satu produsen atau dengan uji paritas bernama, dan didaftarkan sebagai register dengan aturan CI. - *Kuantitas yang dipasok pemanggil padahal ada pengukuran* — basis biaya yang dibaca dari `route.totalOut`, biaya dan hook registri yang ditulis dari calldata, kedalaman yang dideklarasikan alih-alih diukur, volume terpublikasi yang melaporkan deklarasi: ditutup dengan mengukur, dan dengan klasifikasi field dari §16.4. - *Ketiadaan dibaca sebagai izin* — hop terakhir yang tidak dapat dikuotasi di dalam frame sehingga membuat lantai tidak aktif, gerbang cakupan yang dapat dimatikan pemanggil dengan menulis nol, daftar biaya kosong yang mengkuotasi seluruh keluarga pada nol: ditutup dengan kembali ke angka yang diatestasi atau diukur, tidak pernah ke ketiadaan. - *Patokan pada objek yang salah* — asal penurunan sebuah factory yang dapat dipindahkan oleh proxy sementara codehash-nya tetap, runtime sebuah hook yang dipatok padahal implementasinya dapat berpindah: ditutup dengan mengatestasi jawabannya ketika kodenya tidak dapat dipatok, dan dengan menyatakan residunya di lokasi yang tidak dapat ditutup. - *Fail-open dalam kuotasi* — penjaga domain kurva stable yang justru mengalami overflow pada dust, ditemukan oleh jalur N-version: ditutup dengan pendekatan merah-terlebih-dahulu, dengan perbaikan yang lebih kecil daripada kode yang digantikannya. - *Perbaikan yang diterapkan pada salah satu dari dua kanal simetris* — tanda cacat yang pertama kali disebut oleh basis kode ini, ditemui berulang kali; setiap penutupan kini mencari saudaranya sebelum di-merge. Undangan itulah inti bagian ini, dan undangan itu berlaku terus: para pembaca independen diundang, secara publik, dan dibayar, dalam mata uang yang kuantitasnya tetap. Laporkan secara privat, melalui kanal pengungkapan di `SECURITY.md` milik repositori. ## §22 Apa yang harus Anda percayai, dan apa yang tidak perlu Setiap protokol mengaku trustless; hampir tidak ada yang dapat merinci pengecualiannya. Inilah daftar lengkapnya, setiap kewenangan dinyatakan bersama baris yang membatasinya. - **Registri venue, daftar koin jembatan, dan daftar izin hook V4** — dikurasi; kasus terburuk dari pencantuman yang bermusuhan dibatasi oleh yang lebih ketat antara minimum Anda dan lantai Iron-Law Φ; pokok dana tidak dapat dijangkaunya (§9.6, §14.6). - **Kunci kendali Router, sebelum dilepaskan** — dapat mengalihkan tujuan biaya, menjeda swap, mengarahkan ulang kontrak WETH dan Permit2 yang dipanggil oleh pintu native dan pintu Permit2-nya, dan memulihkan token yang salah kirim di balik penundaan publik 48 jam; tidak dapat mengubah tarif biaya, pembagian, atau lantai (konstanta saat kompilasi, tanpa setter) atau menjangkau pokok dana (tanpa proxy, tanpa jalur upgrade, tanpa `selfdestruct`, tidak ada yang disimpan saat diam). - **Kunci kendali Hub, sebelum dilepaskan** — dapat mengarahkan ulang pandangan Hub terhadap Router, Solver, dan Quoter, mengarahkan ulang manajer V4, menjeda pembelajaran registri, dan memberikan kursi operator; tidak dapat salah memberi harga pada sebuah fill, karena tidak ada apa pun yang memberi harga transaksi yang membaca registri. - **Treasury** — ditetapkan pada saat konstruksi, dan pembagian 30 / 70 tidak memiliki setter. - **Kontrak kanonis yang menjadi tumpuan pintu-pintu** — Permit2 milik Uniswap untuk pintu Permit2, WETH milik chain untuk pintu native, PoolManager untuk leg V4: masing-masing hanya dipanggil melalui pintunya atau leg-nya, dan Router memberi harga setiap leg dari delta saldo terukurnya sendiri, sehingga pihak lawan yang tidak jujur akan meruntuhkan output dan batas Anda menolak swap tersebut. - **Token dan kesesuaiannya** — bahwa BZPX memenuhi enam invarian deployment-nya, dan bahwa alamat yang Anda panggil sesuai dengan teks ini: dapat diperiksa begitu catatan §19 dipublikasikan, dengan prosedur yang ditetapkan §19. Apa yang tidak perlu Anda percayai: siapa pun untuk memberi harga transaksi Anda — rute diturunkan di frame eksekusi dari state publik, atau diukur ulang di sana jika Anda yang menyediakannya; siapa pun untuk merutekannya secara adil — lantai diturunkan ulang di on-chain dari output terukur dan biaya tidak memiliki suku yang tumbuh seiring selisih antara kuotasi dan pengiriman; siapa pun untuk menghitung biaya — Router menolak menyelesaikan transaksi tanpa membayarnya; dan siapa pun untuk terus melayani Anda — jika setiap server yang dioperasikan proyek ini lenyap malam ini, kontrak-kontrak tersebut akan memberikan kuotasi, merutekan, dan menyelesaikan transaksi besok persis seperti yang dilakukannya hari ini. Dan jika Anda mempertahankan satu kebiasaan dari dokumen ini, jadikanlah itu minimum yang Anda tetapkan pada transaksi Anda sendiri. Setiap batas dalam agregator kembali ke angka itu; itulah satu-satunya perlindungan dalam sistem yang kualitasnya tidak bergantung pada kompetensi siapa pun selain Anda. ## §23 Karya terkait **Perutean.** Angeris, Evans, Chitra, dan Boyd merumuskan perutean di antara constant-function market maker sebagai program konveks yang optimumnya menyamakan harga marginal di seluruh venue; Diamandis, Resnick, Chitra, dan Angeris memberikan algoritma dekomposisi dual yang efisien untuknya. Desain ini sengaja berhenti sebelum optimum itu di on-chain: Alokator Pembagian bersifat proporsional-terhadap-kedalaman dalam satu lintasan (§10.4), yang tidak memerlukan iterasi maupun model kelengkungan per venue dan tangguh di tempat solver iteratif menjadi tagihan gas dan permukaan serangan; jalur metamorfik mengukur jarak yang menjadi harga pilihan ini — pembagian tidak pernah membayar lebih sedikit daripada pool tunggal terbaik (MR-R1) dan matriks fidelitas menempatkan rute Solver dalam 0.13 bps dari grid menyeluruh di Base. Bentuk tertutup yang menyamakan imbal hasil marginal secara eksak untuk keluarga constant-product adalah dua penjumlahan dan satu akar kuadrat per venue dan merupakan kandidat untuk rilis berikutnya; fungsi objektifnya datar di dekat optimumnya, itulah sebabnya aturan yang tangguh dirilis lebih dahulu. Desain solver off-chain memindahkan optimisasi ke sebuah server dan mereduksi kontrak menjadi pemeriksa; Anggaran Dependensi §3.1 adalah pernyataan makalah ini tentang berapa biayanya. Karya terbaru memperluas model dengan gas: *Optimal Routing across Constant Function Market Makers with Gas Fees* menunjukkan bahwa gas memperlebar wilayah tanpa-transaksi dan berinteraksi secara tidak trivial dengan fragmentasi, dan *Routing Frictions and Executable Liquidity in Fragmented Markets* memisahkan likuiditas yang diiklankan dari likuiditas yang dapat dieksekusi — perbedaan yang diukur desain ini di dalam frame alih-alih dimodelkan. **Agregasi yang tangguh.** Pusat kepercayaan §10.3 adalah median berbobot kedalaman, yang titik keruntuhannya adalah setengah dari bobot. Müller, Moumeni, dan Messaoudi, *Cost of Manipulation in AMM-Based Oracles* (FC 2026), membuktikan batas yang bersesuaian untuk oracle yang mengagregasi harga AMM: dengan bobot yang sama, serangan termurah menggerakkan pool yang paling dangkal, sedangkan dengan bobot likuiditas, mengendalikan setengah bobot memerlukan setidaknya setengah dari total kedalaman kuotasi. Ormer mengusulkan oracle on-chain yang mengestimasi median sebagai pengganti rata-rata TWAP, dan *From Means to Medians* mengkaji tolok ukur mana yang paling sulit dimanipulasi. E25 menerapkan prinsip yang sama pada perutean: sebuah pool hanya dipercaya sejauh modal yang dipertaruhkan berdiri di belakangnya. **Venue.** Uniswap v2 memberikan rujukan constant-product dan konvensi 30 bps yang menjadi bawaan cabang V2; Uniswap v3 memberikan model likuiditas terkonsentrasi, `slot0`, dan fixed point Q64.96 yang diikuti bentuk tertutup §4.2; Uniswap v4 memberikan singleton, flash accounting, dan pengodean izin hook dalam alamat yang menjadi landasan §5 dan §14.2 — desain di sini, sepanjang pengetahuan kami, adalah yang pertama menurunkan, membuktikan, memberi harga, menyaring, dan menyelesaikan pool V4 sepenuhnya di dalam frame. StableSwap karya Egorov mendefinisikan invarian teramplifikasi dari keluarga Curve yang dikeluarkan protokol ini alih-alih didukung atas asumsi kepercayaan yang tidak terukur (§4.1); kurva stable Solidly dari §6 tidak memiliki makalah yang ditelaah sejawat dan dikutip melalui implementasinya yang telah di-deploy. **MEV.** Daian dkk. menamai lawan pengurutan dan menunjukkan skalanya; Zhou dkk. mengukur serangan sandwich pada bursa terdesentralisasi dan memformalkan profitabilitasnya. Makalah ini tidak mengklaim penghapusan — pengurutan diputuskan sebelum kode kontrak berjalan — dan sebagai gantinya mengukur batasnya: kurva sandwich §14.3, dari sisi penyerang, dengan tepi penolakan dan perjalanan pulang-pergi negatif penyerang di baliknya. **Verifikasi.** Hiperproperti Clarkson dan Schneider menamai kelas tempat temuan redistribusi §21 berada — properti dari himpunan jejak, bukan dari satu jejak — dan mengapa hukum kekekalan dapat berlaku sementara pihak yang salah dibayar. Interpretasi abstrak Cousot dan Cousot adalah kerangka bagi bentuk tertutup satu-tick: abstraksi matematika venue yang eksak dalam suatu rentang dan sound ke satu arah di luarnya, dengan lantai sebagai pemeriksaan konkretisasi. Chen, Cheung, dan Yiu memperkenalkan pengujian metamorfik, hakim kedua dari §15.7 ketika tidak ada oracle yang independen dari rumusnya. DeMillo, Lipton, dan Sayward memperkenalkan analisis mutasi, yang hipotesis kopelnya diandalkan oleh penjaga terkurasi §15.2. Pemrograman N-version Avizienis adalah leluhur §15.8, yang diterapkan pada pembangkitan kode alih-alih pada tim-tim independen. Pengujian kombinatorial Kuhn, Kacker, dan Lei memberikan konstruksi dan klaim bagi covering array §15.4: setiap interaksi t-arah dari faktor-faktor rezim diuji secara konstruksi, dengan penyebutnya dicetak. Hasil Littlewood dan Strigini tentang validasi keandalan ultra-tinggi adalah alasan mengapa tidak ada probabilitas kebenaran yang dinyatakan di mana pun dalam makalah ini. **Standar.** Penyimpanan transien EIP-1153 membawa konteks leg Doktrin Satu Callback, buku besar biaya, dan kunci reentrancy; EIP-170 adalah dinding 24,576 byte yang hanya berjarak beberapa ratus byte dari ukuran Router dan Hub; EIP-1014 adalah aritmetika CREATE2 dari 𝒟; EIP-2612 dan Permit2 milik Uniswap mendefinisikan transfer berbasis tanda tangan untuk pintu kedua; ERC-7201 memberi namespace pada penyimpanan Hub; akun terdelegasi EIP-7702 memanggil pintu-pintu yang sama seperti kontrak mana pun. ## §24 Kesimpulan Kami berangkat untuk membangun agregator di atas satu disiplin — ukur, jangan percaya — dan memegangnya di setiap titik tempat sebuah angka dapat saja diterima berdasarkan perkataan seseorang: rute, harga, lantai, basis biaya, himpunan venue, pasangan yang diklaim diperdagangkan sebuah pool, bahkan model biaya protokol itu sendiri. Hasilnya adalah sistem kecil dengan bentuk yang kuat. Fragmentasi likuiditas ternyata merupakan masalah bahasa, bukan matematika: di balik menjamurnya venue terdapat keluarga kecil invarian, dan protokol yang menyatakan masing-masing sekali saja — sebuah dispatcher, sebuah penurunan, sebuah lantai, sebuah medan vitalitas — dapat memberi harga pada lanskap tanpa penanganan khusus per venue, menurunkan rute di dalam transaksi yang mengeksekusinya, dan memeriksa ulang janjinya sendiri terhadap output terukur sebelum sebuah token sampai kepada Anda. Catatan terukur adalah ringkasan terpendek tentang apa yang diperoleh dengan itu: kuotasi bebas penyimpangan yang terselesaikan tepat pada prediksinya 64 kali dari 64, pada mock dan di Base live; lantai yang membatasi sandwich pada transaksi 1 % hingga sekitar 2.7 % darinya dan menolak di luar itu; pratinjau dan pengiriman yang terpisah 0–1 basis poin di empat chain; dan aparatus yang memublikasikan, beserta penyebutnya, bagaimana ia dapat dicurangi dan apa yang tidak dapat dilihatnya. Biayanya pun sama jelasnya. Gas: menurunkan rute di dalam frame lebih mahal daripada menyelesaikan jawaban yang dihitung di tempat lain — harga dari jaminan yang dapat Anda periksa alih-alih jaminan yang harus Anda terima berdasarkan perkataan seseorang — dan kurs byte–gas memberi tahu Anda, per chain, pintu mana yang membuat harga itu paling kecil. Imutabilitas: cacat diungkapkan dan diberi bounty, tidak ditambal — harga dari kontrak yang Anda audit sekali, dan §21 adalah apa yang dibeli oleh harga itu. Tesisnya, dinyatakan ulang: yang memilih adalah yang bertransaksi. Sebuah kuotasi dan eksekusinya adalah komputasi yang sama, sehingga celah tempat kejujuran operator dahulu bergantung ditutup oleh aritmetika; registri yang mempelajari likuiditas dengan memperdagangkannya, dan membuktikan setiap pasangan yang disimpannya; biaya, lantai, dan permukaan masuk yang tidak dapat diubah oleh siapa pun — termasuk para penulisnya — karena semuanya dikompilasi di dalamnya. Protokol ini tidak meminta untuk dipercaya. Ia meminta untuk diverifikasi, dan ia bekerja agar verifikasi menjadi murah, publik, dan permanen. ## §25 Staking V4: Desain Staking V4 adalah basis kode saat ini; alamatnya dipublikasikan saat peluncuran. Bab ini menjelaskan mesin staking sebagaimana sumbernya saat ini: `src/BlazePhoenixStaking.sol` di repositori `Blaze-Phoenix-Staking`, `main` pada `cc614f9` (2026-10-14), yang mendeklarasikan `VERSION = "4.0.0"` (L169). Setiap nomor baris dalam bab ini (L*n*) merujuk ke berkas tersebut pada commit tersebut; bila teks ini dan sumbernya berbeda, sumberlah yang berlaku. Bab ini tidak memuat alamat, tanggal deployment, maupun imbal hasil: setiap angka di dalamnya adalah konstanta yang dikompilasi ke dalam kontrak, atau diturunkan dari konstanta tersebut, dan penurunannya dicetak di sampingnya. Mesin ini tunduk pada disiplin yang sama dengan bagian lain makalah ini. Mesin ini memegang satu token, BZPX, dan setiap klaim atas BZPX tersebut adalah suku buku besar yang jumlahnya diperiksa ulang oleh kontrak di sekitar setiap perubahan state (E35). Seorang staker mengunci BZPX selama jumlah hari yang dipilihnya dan memperoleh dua aliran — emisi terjadwal (E27–E29) dan bunga yang dibayar peminjam (E31–E34) — masing-masing dibobot oleh boost yang tumbuh seiring komitmen (E30). Seorang staker dapat meminjam BZPX dengan jaminan stake-nya (E41). Ketika kerugian terjadi, kerugian itu mengikuti satu urutan tetap (E37), dan kontrak melaporkan, sebagai view publik, apakah ia memegang apa yang menjadi kewajibannya (E36). ### §25.1 Arsitektur dan peran Satu kontrak, `BlazePhoenixStaking`, yang mewarisi `AccessControl`, `Pausable` dan `ReentrancyGuard` (L167). Token, treasury, dan jendela emisi (`emissionStart`, `emissionEnd`) bersifat immutable (L266–269); constructor menolak alamat token yang tidak memiliki kode (L477). Tidak ada oracle, tidak ada jalur upgrade, dan tidak ada setter parameter: setiap konstanta di bawah ini dikompilasi ke dalamnya. | Peran | Dipegang oleh | Boleh | Baris | |---|---|---|---| | `DEFAULT_ADMIN_ROLE` | deployer, saat konstruksi | memberikan dan mencabut peran (tidak ada panggilan `_setRoleAdmin`, sehingga peran ini mengelola setiap peran) | L485 | | `ADMIN_ROLE` | deployer, saat konstruksi | `fundEmission` (pendanaan kumulatif ≤ `TOTAL_REWARDS`); `withdrawReserve` (hanya ke treasury yang immutable, paling banyak `protocolReserve`, tertutup saat pelanggaran keras); `sweepUndistributedEmission` (hanya setelah `emissionEnd`); `unpause`; `cancelEmergency` (hanya pada buku yang solven) | L486, L516, L533, L563, L580, L618 | | `GUARDIAN_ROLE` | tidak seorang pun saat konstruksi; diberikan oleh admin peran | `pause`; `declareEmergency` — keduanya tidak memindahkan dana | L171, L578, L608 | | siapa pun | — | `liquidate`; `tripBreaker` (revert kecuali buku dalam pelanggaran keras); `absorbBadDebt`; `lockStep` | L1066, L597, L639, L1291 | Tidak ada peran yang dapat memindahkan pokok (principal) milik staker, dan satu-satunya tujuan yang dapat dikirimi pendapatan oleh peran mana pun adalah treasury yang immutable. | Konstanta | Nilai | Makna | Baris | |---|---|---|---| | `TOTAL_REWARDS` | 180,000,000e18 | anggaran emisi, sekaligus batas atas `fundEmission` kumulatif | L192 | | `HALVING_PERIOD` | 2 × 365 hari | panjang satu periode emisi | L193 | | `EMISSION_PERIODS` | 8 | jumlah periode sebelum program ditutup (`EMISSION_LENGTH` = 16 tahun) | L194–195 | | `INITIAL_REWARD_PER_SEC` | (`TOTAL_REWARDS` / 2) / `HALVING_PERIOD` | laju periode 0, $R_{0}$ | L196 | | `MAX_STAKE_PER_WALLET` | 30,000,000e18 | batas atas stake per posisi | L198 | | `MIN_EMISSION_WEIGHT` | 1,000e18 | di bawah total bobot ini kedua aliran dibatasi secara pro rata | L208 | | `MAX_LTV` | 50 | batas atas pinjaman, % dari stake bersih | L210 | | `LIQ_THRESHOLD` | 95 | dapat dilikuidasi pada utang ≥ 95 % dari stake | L211 | | `LIQ_BONUS_BPS` | 500 | surplus likuidasi untuk pemanggil, bps dari utang | L212 | | `RESERVE_FACTOR_BPS` | 300 | bagian dari setiap irisan bunga yang disimpan di `protocolReserve` | L213 | | `MIN_LOCK_DAYS`, `MAX_LOCK_DAYS` | 90, 2,555 | batas kunci (lock) dalam hari | L221–222 | | `BOOST_BASE`, `BOOST_LINEAR`, `BOOST_QUAD` | 10,000, 750, 250 | polinomial boost, bps | L224–226 | | `MIN_DEPOSIT_BLOCKS` | 10 | jumlah blok yang harus dilalui sebuah deposit sebelum withdraw, klaim pure-yield, atau perubahan kunci | L228 | | `RATE_R0`, `RATE_RK`, `RATE_UK`, `RATE_S1`, `RATE_S2` | 100, 500, 0.8e18, 500, 72,500 | kurva bunga bertekuk, bps tahunan | L231–235 | | `MAX_PROTOCOL_UTIL_WAD` | 0.75e18 | batas atas utilisasi buku untuk pinjaman baru | L242 | | `CONSERVATION_DUST` | 1e10 | toleransi penjaga konservasi, dalam wei | L247 | | `MAINT_BASE`, `MAINT_DENSITY`, `MAINT_GAP_UNIT`, `MAINT_MAX_SCAN`, `MAINT_MAX_LOCK_ACTIONS` | 1, 50, 15 menit, 10, 4 | anggaran pemeliharaan otonom (E42) | L252–255, L263 | ### §25.2 Alurnya: stake, unstake, klaim, pinjam Setiap titik masuk pengguna menjalankan satu pipeline, dalam urutan yang ditetapkan `deposit`: mengambil snapshot identitas konservasi; menolak bila buku dalam pelanggaran keras; memajukan indeks bunga dan jendela emisi (`_updateGlobal`, L1428); menyelesaikan kedua aliran pada bobot yang dimiliki posisi; mengatribusikan bunga yang menjadi kewajiban posisi (`_accrueInterestFor`, L1627); menghapus kunci yang telah berakhir; melakukan aksinya; menghitung ulang bobot posisi melalui penulis tunggal (`_resync` → `_applyBoost` → `_checkpoint`, L1726–1756); menjalankan jendela pemeliharaan otonom (E42); dan memeriksa identitas konservasi sekali lagi (E35). Pintu-pintu itu hanya berbeda dalam gerbang yang ditambahkannya. | Titik masuk | Dijeda | Darurat | Pelanggaran keras | Syarat tambahan | |---|---|---|---|---| | `deposit(amount, lockDays)` — stake | tertutup | tertutup | tertutup (L760) | $90 \le$ `lockDays` $\le \min(2{,}555,\ \text{days left to } \mathtt{emissionEnd})$; stake posisi ≤ `MAX_STAKE_PER_WALLET`; sebelum `emissionEnd` (L743–760) | | `lock(lockDays)` | tertutup | tertutup | — | `MIN_DEPOSIT_BLOCKS` sejak deposit terakhir (L964–971) | | `withdraw(amount)` — unstake | terbuka | tertutup | tertutup (L902) | tanpa utang; kunci telah berakhir; `MIN_DEPOSIT_BLOCKS` sejak deposit terakhir (L890–895) | | `claimRewards()` | terbuka | tertutup | tertutup (L932) | menyelesaikan emisi dan pure yield (L930) | | `claimPureYield()` | terbuka | tertutup | tertutup (L948) | tanpa utang; `MIN_DEPOSIT_BLOCKS` sejak deposit terakhir (L944–948) | | `borrow(amount)` | tertutup | tertutup | tertutup (L826) | E41 (L820–840) | | `repay(amount)` | terbuka | tertutup | terbuka | — (L858) | | `liquidate(user)` | tertutup | tertutup | terbuka | E39 (L1066) | | `emergencyWithdraw()` — keluar | — | hanya ini | — | E40 (L658) | | `absorbBadDebt(amount)` | terbuka | terbuka | terbuka | E38 (L639) | **Stake.** `deposit` menarik BZPX ke dalam posisi dan memulai atau memperpanjang kuncinya; kunci tidak pernah boleh melewati akhir program emisi, dan boost yang dibelinya (E30) hanya dibayarkan selama kunci masih berlaku. **Unstake.** `withdraw` mengembalikan pokok (principal) begitu posisi tidak memiliki kewajiban apa pun dan kuncinya telah berakhir; fungsi ini tetap terbuka selama jeda oleh guardian, sehingga jeda menghentikan risiko baru tanpa menjebak siapa pun. Dalam keadaan darurat, satu-satunya jalan keluar adalah `emergencyWithdraw`, yang membayar ekuitas bersih, diskalakan secara pro rata bila kontrak memegang lebih sedikit daripada yang menjadi hak posisi-posisi (E40), dan menghanguskan aliran posisi yang belum diklaim. **Klaim.** Panennya adalah kedua klaim tersebut: `claimRewards` membayar kedua aliran, `claimPureYield` hal yang sama untuk posisi tanpa utang; tidak ada fungsi panen terpisah. **Pinjam, bayar kembali, likuidasi.** Seorang staker dapat meminjam BZPX dengan jaminan stake-nya sendiri di dalam dua batas atas (E41); bunga dibebankan pada stake, tidak ditambahkan ke utang (E34); `repay` tetap terbuka selama jeda dan selama pelanggaran keras, karena menutup utang hanya membuat buku lebih aman. Posisi yang utangnya mencapai 95 % dari stake-nya dapat ditutup oleh siapa pun, dan penutupnya menerima surplus dari E39.  ### §25.3 Akuntansi imbalan **Emisi.** Misalkan $T$ = `TOTAL_REWARDS`, $P$ = `HALVING_PERIOD`, $R_{0}$ = `INITIAL_REWARD_PER_SEC`, $s$ = `emissionStart`, dan untuk waktu $t$ misalkan $\tau = t - s$ dan $p = \lfloor \tau / P \rfloor$. Emisi terjadwal kumulatif berbentuk tertutup (`_emittedAt`, L1458–1467): $$ E(t) \;=\; \begin{cases} 0 & t \le s \\ \left(T - (T \gg p)\right) \;+\; (R_{0} \gg p)\,(\tau - pP) & s < t < s + 8P \\ T - (T \gg 8) & t \ge s + 8P \end{cases} $$ ^e27 *Penurunan.* Dalam aritmetika eksak, laju periode $q$ adalah $T/(2^{q+1}P)$, sehingga satu periode penuh $q$ mengemisikan $T/2^{q+1}$ dan emisi sebelum periode $p$ adalah $\sum_{q 0 \end{cases} $$ ^e30 dengan $s_{u}$ stake posisi dan $d_{u}$ utangnya. Nilai eksak: $b(90) = 10{,}199$, $b(365) = 11{,}000$, $b(730) = 12{,}500$, $b(1{,}825) = 20{,}000$, $b(2{,}555) = 27{,}500$ bps. Bobot emisi dihitung atas stake bersih; bobot pure-yield hanya ada untuk posisi tanpa utang — peminjam tidak memperoleh bunga yang dibayarnya sendiri. ### §25.4 Bunga: kurva dan indeks **Kurva.** Utilisasi adalah $U = \min(\lfloor D \cdot 10^{18} / S \rfloor, 10^{18})$, dengan $D$ = `totalDebt` dan $S$ = `totalStaked` ($U = 10^{18}$ jika $S = 0 < D$; laju dasar jika keduanya nol), dan laju tahunan dalam bps bertekuk pada 80 % (`_interestRate`, L1768–1782): $$ r(U) \;=\; \begin{cases} 100 + \left\lfloor 500\,U / 10^{18} \right\rfloor & U \le 0.8 \cdot 10^{18} \\ 500 + \left\lfloor 72{,}500\,(U - 0.8\cdot 10^{18}) / 10^{18} \right\rfloor & U > 0.8 \cdot 10^{18} \end{cases} $$ ^e31 Kedua cabang bertemu di titik tekuk — $100 + 0.8 \times 500 = 500$ — dan kurva mencapai $500 + 0.2 \times 72{,}500 = 15{,}000$ bps pada utilisasi penuh. Sebuah pinjaman tidak boleh menaikkan buku di atas 75 % (E41), sehingga tidak ada pinjaman yang dengan sendirinya memasuki cabang curam. **Indeks.** Setiap irisan $\Delta t$ yang telah berlalu dicap dengan laju yang berlaku sepanjang irisan itu, sebelum penulisan apa pun ke $D$ atau $S$ (`_interestSlice`, L1589–1619; `_updateInterestIndex`, L1539–1583), dengan $Y$ = 365 hari: $$ \delta \;=\; \left\lfloor \frac{\lfloor 10^{18}\, r(U) / 10^{4} \rfloor \cdot \Delta t}{Y} \right\rfloor, \qquad \sigma \;=\; \left\lfloor \frac{D\,\delta}{10^{18}} \right\rfloor, \qquad I \leftarrow I + \delta, \quad S \leftarrow S - \sigma $$ ^e32 Jika $\sigma$ akan melebihi $S$, kemajuan indeks diturunkan ulang sebagai $\delta = \lfloor S \cdot 10^{18}/D \rfloor$ dan $\sigma$ dihitung ulang darinya, sehingga beban per posisi tidak pernah berjumlah lebih dari debit global. Aritmetikanya jenuh ke nol alih-alih revert, sehingga titik-titik masuk yang berjalan di atasnya tidak dapat membeku, dan dalam keadaan darurat jam bergeser tanpa membebankan apa pun (L1547). Satu fungsi menghitung irisan untuk eksekusi dan untuk setiap kuotasi, sehingga keduanya tidak dapat membulatkan secara berbeda. **Pembagian.** Irisan meninggalkan stake dan dibagi dalam langkah yang sama (L1560–1580; `_dampPure`, L1623–1625), dengan $W_{\mathrm{p}}$ = `totalBoostedPure` dan $A^{\mathrm{p}}$ = `accPureYieldPerShare`: $$ \kappa_{r} = \left\lfloor \frac{300\,\sigma}{10^{4}} \right\rfloor, \quad \pi = \sigma - \kappa_{r}, \quad \eta = \left\lfloor \frac{\pi \cdot \min(W_{\mathrm{p}}, W_{\min})}{W_{\min}} \right\rfloor, \quad A^{\mathrm{p}} \leftarrow A^{\mathrm{p}} + \left\lfloor \frac{\eta \cdot 10^{18}}{W_{\mathrm{p}}} \right\rfloor, \quad \mathtt{protocolReserve} \mathrel{+}= \kappa_{r} + (\pi - \eta) $$ ^e33 sehingga $\sigma = \kappa_{r} + \eta + (\pi - \eta)$ secara eksak; tanpa bobot pure, seluruh $\pi$ masuk ke cadangan. Pembatasannya sama dengan pembatasan emisi (E28), dengan konstanta yang sama. **Atribusi.** Sisi global telah diselesaikan ketika bunga terakumulasi; bagian milik posisi sendiri diatribusikan ketika posisi itu berikutnya disentuh (`_accrueInterestFor`, L1627–1671), dengan $I_{u}$ checkpoint indeksnya: $$ i_{u} \;=\; \left\lfloor \frac{d_{u}\,(I - I_{u})}{10^{18}} \right\rfloor; \qquad i_{u} > s_{u} \;\Rightarrow\; \lambda = i_{u} - s_{u} \ \text{enters E37},\ S \mathrel{+}= \lambda,\ i_{u} \leftarrow s_{u}; \qquad s_{u} \leftarrow s_{u} - i_{u}, \quad I_{u} \leftarrow I $$ ^e34 Bunga dibayar dari stake; utang itu sendiri tidak bertambah. Posisi tanpa utang hanya menetapkan ulang checkpoint, sehingga tidak pernah mewarisi pertumbuhan indeks dari masa ketika posisi itu tidak berutang apa pun. Bunga yang tidak dapat dibayar oleh sebuah posisi tetap telah didistribusikan oleh E33; menambahkannya kembali ke $S$ menjaga $S = \sum_{u} s_{u}$, dan kerugiannya dibukukan oleh E37 pada saat kerugian itu diketahui. ### §25.5 Cadangan, solvabilitas, dan air terjun kerugian **Konservasi.** Dengan $B$ saldo BZPX kontrak, $D$ = `totalDebt`, $\mathit{BD}$ = `totalBadDebt`, $S$ = `totalStaked`, $\mathit{RR}$ = `rewardReserve`, $\mathit{PR}$ = `protocolReserve` dan $\Pi$ = `totalRewardDistributed − totalRewardsPaid` (telah didistribusikan, belum dibayarkan), setiap fungsi yang memakai modifier `conserves` mengambil snapshot kedua sisi sebelum badannya dan melakukan revert setelahnya kecuali (L419–438; `_conservationSnapshot`, `_conservationCheck`, L449–457): $$ \left|\, \Delta(B + D + \mathit{BD}) \;-\; \Delta(S + \mathit{RR} + \mathit{PR} + \Pi) \,\right| \;\le\; \varepsilon, \qquad \varepsilon = \mathtt{CONSERVATION\_DUST} = 10^{10}\ \text{wei} $$ ^e35 Setiap suku adalah satu variabel state yang tidak negatif, dijumlahkan tanpa lantai, sehingga identitasnya linear di setiap rezim — termasuk kesulitan terminal, ketika alat-alat pemulihan (`repay`, `liquidate`, `absorbBadDebt`) harus tetap berfungsi — dan hanya perubahan sepanjang satu panggilan yang dibandingkan, sehingga riwayat tidak dapat terakumulasi menjadi alarm palsu. **Solvabilitas.** Apa yang menjadi kewajiban kontrak, dan uji publik apakah kontrak memegangnya (`_owed`, L1794–1798; `_hardBreach`, L1808–1810; `isSolvent`, L1824): $$ \mathrm{owed} \;=\; (S + \mathit{RR} + \mathit{PR} - D)^{+} \;+\; \Pi, \qquad \mathrm{hardBreach} \iff B + \varepsilon < \mathrm{owed}, \qquad \mathtt{isSolvent}() = \neg\,\mathrm{hardBreach} $$ ^e36 *Penurunan kaitannya dengan utang macet.* Bila $S + \mathit{RR} + \mathit{PR} \ge D$, E35 memberikan $\Delta(B - \mathrm{owed} + \mathit{BD}) = 0$ (hingga $\varepsilon$) di sepanjang setiap panggilan yang dijaga, sehingga $B - \mathrm{owed} = c - \mathit{BD}$, dengan $c$ saldo yang dipegang di luar buku besar. Karena itu, utang macet yang tercatat tepat merupakan suku yang mendorong buku menuju pelanggaran keras, dan buku terbaca insolven begitu $\mathit{BD} > c + \varepsilon$. Dalam pelanggaran keras, pintu-pintu yang akan membayar pada nilai par atau menambahkan uang baru ke wadah yang kekurangan akan revert — `deposit`, `borrow`, `withdraw`, `claimRewards`, `claimPureYield` dan penyelesaian pure-yield di dalamnya, `withdrawReserve`, `cancelEmergency` (L760, L826, L902, L932, L948, L1510, L539, L620) — sementara `repay`, `liquidate` dan `absorbBadDebt` tetap terbuka, dan siapa pun dapat memanggil `tripBreaker` untuk memindahkan kontrak ke keadaan darurat (L597). **Air terjun.** Kerugian $\lambda$ hanya muncul di tiga tempat: likuidasi yang utangnya melebihi stake (L1101–1106, L1128), jalan keluar darurat yang berada di bawah air (L704–709), dan bunga yang tidak dapat dibayar oleh sebuah posisi (L1657–1663). Ketiganya menerapkan urutan yang sama: $$ \kappa \;=\; \min(\lambda,\ \mathit{PR}), \qquad \mathit{PR} \leftarrow \mathit{PR} - \kappa, \qquad \mathit{BD} \leftarrow \mathit{BD} + (\lambda - \kappa) $$ ^e37 Cadangan — dibangun dari faktor cadangan setiap irisan bunga (E33) dan dari bonus likuidasi-diri — menyerap terlebih dahulu; hanya sisa yang tidak tertutup yang menjadi utang macet tercatat. Rekapitalisasi adalah pintu publik yang mengambil cadangan terlebih dahulu, lalu paling banyak apa yang ditawarkan pemanggil dan tidak pernah lebih dari yang masih belum tertutup (`absorbBadDebt`, L639–649), dengan $a$ jumlah dari pemanggil: $$ \rho \;=\; \min(\mathit{BD},\ \mathit{PR}), \qquad \gamma \;=\; \min(a,\ \mathit{BD} - \rho), \qquad \mathit{PR} \leftarrow \mathit{PR} - \rho, \qquad \mathit{BD} \leftarrow \mathit{BD} - \rho - \gamma, \qquad B \leftarrow B + \gamma $$ ^e38 Fungsi ini revert ketika $\rho + \gamma = 0$, tidak memindahkan apa pun keluar dan tidak membayar apa pun kepada pemanggil; E35 berlaku menurut konstruksinya ($\Delta \mathrm{LHS} = \gamma - \rho - \gamma = -\rho = \Delta \mathrm{RHS}$). Begitu $\mathit{BD}$ kembali berada dalam batas debu, `isSolvent()` terbaca true dan admin dapat membatalkan keadaan darurat. **Likuidasi.** Sebuah posisi dapat dilikuidasi jika dan hanya jika $d_{u} > 0$ dan ($s_{u} = 0$ atau $100\,d_{u} \ge 95\,s_{u}$) (`_isLiquidatable`, L1133–1137). Menutupnya (`_executeLiquidation`, L1079–1131): $$ \mathrm{seized} \;=\; \min\!\left(d_{u} + \left\lfloor \frac{500\,d_{u}}{10^{4}} \right\rfloor,\ s_{u}\right), \qquad \mathrm{bonus} \;=\; (\mathrm{seized} - d_{u})^{+}, \qquad \lambda \;=\; (d_{u} - s_{u})^{+} \ \text{to E37} $$ ^e39 Bonus diberikan kepada pemanggil, kecuali ketika peminjam menutup posisinya sendiri, yang dalam hal ini bonus tetap berada di `protocolReserve`. Aliran yang telah diperoleh posisi dibayarkan sebelum posisi ditutup, dan sisa stake apa pun tetap ada sebagai posisi tanpa utang yang mempertahankan kuncinya. **Jalan keluar darurat.** Dengan $\mathrm{pot} = B$ dan $E_{+}$ = `totalPositiveEquity` $= \sum_{u} \max(s_{u} - d_{u}, 0)$ sebagaimana dilacak, jalan keluar ini membayar (`emergencyWithdraw`, L658–725; penskalaan, L689–696): $$ x_{0} \;=\; (s_{u} - d_{u})^{+}, \qquad E' \;=\; E_{+} - e_{u} + x_{0}, \qquad x \;=\; \min\!\left( \begin{cases} \lfloor x_{0}\,\mathrm{pot} / E' \rfloor & \mathrm{pot} < E' \\ x_{0} & \text{otherwise} \end{cases},\ \mathrm{pot} \right) $$ ^e40 dengan $e_{u}$ suku terlacak milik pihak yang keluar, yang diganti dengan ekuitas eksaknya setelah akrual. Pada buku yang solven penskalaan tidak pernah aktif dan ekuitas bersih dibayar penuh; pada buku yang kekurangan, setiap jalan keluar mengambil fraksi yang sama dari klaimnya, dan jalan keluar yang berada di bawah air membukukan kekurangannya melalui E37 (L704–709).  **Batas atas pinjaman.** Pinjaman sebesar $a$ harus memenuhi keduanya (`borrow`, L834–840; `_ltvCap`, L1908–1909): $$ d_{u} + a \;\le\; \left\lfloor \frac{50\,(s_{u} - d_{u})^{+}}{100} \right\rfloor, \qquad \left\lfloor \frac{(D + a)\cdot 10^{18}}{S} \right\rfloor \;\le\; 0.75 \cdot 10^{18} $$ ^e41 yang pertama atas stake bersih posisi, yang kedua atas seluruh buku, dijaga di bawah titik tekuk 80 % dari E31. **Pemeliharaan.** Setiap transaksi pengguna, kecuali kontrak sedang dijeda atau dalam keadaan darurat, juga memindai satu jendela registri peminjam (melikuidasi yang berada di bawah air) dan registri kunci (menormalisasi kunci yang telah berakhir), masing-masing berukuran (`_windowBudget`, L1148–1157; `_autoMaintain`, L1170–1178): $$ c(n) \;=\; \min\!\left(1 + \left\lfloor \frac{n}{50} \right\rfloor + \left\lfloor \frac{t - t_{m}}{15\ \mathrm{min}} \right\rfloor,\ 10,\ n\right) $$ ^e42 dengan $n$ ukuran registri dan $t_{m}$ penyapuan terakhir; paling banyak empat normalisasi kunci dijalankan per transaksi (L263). Jadwal ini adalah fungsi murni dari state on-chain — tanpa keeper, tanpa tata kelola — dan gas-nya terbatas dalam setiap kasus. **Invarian.** Desain ini menambahkan sembilan invarian, INV-23 hingga INV-31 (Lampiran B): identitas konservasi, batas atas emisi, urutan kerugian, pintu-pintu yang tertutup saat pelanggaran, batas rekapitalisasi, penulis tunggal bobot, batas atas pinjaman, jalan keluar darurat yang terbatas, dan aturan pematangan deposit. ### §25.6 Pengerasan dalam V4 Tiga perubahan yang di-merge membentuk sumber V4 setelah desain yang ter-deploy di Base; masing-masing dijelaskan di sini pada tingkat desain yang dihasilkannya. - **#22 (`b44e238`, 2026-10-11).** Bunga dicap per irisan oleh satu fungsi yang digunakan bersama oleh eksekusi dan setiap kuotasi (E32), sehingga pratinjau dan transaksi menghitung beban yang sama, pada laju yang berlaku sepanjang irisan. Kanal pure-yield dibatasi oleh lantai bobot yang sama dengan emisi (E33), sehingga penyebut residual tidak dapat menangkap aliran. Peminjam yang menutup posisinya sendiri tidak menerima bonus likuidasi. View risiko hanya-baca ditambahkan (`healthFactor`, `daysToLiquidation`, `maxBorrowOf`). - **#26 (`7fc0c2a`, 2026-10-13).** Satu urutan kerugian untuk ketiga tempat kerugian: cadangan terlebih dahulu, lalu utang macet tercatat (E37); pintu rekapitalisasi publik (E38); pintu-pintu yang memindahkan nilai ditutup saat pelanggaran keras (E36); constructor yang menolak alamat token tanpa kode; pemeriksaan konservasi dihasilkan sekali sebagai dua helper internal alih-alih di-inline di setiap tempat yang dijaga, dengan identitas yang tidak berubah; dan sebuah suite tes jaminan. - **#25 (`cc614f9`, 2026-10-14).** Hanya dokumentasi: baris ringkasan singkat di panduan dan header tes. Tidak ada sumber kontrak yang berubah. ### §25.7 Bukti pengujian Dihitung pada `origin/main` di `cc614f9`, dari pohon sumber, bukan dari sebuah run: 37 berkas `*.t.sol` (`git ls-tree -r --name-only origin/main | grep -c '\.t\.sol$'`), yang mendeklarasikan 256 fungsi `test*` dan 14 fungsi `invariant*` (`git grep -E '^\s*function (test|invariant)' origin/main -- '*.t.sol'`, dipisahkan menurut prefiks). README repositori (baris 84) menyatakan adanya harness Node berisi sembilan suite di sampingnya. Ini adalah hitungan atas apa yang dideklarasikan; makalah ini tidak melaporkan tingkat kelulusan untuk suite staking. --- ## Riwayat revisi ### Versi 2.3.0 (2026-10-14) 2.3.0 — menambahkan bab desain Staking V4 (§25), dengan persamaan E27–E42, invarian INV-23–INV-31 dan gambar FIG-19–FIG-21; versi ini menggantikan pernyataan di bawah bahwa mesin staking tidak lagi diuraikan dalam makalah ini. Di bagian lain hanya label versi, rentang enumerasi, pengantar lampiran, dan baris DOI yang berubah; selebihnya adalah teks 2.3. ### Versi 2.3 (2026-09-24) Versi 2.3 melanjutkan lini 2.2; penomoran 3.0 yang sempat dipakai untuk draf teks ini dicabut, sebagaimana penomoran 3.0 tanggal 2026-09-01 sebelumnya. Perubahan terhadap 2.2: delapan belas inovasi diberi nama, dinomori I-1 sampai I-18 dan dinyatakan beserta matematikanya di bagian depan makalah, dengan papan skor catatan terukur; setiap gambar diukur ulang terhadap `main` pada `8916545`; mesin staking tidak lagi diuraikan di sini (spesifikasinya sendiri yang memuatnya); bagian token mencatat satu pool Airdrop & Bounties sebesar 130,000,000 BZPX; dan ralat 2.2, di bawah, dilebur ke dalam teks yang dikoreksinya. ### Ralat untuk 2.2 (2026-09-07) Diterapkan setelah pembacaan secara permusuhan atas teks 2026-09-06 terhadap `main 8949a9d`; baris versi tetap 2.2. Setiap butir menyebut apa yang dinyatakan teks dan apa yang dinyatakan checkout. 1. §4.2 — pembatas batas `sqrtBoundary` didefinisikan di Core tetapi belum dihubungkan ke pemeringkatan maupun ke janji di dalam frame; teks menyatakan bahwa pembatas itu diterapkan pada sisi janji. Butir terbuka: hubungkan (`Router._v4LegQuote`, cabang pemeringkatan Core), dengan tes red-first yang menyerahkan di bawah kuotasi bersih melampaui buffer E21 ketika leg V4 keluar dari rentangnya. 2. §10.4 — pembatas kapasitas mengecualikan leg V4 (Solver melewati pembacaan saldo untuk jenis 4 dan 8); teks menyatakan bahwa setiap leg terkonsentrasi dibatasi. Butir terbuka: batas fisik untuk singleton. 3. §5.4 — kunci V4 berbiaya statis mengabaikan biaya protokol dari manager (nol di setiap chain yang dilayani saat ini); teks menyebut biaya kunci itu tidak ambigu. 4. §9.3 — margin eviksi turun hingga sekitar 25 % (petahana 51, pendatang baru 64), bukan 3 %; angka sebelumnya melanggar E13 dan disalin dari komentar sumber. 5. §15 dan abstrak — 43 fungsi `invariant_*` (perintah yang dicetak mengembalikan 43), 217 berkas `.t.sol`. 6. §14.1 — `HubE(6)` tidak ada; kehabisan factory adalah `HubE(4)`, kehabisan slot adalah `_canInsert`. 7. §14.2 — "satu lapisan mana pun sudah cukup" dicabut: lapisan-lapisan itu membatasi perubahan delta; residu penggantian biaya pada §5.4 dibatasi oleh lantai. 8. §11.4, INV-21 — aturan bentuk rute adalah urutan kanonis di seluruh rute (`sawHooked`), bukan "hooked hanya pada hop terakhir". 9. §11.3, E24 — kelonggaran lantai hop agregat dibagi dengan BPS: 20 % dari rata-rata leg yang diatestasi. 10. §17.3 dan Lampiran C — harness `FactoryCensus` berada di pohon deployment privat; tabel tersebut dilaporkan, tidak dapat direproduksi dari checkout ini. 11. §17.5 — acuan gas disebutkan namanya (KyberSwap `MetaAggregationRouterV2`, fork Base, 2026-08-22, Paraswap sebagai pembanding kedua) dan rasio per transaksi (2.7×) dicetak di samping rasio per leg; harness dan calldata yang ditangkap bersifat privat, sehingga angkanya dilaporkan, tidak dapat direproduksi dari checkout ini. 12. §17.2 — "agregasi berperute V4 pertama di chain" dicabut; "persis" diganti dengan pita terukur (0–1 bps). 13. INV-8, INV-10, INV-15, INV-20, INV-22 — kutipan penegakan dikoreksi ke tes dan kode yang memikulnya; INV-22 menyebut keempat kontrak yang di-deploy. 14. §1 — survei agregator dibatasi pada tujuh yang disebutkan, sebagaimana didokumentasikan pada 2026-09-07. 15. Referensi 16 dan 20 — EIP-1153 ditulis oleh A. Akhunov dan M. Salem; EIP-7702 oleh V. Buterin, S. Wilson, A. Dietrichs dan M. Garnett. 16. §2.3, §15.11, §21 — hitungan kalibrasi instrumen dan pola cacat diganti dengan aturan kalibrasi itu sendiri. - §14.2, Lapisan 2 (2026-09-07, admisi hook): daftar izin mengkurasi pintu otomatis dan pin codehash menjeda hook terdaftar yang kodenya berpindah, pada setiap pintu. Hook yang bit alamatnya tidak membawa izin swap tidak pernah berjalan dalam swap dan tidak memerlukan daftar maupun pin. Hook yang berjalan dalam swap dan tidak didaftarkan siapa pun diterima pada pintu eksplisit sebagai pilihan bertanda tangan dari pemanggil, dibatasi seperti setiap venue oleh janji di dalam frame, gerbang atestasi dan `userMinOut`; hook itu tidak pernah diusulkan oleh pintu otomatis. Mendaftarkan pool ber-hook berarti mengadmisi dan mem-pin hook-nya, sehingga pool ber-hook hanyalah satu langkah operator. Ketiga lapisan tetap berlaku; "default tertutup" menggambarkan pintu otomatis. ### Ralat untuk 2.2 (2026-09-24) Diterapkan setelah gelombang bounty kesembilan; baris versi tetap 2.2. 1. §4.2, dan butir 1 ralat 2026-09-07 — ditutup. Pool V4 dikuotasi dengan menelusuri bukunya sendiri: harga, likuiditas, tick bitmap dan tick-nya, dibaca melalui `extsload`, dengan aritmetika langkah milik PoolManager sendiri, baik untuk pemeringkatan maupun untuk janji (`Core.v4WalkOut`). Pembatas batas `sqrtBoundary` dipensiunkan. Pernyataan bahwa dispatcher tidak mereplikasi aritmetika persilangan tick kini hanya berlaku untuk keluarga V3. 2. §10.4, dan butir 2 ralat 2026-09-07 — ditutup untuk tujuan yang dilayaninya: penelusuran hanya menghitung likuiditas yang dipegang buku dalam tick yang dilintasinya, sehingga leg V4 dibatasi oleh apa yang dipegang pool-nya sendiri (`test_AOneTickRangeWithNothingBeyondPaysWhatItHolds`). 3. Butir 3 ralat 2026-09-07 — ditutup: kunci berbiaya statis menyusun biaya protokol dari manager dengan biaya LP dari kunci itu searah dengan arah swap (`Core.effV4Fee`; `test_StaticKey_ProtocolFee_ReachesThePromise`). 4. §4 — setiap pembacaan yang dilakukan jalur kuotasi terhadap sebuah pool dibatasi gas dan menyalin sejumlah kata yang tetap; dua pembacaan yang tadinya berupa panggilan tingkat tinggi (`getAmountOut` milik pair Solidly, dan `factory()` lalu `getFee`) kini bertanya melalui `Core._askWord` (`test/APoolsAnswerIsBoundedByTheReader.t.sol`). ## Lampiran A · Persamaan primitif Setiap klaim kuantitatif dalam makalah ini bermuara pada salah satu persamaan berikut. Masing-masing diimplementasikan sekali, di kontrak yang disebut, dan diimpor di tempat lain. Penomoran E1–E22 stabil sejak edisi sebelumnya; E23–E26 baru dan ditambahkan di akhir. E27–E42 (2.3.0) adalah milik mesin staking, didefinisikan di `src/BlazePhoenixStaking.sol` pada repositori staking di `cc614f9` (§25); "Staking" pada kolom keempat menamai kontrak tersebut, beserta nomor barisnya. | # | Nama | Persamaan | Didefinisikan di | § | |---|---|---|---|---| | E1 | Meta-Persamaan | $R^{\star} = \arg\max_{R}\ \mathrm{net}(R)\cdot\prod_{\ell}\hat{\Psi}(p_{\ell})\cdot\mathbf{1}[\mathrm{net}(R)\ge\Phi(R)]\cdot\Xi(R)$ | Pipeline Solver | §3 | | E2 | Output constant-product | $y = \lfloor x(\mathrm{BPS}-f)\,r_{\mathrm{out}} / (r_{\mathrm{in}}\,\mathrm{BPS} + x(\mathrm{BPS}-f)) \rfloor$ | Core `outV2` | §4.2 | | E3 | Output likuiditas terkonsentrasi (di dalam tick) | $\sqrt{P}' = L\sqrt{P}/(L + x_{f}\sqrt{P}/Q_{96})$, $y = L(\sqrt{P}-\sqrt{P}')/Q_{96}$; bentuk dual untuk arah sebaliknya | Core `outV3` | §4.2 | | E4 | Slot dasar penyimpanan V4 | $\mathrm{slot} = \mathrm{keccak256}(\mathrm{abi.encode}(\mathrm{poolId}, 6))$; $\sqrt{P}$ pada bit [0,160), biaya LP pada [208,232) dari kata 0; $L$ pada kata 3 | Core `v4SqrtAndLiq` | §5 | | E5 | Invarian stable Solidly | $k(x,y) = x^{3}y + xy^{3}$ | Core `_solK` | §6 | | E6 | Langkah Newton Solidly | seed $y_{0} = Y$; langkah naik $\max(1, \lfloor (K-k)/f' \rfloor)$; langkah turun $\max(1, \lfloor (k-K)/f' \rfloor)$, diganti dengan $\lfloor y/2 \rfloor$ ketika akan melintasi nol; keluar pada $\lvert y_{n+1}-y_{n}\rvert \le 1$ dengan lonjakan satu unit melawan taker; batas 64 → seed → kuotasi 0 | Core `_solY` | §6 | | E7 | Normalisasi desimal | $X = r_{\mathrm{in}}10^{18-d_{\mathrm{in}}}$, $Y = r_{\mathrm{out}}10^{18-d_{\mathrm{out}}}$, diskalakan balik setelah penyelesaian | Core `_solidlyStable` | §6 | | E8 | Penurunan CREATE2 | $\mathrm{pool} = \mathrm{addr}_{20}(\mathrm{keccak256}(\mathtt{0xff} \Vert \mathrm{origin} \Vert \mathrm{salt} \Vert \mathrm{initCodeHash}))$ | Core `create2Address`, `deriveAddress` | §7 | | E9 | Pengemasan Monoslot | $s = a \,\vert\, f\!\ll\!8 \,\vert\, k\!\ll\!32 \,\vert\, r\!\ll\!40 \,\vert\, (c\wedge\mathtt{0xFFF})\!\ll\!48 \,\vert\, b\!\ll\!60 \,\vert\, \dots \,\vert\, B_{\mathrm{last}}\!\ll\!224$ | Core `encodeSlot` | §8 | | E10 | Medan Vitalitas | $\Psi = V \cdot 2^{b} \cdot (1 + 0.25\,\mathbf{1}_{\mathrm{bridge}}) \cdot (1 + 0.05\,\mathbf{1}_{\mathrm{conc}})$ | Core `psi` | §9.2 | | E11 | Peluruhan aktivitas | $V = \mathrm{swapCount} \gg \lfloor (t - t_{\mathrm{last}})/24{,}576 \rfloor$; 0 begitu pergeseran melebihi 31 | Core `_decayedSwapCount` | §9.2 | | E12 | Bucket kedalaman | $b = \min(15, \lfloor \log_{10}(d/10^{15}) \rfloor)$ | Core `depthBucket` | §9.2 | | E13 | Rintangan eviksi | $2^{b(d_{\mathrm{new}})} > \Psi_{\mathrm{worst}} + \lfloor \Psi_{\mathrm{worst}}/4 \rfloor$ | Hub `_canInsert` | §9.3 | | E14 | Gerbang pembagian | pertahankan pembagian iff $\mathrm{out}_{\mathrm{split}} \ge \mathrm{out}_{\mathrm{single}}\cdot(1 + 25/10^{6})$, $\mathrm{out}_{\mathrm{single}}$ yang lebih baik antara kandidat terdalam dan kandidat berkurs terbaik pada ukuran penuh | Solver `_buildHop` | §10.4 | | E15 | Lantai Iron-Law | $\mathtt{floorBps} = \max(9{,}600 - \mathtt{legShv} - \min(\delta, 10^{4}) - \sigma_{\ln}/10^{14},\ 8{,}000)$ | Core `ironFloorBpsShv` | §11.5 | | E16 | Minimum efektif | $\mathtt{effMin} = \max(\mathtt{userMinOut},\ \mathtt{route.singleOutFloor},\ \lceil \mathtt{finalHopQuote}\cdot\mathtt{floorBps}/10^{4}\rceil)$; suku kedua dibuang dan suku ketiga diskalakan ulang dengan rasio bersih terukur ketika fee-on-transfer terdeteksi | Router `_execute` | §11.5 | | E17 | Biaya protokol | $\mathrm{fee} = \lceil 28 \cdot \mathrm{base} / 10^{4} \rceil$, basis = input terukur hop biaya (berjangkar), output kotor (rute langsung ke koin jembatan), atau input terukur setiap hop (habis dicoba); $t_{1} = \lfloor 3{,}000\cdot\mathrm{fee}/10^{4} \rfloor$, $t_{2} = \mathrm{fee} - t_{1}$ | Router `_chargeHopFee`, `_payFee` | §13 | | E18 | Gerbang hook | $(\mathrm{uint160}(\mathrm{hook}) \,\&\, \mathtt{0x3FFF}) \,\&\, ((1\ll 3)\mid(1\ll 2)) \ne 0 \Rightarrow$ leg ditolak, tidak ada panggilan dilakukan | Core `hookAltersDeltas`; Router | §14.2 | | E19 | Gerbang biaya dinamis | $f_{\mathrm{eff}} = f_{\mathrm{key}}$ jika statis; tidak dapat dikuotasi jika sentinel menyertai biaya protokol non-nol; selain itu biaya LP aktif dari `slot0` / `globalState` / `fee()` milik pool | Core `effV4Fee`, `quoteV3Fee` | §5.4 | | E20 | Batas atas biaya V2 | $f_{\mathrm{eff}} = f_{\mathrm{decl}}$ jika $0 < f_{\mathrm{decl}} \le 100$ bps, selain itu 30 | Core `effV2Fee`; aturan yang sama untuk fallback fee deklarasian Solidly | §4.2 | | E21 | Buffer keamanan pratinjau | $s = \min(\max(0, n-2) + 5a,\ 10)$ bps | Quoter `_pack` | §12.1 | | E22 | Pilihan permukaan | bawa rute di calldata iff $p_{\mathrm{byte}} < \rho^{*}$; $\rho^{*}$ terukur 66.9–105.5 gas/byte menurut bentuk rute | `test/EquationBench.t.sol` | §17.6 | | E23 | Pemangkasan leg akibat konsentrasi | $\mathtt{legShv} = \sum_{\mathrm{hops}} \lfloor 200\,((\sum a)^{2} - \sum a^{2})/\sum a^{2} \rfloor$ | Core `legShaveBps` | §11.5 | | E24 | Lantai hop agregat | $\sum \mathrm{got} + \lfloor (\mathrm{BPS} - 8{,}000)\cdot \lfloor \sum \mathrm{attested}/n \rfloor / \mathrm{BPS} \rfloor \ge \sum \mathrm{attested}$ | Router `_execute` | §11.3 | | E25 | Pusat kepercayaan | median berbobot kedalaman: urutkan $(r_{i}, d_{i})$ menurut $r_{i}$, kembalikan $r_{i}$ pertama di mana $\sum_{j \le i} d_{j} \ge \lceil \sum d / 2 \rceil$; pita $[0.95, 1.05] \times$ pusat | Solver `_depthWeightedMedian` | §10.3 | | E26 | Predikat rezim biaya | $\mathrm{feeHop} = \min\{h : \mathrm{isBridge}(\mathrm{hops}[h].\mathrm{tokenIn})\}$; bebankan pada $h$ iff $\neg\mathrm{feeOnOut} \wedge (\mathrm{feeHop} = \infty \vee h = \mathrm{feeHop})$; $\mathrm{feeOnOut} \iff$ satu hop dan $\mathrm{isBridge}(\mathrm{tokenOut})$ | Router `_execute` | §13.1 | | E27 | Bentuk tertutup emisi | $E(t) = (T - (T \gg p)) + (R_{0} \gg p)(t - s - pP)$, $p = \lfloor (t - s)/P \rfloor$; $0$ hingga $s$; $T - (T \gg 8)$ mulai dari $s + 8P$ | Staking `_emittedAt` (L1458–1467) | §25.3 | | E28 | Jendela emisi | $r = \min(\lfloor (E(t') - E(t_{\ell}))\min(W, W_{\min})/W_{\min} \rfloor,\ \mathit{RR})$; $A \mathrel{+}= \lfloor r \cdot 10^{18}/W \rfloor$ | Staking `_updateGlobal` (L1428–1448) | §25.3 | | E29 | Penyelesaian | $\mathrm{due}_{u} = (\lfloor w_{u}A/10^{18} \rfloor - c_{u})^{+}$, then $c_{u} \leftarrow \lfloor w_{u}A/10^{18} \rfloor$ | Staking `_settlePendingRewards`, `_settlePendingPureYield` (L1487–1517) | §25.3 | | E30 | Boost kunci dan bobot | $b(\ell) = 10^{4} + \lfloor 750\ell/365 \rfloor + \lfloor 250\ell^{2}/365^{2} \rfloor$ bps, $\ell$ adalah kunci yang berlaku; $w_{u} = \lfloor (s_{u} - d_{u})^{+} b/10^{4} \rfloor$; $w^{\mathrm{p}}_{u} = \lfloor s_{u} b/10^{4} \rfloor$ iff $d_{u} = 0$ | Staking `boostByDays`, `_computeBoost` (L496–505, L1695–1700) | §25.3 | | E31 | Kurva bunga | $r = 100 + \lfloor 500U/10^{18} \rfloor$ untuk $U \le 0.8 \cdot 10^{18}$, selain itu $500 + \lfloor 72{,}500(U - 0.8 \cdot 10^{18})/10^{18} \rfloor$ bps setahun | Staking `_interestRate` (L1768–1782) | §25.4 | | E32 | Indeks bunga dan irisan | $\delta = \lfloor \lfloor 10^{18} r/10^{4} \rfloor \Delta t / Y \rfloor$, $\sigma = \lfloor D\delta/10^{18} \rfloor$; jika $\sigma > S$, $\delta = \lfloor S \cdot 10^{18}/D \rfloor$ dan $\sigma$ dihitung ulang | Staking `_interestSlice`, `_updateInterestIndex` (L1539–1619) | §25.4 | | E33 | Pembagian irisan | $\kappa_{r} = \lfloor 300\sigma/10^{4} \rfloor$ ke cadangan; $\eta = \lfloor (\sigma - \kappa_{r})\min(W_{\mathrm{p}}, W_{\min})/W_{\min} \rfloor$ ke pure staker; sisanya ke cadangan | Staking `_updateInterestIndex`, `_dampPure` (L1560–1580, L1623–1625) | §25.4 | | E34 | Atribusi bunga | $i_{u} = \lfloor d_{u}(I - I_{u})/10^{18} \rfloor$, dibebankan pada $s_{u}$; kelebihan di atas $s_{u}$ menjadi kerugian bagi E37 | Staking `_accrueInterestFor` (L1627–1671) | §25.4 | | E35 | Pengaman konservasi | $\lvert \Delta(B + D + \mathit{BD}) - \Delta(S + \mathit{RR} + \mathit{PR} + \Pi) \rvert \le 10^{10}$ | Staking `conserves` (L419–457) | §25.5 | | E36 | Kewajiban dan solvabilitas | $\mathrm{owed} = (S + \mathit{RR} + \mathit{PR} - D)^{+} + \Pi$; pelanggaran keras iff $B + 10^{10} < \mathrm{owed}$ | Staking `_owed`, `_hardBreach`, `isSolvent` (L1794–1824) | §25.5 | | E37 | Air terjun kerugian | $\kappa = \min(\lambda, \mathit{PR})$; $\mathit{PR} \mathrel{-}= \kappa$; $\mathit{BD} \mathrel{+}= \lambda - \kappa$ | Staking L1101–1106, L704–709, L1657–1663 | §25.5 | | E38 | Rekapitalisasi | $\rho = \min(\mathit{BD}, \mathit{PR})$, $\gamma = \min(a, \mathit{BD} - \rho)$; $\mathit{BD} \mathrel{-}= \rho + \gamma$ | Staking `absorbBadDebt` (L639–649) | §25.5 | | E39 | Likuidasi | dapat dilikuidasi iff $d_{u} > 0 \wedge (s_{u} = 0 \vee 100 d_{u} \ge 95 s_{u})$; $\mathrm{seized} = \min(d_{u} + \lfloor 500 d_{u}/10^{4} \rfloor, s_{u})$; kerugian $(d_{u} - s_{u})^{+}$ | Staking `_executeLiquidation`, `_isLiquidatable` (L1079–1137) | §25.5 | | E40 | Potongan jalan keluar darurat | $x_{0} = (s_{u} - d_{u})^{+}$, $E' = E_{+} - e_{u} + x_{0}$; $x = \lfloor x_{0}\,\mathrm{pot}/E' \rfloor$ jika $\mathrm{pot} < E'$, selain itu $x_{0}$; $x \le \mathrm{pot}$ | Staking `emergencyWithdraw` (L689–696) | §25.5 | | E41 | Plafon peminjaman | $d_{u} + a \le \lfloor 50(s_{u} - d_{u})^{+}/100 \rfloor$ dan $\lfloor (D + a) 10^{18}/S \rfloor \le 0.75 \cdot 10^{18}$ | Staking `borrow`, `_ltvCap` (L834–840, L1908–1909) | §25.5 | | E42 | Anggaran pemeliharaan | $c(n) = \min(1 + \lfloor n/50 \rfloor + \lfloor (t - t_{m})/900\ \mathrm{s} \rfloor,\ 10,\ n)$ per registri | Staking `_windowBudget` (L1148–1157) | §25.5 | ## Lampiran B · Invarian Inilah properti-properti yang berlaku di setiap keadaan yang dapat dicapai: masing-masing ditegakkan oleh bentuk kode pada lokasi yang disebut, dan transaksi yang akan melanggarnya tidak dieksekusi. INV-1–INV-18 mempertahankan nomornya dari edisi sebelumnya, dengan kolom penegakan dibawa ke kode; INV-19–INV-22 baru. INV-23–INV-31 (2.3.0) adalah milik mesin staking (§25), ditegakkan di `src/BlazePhoenixStaking.sol` pada repositori staking di `cc614f9`. | # | Invarian | Penegakan | |---|---|---| | INV-1 | Router tidak memegang dana di antara transaksi; saldonya saat diam adalah nol. | Penyapuan dan pembayaran berlingkup baseline (§11); `invariant_RouterHoldsNothing`, `HoldsNothingBeyondTheSeed` | | INV-2 | Setiap swap bersifat atomik: tidak ada keadaan di mana sebagian perdagangan telah diselesaikan. | Semantik transaksi EVM; satu frame | | INV-3 | Tanpa oracle: tidak ada price feed eksternal yang menjadi masukan bagi admisi, pengurutan, pembagian, penetapan lantai atau biaya. | Tidak ada pemanggilan feed di kelima kontrak | | INV-4 | Tarif biaya, pembagian biaya dan konstanta lantai tidak memiliki setter di bytecode yang di-deploy. | Konstanta waktu-kompilasi di Core dan Router (§13) | | INV-5 | Bidang rute yang disuplai pemanggil dapat memperketat perlindungan, tidak pernah melonggarkannya. | Maksimum tiga arah E16; gerbang cakupan mengangkat atestasi, tidak pernah menurunkannya (§11) | | INV-6 | Swap dengan minimum nol tidak dieksekusi. | `RouterE(10)` di setiap pintu | | INV-7 | Ψ memeringkat dan memangkas kandidat; tidak ada kuotasi, lantai atau alokasi yang membacanya. | Aliran data: tidak ada yang berada di hilir pemeringkatan mengonsumsi Ψ (§9.6) | | INV-8 | Registri sebuah pair menampung paling banyak enam belas pool, dan eviksi mempertahankan yang paling bugar menurut Ψ penuh dengan margin E13. | Hub `_canInsert`; `invariant_neverExceedsMaxSlots` (batas atas); `test_RecordSwap_EvictsWeakestWhenFullAndNewcomerClearsMargin` (eviksi) | | INV-9 | Tidak ada alamat tanpa bytecode runtime yang masuk ke sebuah rute. | `hasCode` pada setiap penurunan (§7) | | INV-10 | Callback universal hanya membayar pool yang dikomitmenkan untuk leg saat ini, hanya selama leg sedang berjalan, dan tidak pernah lebih dari anggaran tercatat leg tersebut. | Konteks leg transien; `RouterE(6)` untuk pool, `RouterE(8)` untuk anggaran (§11.4) | | INV-11 | Hook V4 yang alamatnya menyatakan izin pengubah delta ditolak sebelum token apa pun berpindah, tanpa memanggilnya. | E18; `RouterE(9)`; Solver `_topKPools` | | INV-12 | Tidak ada produk penetapan harga yang dapat overflow: setiap perkalian berbahaya difaktorkan melalui `mulDiv` 512-bit, dan keadaan yang tidak dapat dibatasi dikuotasi nol. | Core (§4.2, §6) | | INV-13 | Pembulatan berjalan melawan janji berlebih: kuotasi dan pembayaran dibulatkan ke bawah, lantai pelindung dan biaya dibulatkan ke atas. | Core `mulDiv` / `mulDivUp` di setiap lokasi | | INV-14 | Di mana suatu batas tidak dapat dibuktikan, komputasi mengembalikan nol dan venue dilepaskan — tidak pernah menebak, tidak pernah revert yang dapat dijadwalkan di dalam kuotasi. | Postur gagal-tertutup di seluruh Core; `_solKFits` (§6) | | INV-15 | Basis biaya adalah tarikan yang diukur, dibatasi oleh input yang dikomitmenkan rute — tidak pernah output yang dideklarasikan; `route.totalOut` tidak dibaca oleh apa pun. | `_chargeHopFee`; `test_FeeBase_IgnoresLiedAboutTotalOut` | | INV-16 | Pelepasan bersifat satu arah: flag ditulis `true` di satu lokasi dan `false` di nol lokasi; sesudahnya hanya tingkat kurator yang hanya-bertambah yang tersisa, dan factory atau hook yang telah dipindahkan tidak dapat dipersenjatai ulang. | `renounceControl` pada Hub dan Router (§14.7) | | INV-17 | Biaya fallback constant-product atau Solidly yang dideklarasikan dipercaya hanya dalam batas atas 100 bps; di luarnya 30 bps kanonis memberi harga pada pool. | E20 | | INV-18 | Tidak ada hop yang membawa lebih dari empat leg dan tidak ada rute lebih dari sebelas dalam rencana Solver; Router menerima paling banyak tiga hop dan lima leg per hop. | Anggaran Solver; Router `_execute` → `RouterE(3)` | | INV-19 | Sebuah pool masuk ke registri hanya jika membuktikan bahwa ia memperdagangkan pair tersebut: `token0()`/`token1()` untuk jenis berbentuk pair, penurunan ulang id pool untuk V4; pool yang ditanyai membuktikan hal yang sama sebelum penemuan mencantumkannya. | Hub `recordSwap`, `_probe`; `invariant_ActiveEntriesTradeThePair` | | INV-20 | Penyelesaian membayar biaya protokol tepat sekali pada rute berjangkar dan sekali per hop pada rute habis dicoba; penyelesaian yang tidak membayar apa pun tidak ada. | Buku besar biaya, `RouterE(15)`/`RouterE(16)`; `invariant_SettledSwapEmitsExactlyOneFee` (berjangkar); `test/FeeSeals.t.sol`, `test/ExhaustionRegimePreviewParity.t.sol` (habis dicoba) | | INV-21 | Hop berantai — input setiap hop adalah output hop sebelumnya — dan tidak ada leg tanpa hook yang dieksekusi setelah leg ber-hook, dalam hop ini maupun hop berikutnya (`sawHooked` berlaku di seluruh rute). | Router `_execute` → `RouterE(3)`; `sawHooked` | | INV-22 | Keempat kontrak yang di-deploy — Hub, Solver, Router, Quoter — dikirim di bawah gerbang 24,000 byte milik proyek pada profil rilis, library Core diukur terpisah (6,477 byte dari 24,576), dan suite berjalan pada profil tersebut. | `DeployedSizeGate`; `profile_parity.py` | | INV-23 | Pada setiap titik masuk staking yang mengenakan `conserves`, saldo ditambah utang ditambah utang macet tercatat berubah sebesar jumlah yang sama dengan stake ditambah kedua cadangan ditambah reward yang didistribusikan-namun-belum-dibayar, dalam 1e10 wei (E35). | Staking `conserves`, L419–457 → `Staking__InvariantBreached` | | INV-24 | Emisi terjadwal tidak pernah melebihi `TOTAL_REWARDS − (TOTAL_REWARDS >> 8)`; pendanaan kumulatif tidak pernah melebihi `TOTAL_REWARDS`; tidak ada jendela emisi yang membayar lebih dari yang dipegang `rewardReserve`. | `_emittedAt` L1458–1467; `fundEmission` L518 → `Staking__CapExceeded`; `_updateGlobal` L1442 | | INV-25 | Setiap kerugian yang terealisasi — kekurangan likuidasi, jalan keluar darurat yang terendam, bunga yang tidak dapat ditagih — menarik dari `protocolReserve` terlebih dahulu; hanya sisa yang tidak tertutup yang ditambahkan ke `totalBadDebt` (E37). | Staking L1101–1106, L704–709, L1657–1663 | | INV-26 | Selama saldo ditambah 1e10 berada di bawah `owed`, tidak ada deposit, pinjaman, penarikan, klaim reward atau pure-yield, penarikan cadangan maupun pembatalan darurat yang dieksekusi (E36). | `_hardBreach` menjaga L760, L826, L902, L932, L948, L1510, L539, L620 → `Staking__InvariantBreached` | | INV-27 | `absorbBadDebt` tidak memindahkan BZPX keluar, tidak membayar apa pun kepada pemanggil, dan menurunkan `totalBadDebt` paling banyak sebesar nilainya saat ini: cadangan terlebih dahulu, jumlah dari pemanggil dibatasi pada sisa yang tidak tertutup (E38). | `absorbBadDebt` L639–649 | | INV-28 | Total bobot emisi, bobot pure-yield dan ekuitas positif ditulis hanya oleh `_applyBoost`, yang mengganti suku terlacak sebuah posisi dengan suku yang dihitung ulang; kunci memperoleh boost hanya selama berlaku (E30). | `_applyBoost` L1726–1734; `_effectiveLockDays` L1687–1690 | | INV-29 | Pinjaman dieksekusi hanya jika utang baru paling banyak setengah dari stake bersih posisi sebelum pinjaman dan utilisasi buku sesudahnya paling banyak 75 % (E41). | `borrow` L834 → `Staking__LTVExceeded`; L838–840 → `Staking__UtilTooHigh` | | INV-30 | Jalan keluar darurat membayar paling banyak ekuitas bersih posisi dan paling banyak saldo kontrak, diskalakan dengan pot/E′ ketika saldo kurang dari ekuitas yang dilacak (E40). | `emergencyWithdraw` L689–696 | | INV-31 | Tidak ada penarikan, klaim pure-yield atau perubahan kunci yang dieksekusi dalam `MIN_DEPOSIT_BLOCKS` = 10 blok sejak deposit terakhir posisi. | L894, L947, L971 → `Staking__FlashLoanProtection` | ## Lampiran C · Perintah reproduksi Setiap angka dalam makalah ini yang berasal dari repositori direproduksi oleh salah satu perintah berikut, dari checkout bersih `Blaze-Phoenix-Dex` pada `8949a9d` dengan Foundry dan Python 3 terpasang; suite fork memerlukan kunci RPC arsip di `DRPC_KEY`. ```bash forge test --no-match-path 'test/fork/**' # the suite, release settings (§15.1) forge test --match-path 'test/fork/**' # the fork lane, five chains (§15.1, §17) FOUNDRY_PROFILE=release forge build --sizes --skip test --skip script # sizes against EIP-170 (§16.3) python3 .github/scripts/mutants.py # the curated mutation guard, 268/268 (§15.2) python3 .github/scripts/check_targets.py # every mutant still points at one line python3 .github/scripts/assurance/covering_array.py --check # both covering arrays current (§15.4) forge test --match-contract RegimeCoverageTest -vv # strength 2, 63 rows forge test --match-contract RegimeCoverageT3Test -vv # strength 3, 168 rows forge test --match-path test/regime/HostileVenueMatrix.t.sol # ten pathologies × two doors (§15.5) forge test --match-path test/regime/SandwichCurve.t.sol -vv # the sandwich curve (§14.3) forge test --match-path test/regime/CanonicalOracles.t.sol # the quote maths against the specifications (§15.6) forge test --match-path 'test/*MetamorphicRelations.t.sol' # 14 + 5 relations (§15.7) FOUNDRY_PROFILE=nver1 forge build --skip '*.t.sol' && FOUNDRY_PROFILE=nver2 forge build --skip '*.t.sol' NVERSION_LANE=1 forge test --match-path 'test/nversion/*' # the three binaries agree (§15.8) forge test --match-test invariant_ --fuzz-seed 0xb1a2ef00 # the stateful campaigns (§15.3) forge test --match-path test/FeeSeals.t.sol # the fee rule, both regimes (§13.4) forge test --match-path test/QuoteDelayStatistics.t.sol -vv # how a quote ages, 240 samples (§12.2) forge test --match-path test/QuoterGasStatistics.t.sol -vv # what a quote costs (§12.3) forge test --match-path test/fork/QuoteDelayFork.t.sol -vv # live Base, 1,000 USDC → WETH (§12.2) forge test --match-path test/fork/FidelityMatrix.t.sol -vv # preview → delivery, four chains (§17.2) forge test --match-path test/fork/DiscoveryColdWarm.t.sol -vv # cold and warm solve (§17.4) forge test --match-path test/EquationBench.t.sol -vv # ρ* (§17.6) forge test --match-path 'test/fork/Deployed*.t.sol' # what V1 is, pinned by codehash (§19) python3 .github/scripts/assurance/projection_distance.py # 86 / 99 (§15.9) python3 .github/scripts/assurance/metrics.py # every assurance number, with its denominator bash .github/scripts/shared-quantities.sh # the register agrees with the tree ``` Hash pada Contoh terhitung 4 direproduksi oleh implementasi keccak-256 mana pun atas `abi.encode(currency0, currency1, fee, tickSpacing, hooks)`; angka-angka makalah ini dihasilkan dengan Keccak-f[1600] Python murni yang diperiksa terhadap vektor uji string kosong dan `"abc"` serta terhadap selector `extsload(bytes32)` yang di-hard-code Core. ## Glosarium **Para operator.** | Simbol | Nama | Satu baris | |---|---|---| | Ω | Dispatcher Delapan Lipat | memberi harga setiap leg — bentuk tertutup di mana bentuk tertutup itu eksak, tanya-venue di mana bytecode venue itu sendiri adalah satu-satunya sumber yang jujur; "Delapan Lipat" menurut sejarah, enam jenis aktif saat ini | | 𝒟 | Penurunan Deterministik | menghitung alamat pool dengan aritmetika CREATE2 di mana deployment dapat direproduksi, bertanya lalu membuktikan pair di mana tidak, menurunkan dan membuktikan id pool untuk singleton V4; `hasCode` membuang apa yang tidak memiliki bytecode | | Φ | Lantai Iron-Law | lantai retensi milik protokol sendiri: 96 % dasar, melonggar menurut dampak terukur dan konsentrasi terukur, dijepit keras pada 80 %, diterapkan pada kuotasi di dalam frame dari hop terakhir | | Ψ | Medan Vitalitas | kualitas venue yang dihitung dari Monoslot saja; memeringkat dan memangkas himpunan kandidat — ia dapat menyembunyikan venue, tidak pernah salah memberi harga | | Ξ | proyektor anti-penipuan | menyingkirkan setiap rute yang menyentuh hook pengubah delta atau yang tidak dapat diadmisi dari maksimisasi, sebelum pemeringkatan, tanpa memanggil hook | **Istilah.** **Rezim berjangkar** — biaya dibebankan sekali, pada koin jembatan pertama yang dipegang Router (atau pada output rute langsung ke sebuah koin jembatan). **Pita kepercayaan** — ±5 % di sekitar median berbobot kedalaman dari tarif marginal para kandidat; tidak bekerja pada himpunan kandidat tunggal. **Gerbang cakupan** — batas teratestasi sebuah leg yang diangkat ke kuotasi terukur ketika atestasi mencakup kurang dari separuhnya. **Exact Pass** — pratinjau Quoter yang eksak per pool: swap milik venue itu sendiri dijalankan dan digulung kembali melalui ekstraksi revert; bersih dari biaya sejak 2026-09-03. **Rezim habis dicoba** — tidak ada koin jembatan sebagai input hop mana pun: setiap hop membayar 28 bps atas input terukurnya sendiri; kebal terhadap prefiks tanpa nilai menurut konstruksi. **Buku besar biaya** — hitungan transien pembayaran biaya per penyelesaian, menolak nol dan menolak dua pada rute berjangkar. **Desain Metrologis** — bangun kontrak sebagai instrumen: runtuhkan keragaman menjadi koordinat, ukur setiap koordinat yang dapat diukur, jadikan sisanya monoton. **Meta-Persamaan** — seluruh agregator sebagai satu maksimisasi, berupa hasil kali sehingga satu faktor yang gagal menolkan rute. **Monoslot** — seluruh keadaan perutean sebuah pool dalam satu kata 256-bit, tanpa harga di dalamnya. **Doktrin Satu Callback** — satu `fallback` menjawab callback flash-accounting setiap venue berbentuk V3, dijaga tiga cara. **Pintu Satu Arah** — pelepasan sebagai bytecode: tingkat kendali mati, tingkat kurator yang hanya-bertambah tetap ada. **Pair-proof** — sebuah pool membuktikan `token0`/`token1`-nya (atau id yang diturunkan ulang) sebelum registri menyimpannya atau penemuan mencantumkannya. **Jarak proyeksi** — seberapa jauh objek yang teramati dari sebuah penolakan berada dari objek yang memutuskan. **Registri Swa-Pulih** — protokol mempelajari likuiditas dengan memperdagangkannya: enam belas slot per pair, eviksi berperingkat kebugaran, peluruhan dengan aritmetika. **Aturan Surplus** — bagian protokol adalah 28 bps dari satu basis terukur dan tidak ada yang berskala dengan selisih antara kuotasi dan penyerahan. **Jalan ketiga** — hasil fixture apa pun yang bukan penyelesaian di dalam lantai dengan tidak ada yang tersisa pada Router, bukan pula penolakan dengan selector milik kita. ## Referensi 1. G. Angeris, A. Evans, T. Chitra, S. Boyd. *Optimal Routing for Constant Function Market Makers.* arXiv:2204.05238, 2022 (ACM EC '22). — Perutean atas CFMM sebagai program konveks; optimum yang tidak dicapai oleh alokator proporsional pada §10.4. 2. T. Diamandis, M. Resnick, T. Chitra, G. Angeris. *An Efficient Algorithm for Optimal Routing Through Constant Function Market Makers.* arXiv:2302.04938, 2023 (Financial Cryptography 2023). — Algoritma dekomposisi dual untuk masalah yang sama (§23). 3. H. Adams, N. Zinsmeister, D. Robinson. *Uniswap v2 Core.* 2020. https://uniswap.org/whitepaper.pdf — Acuan constant-product dan default 30 bps pada §4.2. 4. H. Adams, N. Zinsmeister, M. Salem, R. Keefer, D. Robinson. *Uniswap v3 Core.* 2021. https://uniswap.org/whitepaper-v3.pdf — Likuiditas terkonsentrasi, `slot0`, bilangan titik tetap Q64.96 (§4.2, §15.6). 5. Uniswap Labs (H. Adams et al.). *Uniswap v4 Core.* 2024. https://uniswap.org/whitepaper-v4.pdf — PoolManager singleton, flash accounting, dan pengodean izin hook pada alamat (§5, §14.2). 6. M. Egorov. *StableSwap — Efficient Mechanism for Stablecoin Liquidity.* 2019. https://curve.fi/files/stableswap-paper.pdf — Invarian teramplifikasi dari keluarga yang dikeluarkan pada §4.1. 7. P. Daian, S. Goldfeder, T. Kell, Y. Li, X. Zhao, I. Bentov, L. Breidenbach, A. Juels. *Flash Boys 2.0: Frontrunning in Decentralized Exchanges, Miner Extractable Value, and Consensus Instability.* IEEE S&P 2020. DOI 10.1109/SP40000.2020.00040. — Musuh pengurutan yang dibatasi oleh §14.3 alih-alih diklaim dapat dihapuskan. 8. L. Zhou, K. Qin, C. F. Torres, D. V. Le, A. Gervais. *High-Frequency Trading on Decentralized On-Chain Exchanges.* IEEE S&P 2021. DOI 10.1109/SP40001.2021.00027. — Serangan sandwich yang diukur dan diformalkan (§14.3). 9. P. Cousot, R. Cousot. *Abstract Interpretation: A Unified Lattice Model for Static Analysis of Programs by Construction or Approximation of Fixpoints.* POPL 1977. DOI 10.1145/512950.512973. — Kerangka bagi bentuk tertutup satu-tick sebagai abstraksi yang sahih (§23). 10. M. R. Clarkson, F. B. Schneider. *Hyperproperties.* Journal of Computer Security 18(6), 2010. DOI 10.3233/JCS-2009-0393. — Properti atas himpunan jejak; kelas tempat temuan redistribusi berada (§21, §23). 11. T. Y. Chen, S. C. Cheung, S. M. Yiu. *Metamorphic Testing: A New Approach for Generating Next Test Cases.* HKUST-CS98-01, 1998; arXiv:2002.12543. — Hakim kedua pada §15.7. 12. R. A. DeMillo, R. J. Lipton, F. G. Sayward. *Hints on Test Data Selection: Help for the Practicing Programmer.* IEEE Computer 11(4), 1978. DOI 10.1109/C-M.1978.218136. — Analisis mutasi dan hipotesis keterkaitan (§15.2). 13. A. Avizienis. *The N-Version Approach to Fault-Tolerant Software.* IEEE TSE SE-11(12), 1985. DOI 10.1109/TSE.1985.231893. — Leluhur dari §15.8. 14. D. R. Kuhn, R. N. Kacker, Y. Lei. *Practical Combinatorial Testing.* NIST SP 800-142, 2010. DOI 10.6028/NIST.SP.800-142. — Covering array dan cakupan interaksi t-arah (§15.4). 15. B. Littlewood, L. Strigini. *Validation of Ultrahigh Dependability for Software-Based Systems.* Communications of the ACM 36(11), 1993. DOI 10.1145/163359.163373. — Mengapa tidak ada probabilitas kebenaran yang dinyatakan (§15.11). 16. A. Akhunov, M. Salem. *EIP-1153: Transient Storage Opcodes.* https://eips.ethereum.org/EIPS/eip-1153 — Konteks leg, buku besar biaya, dan kunci reentrancy (§11.4, §13.2). 17. V. Buterin. *EIP-170: Contract Code Size Limit.* https://eips.ethereum.org/EIPS/eip-170 — Dinding 24,576 byte (§16.3). 18. V. Buterin. *EIP-1014: Skinny CREATE2.* https://eips.ethereum.org/EIPS/eip-1014 — Aritmetika alamat milik 𝒟 (§7). 19. M. Lundfall et al. *EIP-2612: Permit Extension for EIP-20 Signed Approvals.* https://eips.ethereum.org/EIPS/eip-2612 · Uniswap Labs. *Permit2.* https://github.com/Uniswap/permit2 — Pintu Permit2 (§11.1). 20. V. Buterin, S. Wilson, A. Dietrichs, M. Garnett. *EIP-7702: Set Code for EOAs.* https://eips.ethereum.org/EIPS/eip-7702 — Akun yang didelegasikan memanggil pintu yang sama (§11.1). 21. *ERC-7201: Namespaced Storage Layout.* https://eips.ethereum.org/EIPS/eip-7201 — Namespace penyimpanan milik Hub (§16.1). 22. MariaDB Corporation Ab. *Business Source License 1.1.* https://mariadb.com/bsl11/ — Lisensi kode. 23. Fable & Mitra. *BlazePhoenix-Dex: an on-chain DEX aggregator with measured routing.* Repository, `main` 8949a9d, 2026-09-05. https://github.com/blazephoenixxyz-crypto/Blaze-Phoenix-Dex — Sumber kanonis untuk setiap klaim dalam makalah ini; Lampiran C mereproduksi angka-angkanya darinya. 24. S. Müller, N. Moumeni, A. Messaoudi. *Cost of Manipulation in AMM-Based Oracles.* arXiv:2606.03548, 2026 (Financial Cryptography 2026, DeFi workshop). — Batas median berbobot likuiditas di balik E25 (§10.3, §23). 25. *Ormer: A Manipulation-resistant and Gas-efficient Blockchain Pricing Oracle for DeFi.* arXiv:2410.07893. — Oracle on-chain yang mengestimasi median (§23). 26. *From Means to Medians: Optimal Benchmark Design.* arXiv:2506.22142. — Tolok ukur mana yang paling sulit dimanipulasi (§23). 27. *Optimal Routing across Constant Function Market Makers with Gas Fees.* arXiv:2603.02844. — Perutean dengan gas (§23). 28. *Routing Frictions and Executable Liquidity in Fragmented Markets.* arXiv:2609.19013. — Likuiditas yang diiklankan versus yang dapat dieksekusi (§23). ## Cara mengutip Mitra. *BlazePhoenix Technical Whitepaper: an on-chain liquidity aggregator whose quote and execution are one computation.* Versi 2.3.0, 2026-10-14. Zenodo. DOI [10.5281/zenodo.23084091](https://doi.org/10.5281/zenodo.23084091) (v2.3 yang dideposit). Semua versi: [10.5281/zenodo.23084090](https://doi.org/10.5281/zenodo.23084090). Concept DOI dari rangkaian deposit pertama (v2.2): [10.5281/zenodo.22526574](https://doi.org/10.5281/zenodo.22526574). BibTeX dan format lain: https://blazephoenix.xyz/research/whitepaper