Saya mulai melakukan staking RLS sejak tahap janji yang telah ditetapkan; membaca blog resmi sudah jadi kebiasaan. Pada 12 September, artikel yang membahas kemampuan untuk diaudit—di paruh kedua, ia mencantumkan enam standar, mengatakan bahwa seluruhnya terpenuhi secara paksa melalui konstruksi matematika. Saya setuju dengan pernyataan itu, tetapi “terpenuhi melalui konstruksi” adalah pernyataan yang bisa diverifikasi, bukan sesuatu yang hanya perlu dipercaya. Jadi saya menghabiskan waktu seminggu untuk mencari bukti untuk keenam poin tersebut di kode sumber publik, dokumentasi teknis, dan antarmuka on-chain; sekarang saya bagikan kepada kalian semua.
Pertama, mari bahas kategorisasinya. Saya menganggap itu lebih berguna dibanding sebagian besar diskusi tentang “privasi tetapi tetap transparan”. Untuk auditabilitas, ada tiga jalur: paksaan matematis—yang ditulis ke dalam konstruksi kriptografi; kepercayaan perangkat keras—bergantung pada integritas lingkungan eksekusi tepercaya; dan kontrol akses berbasis kebijakan—siapa yang dapat melihat apa ditentukan oleh konfigurasi dari pihak operator jaringan.
Berdasarkan itu, ia mengajukan enam standar auditabilitas tingkat institusi, lalu mengatakan bahwa matematik memaksa untuk memenuhi keenamnya melalui konstruksi.
Agar tidak makin lama makin abstrak, saya kunci ke sebuah skenario: sebuah bank berpartisipasi dalam uji coba central bank digital currency; auditor bank sentral perlu melihat transaksi bank tersebut di jaringan. Drex dari Brasil adalah skenario itu, dan Rayls sedang melakukan pilot di dalamnya. Hanya ada satu pertanyaan yang harus dijawab: mengapa yang dilihat auditor bisa dipercaya.
Untuk butir pertama dan kedua: selective disclosure dan pembatasan ruang lingkup.
Dua butir ini bermuara pada hal yang sama: observation key.
GitHub Rayls terbuka; di direktori cryptography pada repositori relayer ada file mlkem.go. Di situ ada GenerateSalt yang menggunakan enkapsulasi observation public key ML-KEM-768 milik penerima untuk berbagi shared key; RecoverSalt mendekapsulasi menggunakan observation private key ML-KEM-768 lokal; ia memanggil NewEncapsulationKey768 dan NewDecapsulationKey768 dari pustaka standar Go. Nama variabelnya persis view public key dan view secret key.
Jadi fondasi kriptografi untuk observation key adalah ML-KEM-768, dan ini ada landasannya untuk diverifikasi.
Tambahkan sedikit konteks tentang maknanya. Pada 30 Agustus, artikel Rayls tentang persiapan kuantum secara khusus menekankan: jika klaim keamanan kuantum tidak ditulis sampai level parameter, itu bukanlah klaim melainkan hanya label, dan contoh yang diberikan memang tepat membedakan bahwa ML-KEM-512 dan ML-KEM-1024 itu hal yang berbeda. Saat membahas peningkatan mereka sendiri, artikel itu hanya menulis "sudah diganti dengan ML-KEM". Di kode tertulis 768. Ini bukan cacat; 768 adalah set parameter resmi NIST dan juga nilai default rekomendasi industri untuk deployment perusahaan. Ini hanya fakta yang sebelumnya butuh membaca kode untuk mengetahuinya, dan sekarang bisa langsung dirujuk.
Karena tingkat sudah ditetapkan, biaya untuk pindah tingkat bisa dihitung. FIPS 203 mengunci ukuran: public key terenkapsulasi 768 menjadi 1184 byte, ciphertext 1088 byte, dan 1024 untuk keduanya adalah 1568 byte.
Kuncinya adalah frekuensi, dan dokumentasi manajemen kunci juga menuliskannya: enkapsulasi dilakukan satu kali untuk setiap pasangan partisipan saat jaringan dibangun; ciphertext disimpan di private network hub; setelah itu setiap pesan hanya membawa satu label kecil. Jadi ia tidak bertambah seiring volume transaksi. Sebuah jaringan 30 institusi memiliki 435 pasangan; selisih antara dua tingkatan sekitar 215 KB. Bahkan jika 60 institusi dan 1770 pasangan, selisihnya tetap tidak lebih dari 1 MB, dan itu sekali saja.
Nilainya begitu kecil sampai tidak ada artinya, dan justru dari situlah kesimpulannya: jika suatu deployment membutuhkan tingkat yang lebih tinggi, hambatannya tidak berasal dari bandwidth atau storage; itu hanyalah perubahan kode. Dalam diskusi migrasi post-kuantum yang umum, pemilihan parameter sering kali merupakan trade-off performa—pada lapisan ini tidak.
Batasi hanya pada satu ketentuan ini; dokumentasi teknis menambahkan setengah lainnya: kemampuan observasi dapat dibatasi berdasarkan jendela waktu dan berdasarkan akun.
Butir ketiga, pemisahan visibilitas dan izin
Cara dokumentasi teknis menyatakannya lebih keras daripada blog: spending key dan observation key saling independen secara matematis, tidak bisa diturunkan dari satu sama lain. Dalam ringkasan tinjauan keamanan, kalimatnya lebih langsung: izin pengamatan dan izin pengeluaran dipisahkan oleh kriptografi, bukan konfigurasi; jadi satu kali kesalahan konfigurasi tidak bisa mengubah izin baca menjadi izin tulis.
Dokumen manajemen kunci juga mengoreksi asumsi saya yang keliru. Semua materi kunci di sisi institusi diproses secara terpusat oleh sebuah komponen bernama Cryptographic Trust Suite, yang berjalan di dalam batas milik institusi sendiri. Relayer tidak pernah memegang kunci apa pun; hanya diminta untuk melakukan enkripsi dan dekripsi. Izin baca auditor berasal dari: setiap institusi mengenkripsi observation key mereka sendiri menggunakan public key pihak pengelola, lalu menyimpannya bersama sebuah kode autentikasi ke private network hub, sebagai bagian dari catatan pihak partisipan; layanan audit mengambilnya kembali saat proses dimulai.
Ada produk sampingan dari dokumen ini yang sendiri menyorot: institusi dapat melihat catatan pihak-pihak partisipan mana yang ada di hub, sehingga mereka tahu hal apa saja yang diset agar bisa dibaca. Pemberian visibilitas itu sendiri dapat dilihat.
Sekalian, tiga jenis tabel kunci di halaman ini juga menguatkan apa yang saya lihat di kode: kunci tanda tangan pada ECDSA di secp256k1, observation key pada ML-KEM, dan kunci pembelanjaan pada Baby JubJub di BN254. Dokumentasi dan kode sumber benar-benar cocok.
Butir keempat, correct-by-verification (kebenaran yang dapat diverifikasi)
Blog ini mengandalkan zero-knowledge proofs; Rayls menyediakan layanan gnark-api khusus untuk menghasilkan dan memverifikasi bukti Groth16.
Dokumen transaksi Enygma memberikan beberapa parameter spesifik yang biasanya tidak pernah dirujuk. Ukuran anonymous set adalah 2 atau 6: artinya setiap transfer digabung dengan satu transfer lain atau lima transfer lain, sehingga pengamat tidak bisa membedakan siapa yang memulai. Satu crossTransfer maksimal menargetkan 5 chain tujuan dan membawa 5 aksi yang dapat dipanggil. Atomisitas batch dijamin oleh kontrak Enygma di private network hub: ia memverifikasi bukti seluruh batch terlebih dahulu, baru kemudian mata uang dicetak; hanya jika semua tujuan terpenuhi, pencetakan dilakukan.
Ada satu lagi biaya operasional yang ditulis sangat terus terang dalam dokumen: jika digabungkan, batch processing, pembuatan bukti, dan verifikasi hub jumlahnya puluhan detik skala, jadi harus direncanakan seperti itu, bukan seperti finalitas tingkat sub-detik untuk transaksi internal institusi. Validitas yang bisa diverifikasi tidak gratis; harganya adalah puluhan detik itu.
Namun ada satu bagian redaksi yang layak diangkat sendiri, karena itu melibatkan empat dokumen.
Dokumentasi teknis mengatakan bahwa komitmen Pedersen "menyembunyikan sebuah nilai, sekaligus mengikat pihak komitmen ke nilai tersebut, sehingga tidak bisa diubah setelahnya"—mereka menjadikan sifat keterikatan sebagai properti yang ditegaskan. Artikel kuantum pada bulan Agustus menandai bagian ini sebagai tidak perlu penanganan, artinya memang sudah tahan terhadap kuantum. Di kode, enygma_math.go menunjukkan bahwa konstruksi Pedersen tersebut memakai dua generator independen pada kurva BabyJubJub, menghitung v dikali G ditambah r dikali H—itu konstruksi Pedersen standar dan benar. Lalu, dua paper akademik Rayls, dengan nomor IACR 2025/1639 dan 2025/1638: istilah yang dipakai untuk keseluruhan desain adalah quantum-private, yakni privasi kuantum; penjelasannya adalah bahwa lawan kuantum tidak dapat menyimpulkan pembayaran, penerima, dan nominal transaksi. Ini adalah klaim murni tentang kerahasiaan.
Pembacaan saya: dari empat materi, hanya istilah yang dipakai paper yang presisi. BabyJubJub dibangun di domain skalar BN254, sehingga kerahasiaan berlaku untuk lawan kuantum; ini adalah bagian klaim paper. Keterikatan bergantung pada discrete logarithm, dan ini adalah bagian yang tidak diklaim oleh paper.
Bagi sebuah institusi yang harus dapat membuktikan posisi kepatuhan terhadap pengawasan yang bersifat adversarial, "lawan kuantum tidak dapat melihat saldo saya" dan "lawan kuantum tidak dapat memalsukan saldo palsu" adalah dua hal berbeda, tetapi keduanya ditulis sebagai satu hal di dokumen dan blog. Paper tidak melakukan penggabungan itu.
Butir kelima, dapat dicabut (revocable)
Saya sudah lama mencari yang ini. Dokumentasi Rayls punya satu halaman bernama dokumen opsi desain private network, di situ saya menemukan jawabannya. Tapi itu bukan hal yang sama dengan yang dibahas di blog, dan saya justru menganggapnya lebih menarik.
Auditor adalah peran yang ditunjuk oleh pihak pengelola, dan yang sejajar adalah pihak partisipan serta pihak penerbit. Intinya adalah visibilitas auditor bukanlah saklar, melainkan bergantung pada tingkat; dokumen ini menunjukkan tingkatan melalui tiga contoh.
Untuk level jaringan mata uang digital bank sentral, auditor dapat mendekripsi transaksi antar-node. Untuk level platform perdagangan aset tokenized, auditor memantau dengan memverifikasi komitmen Pedersen yang dipublikasikan tiap node ke hub; dokumentasinya secara gamblang menyatakan auditor tidak memiliki akses langsung ke data payload transaksi terenkripsi, hanya melihat bukti, tidak melihat kontennya. Untuk level paling ekstrem, yaitu marketplace NFT yang dijalankan DAO, peran audit dipegang oleh verifikator yang dibuktikan oleh public chain; akses default-nya nol. Hanya ketika verifikasi bukti menunjukkan adanya penipuan, dekripsi untuk transaksi tersebut diaktifkan.
Tiga tingkatan ditaruh bersebelahan; kalimat tentang browser auditor, "tingkat dekripsi bisa dikonfigurasi saat tahap pembangunan", langsung menjadi nyata.
Kembali ke satu bagian dari blog itu. Blog mengatakan visibilitas bisa dicabut dan pencabutan dipaksakan oleh kriptografi. Dokumentasi memberikan desain yang berbeda: visibilitas ditetapkan berdasarkan tingkat saat jaringan dibangun, bukan dicabut setelah kejadian. Keduanya sama-sama membatasi auditor: yang satu adalah pengendalian sebelum, yang lain adalah pembatalan setelah.
Memang ada cara pencabutan di layer tata kelola: peran bisa diperbarui, status anggota bisa aktif, dibekukan, atau dinonaktifkan; pembekuan dieksekusi oleh pihak pengelola melalui kontrak tata kelola ParticipantStorage. Namun untuk mencabut visibilitas yang sudah didapat seorang auditor, saya tidak menemukan deskripsi implementasinya. Ada detail yang membuat masalah ini jadi sangat spesifik: dokumentasi mengatakan auditor menerima pertukaran kunci Diffie-Hellman satu kali saat setiap node baru bergabung, dan kemampuan akses diserahkan dalam bentuk materi kunci. Mencabut peran bisa menghalangi pemberian di masa depan, tetapi apakah materi kunci yang sudah diserahkan bisa dibuat tidak berlaku—itu masih saya teliti.
Butir keenam, persistensi
Butir ini berlawanan dengan butir kelima: blog malah mengecilkan persoalan; mereka menulis seolah kurang penting.
Ia mengatakan persistensi menjadi milik manajemen kunci dan dapat diselesaikan—cara membacanya terasa seperti ada bagian yang kosong. Namun dokumentasi manajemen kunci sudah mengubah "bisa diselesaikan" itu menjadi rencana yang spesifik. Penyimpanan kunci dapat dipasang-pasangkan ke sistem yang sudah dimiliki institusi: AWS KMS, Google Cloud KMS, Azure Key Vault, local HSM; lingkungan pengembangan hanya memakai file lokal. Enkripsi statis lewat envelope, dan yang dipersistensikan adalah ciphertext, bukan materi kunci.
Yang paling penting adalah kalimat ini. Karena setiap proses enkripsi/dekripsi melewati layanan manajemen kunci milik institusi sendiri, jejak audit yang dihasilkan oleh layanan tersebut memang sudah ada. Menimpa jejak audit untuk key milik Rayls itu sama saja dengan menimpa jejak audit hal lain yang dijalankan institusi itu sendiri. Kesimpulan untuk divisi kepatuhan yang diberikan dokumen adalah: tidak perlu membangun bidang audit baru untuk itu. Ini persis yang diinginkan persistensi: jejak audit menempel pada sistem institusi itu sendiri, bukan pada log privat milik pemasok.
Rotasi juga ditulis sangat rinci: setiap chain bisa memiliki beberapa kunci tanda tangan; rotasi dilakukan sesuai kebutuhan penggunaan. Masing-masing kunci dilacak nonce-nya sendiri-sendiri. Kunci yang sudah digunakan untuk menandatangani transaksi yang masih diproses tetap berlaku sampai transaksi-transaksi itu selesai diselesaikan. Ini tepat menyelesaikan celah yang paling mudah bermasalah pada rotasi.
Namun ada satu batas: bagian yang mendeskripsikan rotasi membahas kunci tanda tangan; saya tidak melihat rotasi observation key di halaman-halaman ini. Sedangkan persistensi justru peduli apakah jejak audit masih bisa dibaca bertahun-tahun kemudian—dan itu lebih bergantung pada sisi observation key.
Alat yang benar-benar digunakan auditor
Di bagian awal semuanya bicara tentang kriptografi, tapi auditor sebenarnya duduk dan memakai sebuah alat. Dokumentasinya menjelaskan bahwa private network auditor browser hanya bisa diakses oleh auditor, pihak pengelola dan partisipan lain tidak bisa. Ia memberi tampilan “after decryption” untuk transaksi lintas-chain.
Pembatasan ruang lingkup: hanya mencakup transaksi lintas-chain yang direkam ke private network hub; transaksi yang terjadi di dalam ledger Sovereign milik institusi tertentu itu sendiri tidak dapat diakses auditor. Jadi, visibilitas untuk audit adalah antar institusi, bukan di dalam institusi.
Lalu, apakah ada sebuah contoh yang bisa diverifikasi sepenuhnya
Ada, dan hanya satu: karena arsitekturnya sendiri yang menentukan sebagian besar hal tidak dapat dilihat.
Dokumentasi resmi menjelaskan alasannya: transaksi Enygma berasal dari ledger Sovereign milik masing-masing institusi; setiap institusi sendiri melakukan deployment browser untuk memantau ledger tersebut. Bagian lintas-chain ditangani oleh private network hub dan dilihat oleh auditor browser. Aktivitas institusi sesuai desain tidak ada di public chain, sehingga Anda tidak akan menemukan transaksi Enygma di browser public chain; ini bukan kekurangan, melainkan hasil yang tak terhindarkan dari arsitektur tiga lapis.
Namun kontrak penguncian Parfin itu ada di public chain, dan kebetulan merupakan sampel lengkap dari "matematik memaksa".
Alamat yang diawali 0x1463889D, nama kontraknya RlsTokenLock—kode sumber sudah diverifikasi, bukan kontrak proxy. Ini berarti ia termasuk sedikit objek yang bisa dibaca kodenya sekaligus dicek status terkini. Saya mencocokkan keduanya.
Konstruktor menyatakan totalAmount adalah 1.070.493.535 RLS. RLS yang saat ini benar-benar dipegang kontrak adalah 1.070.493.535. Tidak ada satu wei pun yang kurang, benar-benar penuh.
Jadwal unlock lebih layak dibicarakan. Di konstruktor ada 48 timestamp; semuanya saya dekode: tingkat pertama 1 Desember 2027, setelah itu tiap tanggal 1 setiap bulan, tingkat terakhir 1 November 2031; rentangnya sekitar 3,92 tahun; kira-kira 22,3 juta RLS per tingkat. Materi publik sebelumnya menekankan penguncian hingga Desember 2027, itu adalah tingkat pertama, benar; gambaran lengkap dari konstruktor adalah setelah tingkat pertama masih ada pelepasan bulanan hampir empat tahun.
Komentar di dalam kontraknya sendiri menuliskan niat desain secara gamblang: tidak dapat diupgrade; klausul saat deployment adalah klausul yang berlaku selamanya; tidak ada unlock lebih awal, sehingga kunci apa pun tidak bisa pindah tingkat sebelum tanggal kedaluwarsa. Dua hal ini saya cocokkan satu per satu dengan kode: jadwal ditulis di constructor tanpa setter, dan kontraknya memang bukan proxy.
Inilah wujud "matematik memaksa" pada sebuah contoh yang bisa saya verifikasi sepenuhnya: pernyataan selaras dengan kode, dan kode lebih spesifik daripada pernyataannya. Hal-hal yang hanya bisa saya temukan jejaknya di kode sumber dan dokumentasi di enam standar itu, di sini bisa dilihat sampai tuntas.
Dua kutipan eksternal lainnya
Blog saat membahas TEE mengatakan bahwa Intel SGX pernah memiliki celah yang tercatat karena merusak jaminan isolasi. Pernyataan itu benar, tapi mereka mengecilkan argumen mereka sendiri. Celah kelas isolasi misalnya Foreshadow, Plundervolt, EPIC Leak, SmashEx, dengan nomor masing-masing CVE-2018-3615, CVE-2019-11157, CVE-2022-21233, CVE-2021-0186, dan CVE-2021-33767. Yang paling mematikan justru SGAxe dari tahun 2020: dengan menggunakan CVE-2020-0549, ia mengekstrak kunci autentikasi dari enclave autentikasi di lingkungan produksi Intel; setelah itu ia bisa mengeluarkan pernyataan apa pun yang dinilai legal oleh layanan autentikasi buatan Intel.
Argumen blog adalah jaminan TEE disediakan oleh bukti yang dikeluarkan oleh perangkat keras, dan SGAxe justru membobol bagian yang mengeluarkan bukti tersebut. Kegagalan paling serius bukanlah data dicuri, melainkan jaminannya sendiri dipalsukan. Untuk adil, semuanya sudah diperbaiki melalui update microcode dan TCB recovery; SGX hari ini bukanlah SGX tahun 2018. Ungkapan yang lebih akurat adalah: root of trust perangkat keras memiliki permukaan celah yang bergulir.
Yang lainnya adalah ia mengatakan BIS Project Agora sedang mengarah ke arsitektur yang sama. Saya membaca laporan prototipe BIS tanggal 27 Mei: topologinya memang mirip, dengan struktur dua lapis, shared ledger ditambah ledger independen untuk tiap wilayah. Namun batas Agora itu ditetapkan lewat yurisdiksi; laporan tidak menjelaskan bagaimana kontrol akses di dalam ledger yurisdiksi diterapkan. Jadi apakah penyempitan itu sampai ke level model kepercayaan, dari materi publik yang ada sekarang tidak terlihat.
Mana yang sudah dikonfirmasi, mana yang merupakan dugaan saya
Yang dikonfirmasi: ML-KEM-768 digunakan untuk observation key, lihat relayer's cryptography/mlkem.go; Pedersen menggunakan konstruktor generator ganda untuk BabyJubJub, lihat enygma_math.go; private key audit dienkripsi dan didistribusikan oleh relayer, lihat cryptography/service.go dari layanan tata kelola; kunci belanja (spending key) dan observation key secara matematis independen, observasi bisa dibatasi berdasarkan waktu dan akun, browser auditor hanya mencakup transaksi lintas-chain dan tingkat dekripsi bisa dikonfigurasi saat tahap pembangunan; semuanya ada dalam dokumentasi teknis resmi. Cryptographic Trust Suite memegang kunci secara terpusat dan Relayer tidak pernah memegang kunci; penyimpanan kunci dapat dipasang ke KMS atau HSM; enkripsi envelope statik; log audit layanan manajemen kunci milik institusi yang mencatat operasi kunci sebagai jejak audit; kunci tanda tangan berotasi sesuai penggunaan dan kunci yang menandatangani transaksi yang menunggu penyelesaian tetap berlaku sampai transaksi itu selesai; enkapsulasi dilakukan satu kali saat membangun jaringan berdasarkan partisipan; ukuran anonymous set adalah 2 atau 6; satu crossTransfer menargetkan maksimal 5 chain tujuan; finalitas berskala puluhan detik; pembekuan pihak partisipan dieksekusi oleh kontrak tata kelola ParticipantStorage oleh pihak pengelola; semuanya ada dalam dokumentasi teknis resmi. Status verifikasi RlsTokenLock, sifat non-proxy, jadwal 48 tingkat, pernyataan jumlah dan saldo aktual—semuanya dibaca melalui antarmuka browser publik pada 12 September 2026. Nomor-nomor celah SGX berasal dari catatan CVE dan paper SGAxe. Struktur dan data Agorá berasal dari materi publik BIS.
Dugaan saya: dari empat dokumen, hanya paper yang memakai istilah tentang Pedersen yang benar-benar presisi. "Batas dipaksakan oleh matematika" menggambarkan eksekusi, bukan distribusi. SGAxe lebih mampu menopang argumen blog dibanding jenis celah yang bersifat isolasi. Tiga dokumen ini tidak menulis seperti itu.
Yang tidak berhasil diverifikasi: mekanisme pencabutan setelah kejadian pada butir kelima. Saya menelusuri lima dokumen: manajemen kunci, browser auditor, dasar kriptografi Enygma, pembekuan pihak partisipan, opsi desain private network, serta dokumen private network hub; ditambah dua repositori kode: relayer dan layanan tata kelola. Saya menemukan konfigurasi tiga tingkat visibilitas, mekanisme pemberian, serta pembekuan dan penonaktifan pihak partisipan; tetapi saya tidak menemukan implementasi untuk mencabut visibilitas yang sudah diberikan dan kemudian dipaksakan oleh kriptografi. Observasi rotasi jangka panjang untuk observation key juga tidak saya temukan—bagian yang mendeskripsikan rotasi di dokumen itu membahas kunci tanda tangan.
Terakhir, ada satu hal yang tidak berhubungan dengan teknis
Pada minggu yang sama saat tulisan ini dibuat, pihak resmi mengumumkan bahwa 55% tingkat staking diperpanjang hingga 15 September, dan mengatakan bahwa saat penyesuaian mekanisme staking, pendukung awal akan tetap memperoleh bagian dari imbalan tersebut; pembaruan berikutnya tentang staking dan ekonomi token yang lebih luas termasuk pembakaran akan diumumkan kemudian.
Saya sudah melakukan staking sejak tahap komitmen sebelumnya, ikut penuh selama tiga bulan. Tadinya tingkatnya berakhir pada 9 September; pada beberapa hari itu saya melihat di antarmuka bahwa kuotanya sudah habis dan tidak bisa ditambahkan, sehingga sempat mengira masalahnya ada di frontend. Sekarang saya lihat mekanismenya sedang disesuaikan.
Bagian ini adalah opini pribadi saya, bukan pernyataan fakta: pada masa jendela ketika mekanisme diubah, mereka memilih memperpanjang alih-alih memutus langsung, dan juga menuliskan tanggalnya dengan jelas. Menurut saya itu adalah sikap yang menunjukkan itikad baik. Yang paling mudah terjadi pada periode penyesuaian mekanisme adalah bahasa yang ambigu; memberikan tanggal yang pasti berarti masa berlaku berakhir—uang harus ditebus atau dijelaskan ulang sekali lagi.
Ini hanya sebuah kejadian spesifik, tidak merupakan penilaian terhadap pengaturan jangka panjang apa pun. Saya tidak memprediksi hasil, dan juga tidak menyarankan siapa pun mengambil keputusan berdasarkan hal ini.
Sumber referensi: blog resmi Rayls Auditability without surveillance: why mathematical enforcement beats trusting the code, 12 September 2026; dua halaman dokumentasi teknis resmi Rayls tentang dasar kriptografi Enygma dan private network auditor browser; repositori GitHub organisasi raylsnetwork: rayls-sovereign-relayer dan rayls-sovereign-pnh-governance; antarmuka explorer.rayls.com milik public chain Rayls untuk addresses dan smart-contracts, waktu pengambilan data 12 September 2026; NIST FIPS 203; catatan CVE 2018-3615, 2019-11157, 2020-0549, 2021-0186, 2021-33767, 2022-21233 dan paper SGAxe; laporan prototipe BIS Project Agorá othp110; arsip elektronik kriptografi IACR 2025/1638 dan 2025/1639; pengumuman akun X resmi Rayls pada 12 September 2026.
