Bagian yang paling penting menurut saya tentang Newton Protocol adalah bahwa ia tidak memperlakukan aturan sebagai sesuatu yang berada di luar transaksi.
Di banyak sistem DeFi, aturan memang ada, tetapi aturan tersebut berada di tempat yang lemah.
Sebuah tim mungkin memiliki aturan risiko dalam sebuah dokumen.
Sebuah frontend mungkin memblokir beberapa pengguna.
Sebuah dasbor mungkin menampilkan sinyal peringatan.
Seorang manajer mungkin mengikuti kebijakan internal.
Penyedia kepatuhan mungkin menandai (flag) sebuah alamat setelah aktivitas terjadi.
Hal-hal ini bisa membantu, tetapi itu tidak sama dengan penegakan (enforcement).
Ide Newton berbeda. Ia mencoba mengubah aturan menjadi bagian langsung dari eksekusi. Sebuah transaksi tidak hanya perlu mengatakan, “Saya ingin mengeksekusi.” Ia juga harus membuktikan bahwa transaksi tersebut telah lolos aturan sebelum smart contract mengizinkannya.
Itulah poin utama dari alur Newton:
Kebijakan → Intent → Tugas → Attestation → PolicyClient
Alur ini terdengar teknis, tapi idenya sederhana.
Kebijakan mendefinisikan aturan.
Maksud/intent menggambarkan transaksi.
Sebuah tugas meminta operator Newton untuk mengevaluasi transaksi tersebut terhadap aturan.
Sebuah attestation membuktikan bahwa aturan telah diperiksa dan disetujui.
PolicyClient di dalam smart contract memverifikasi bukti sebelum eksekusi.
Begitulah Newton mengubah aturan dari janji yang bersifat “lunak” menjadi logika eksekusi.
Menurut saya, ini kedalaman proyek yang sesungguhnya. Newton bukan hanya menambahkan satu dasbor lagi ke DeFi. Newton menambahkan langkah keputusan sebelum settlement. Blockchain tetap menyelesaikan transaksi, tetapi Newton membantu memutuskan apakah transaksi boleh diizinkan sebelum settlement itu terjadi.
Ini penting karena blockchain sangat bagus untuk eksekusi, tetapi blockchain tidak otomatis memahami konteks dunia nyata.
Sebuah smart contract bisa mengetahui alamat pengirim, alamat penerima, nilai, dan calldata. Tetapi smart contract mungkin tidak tahu apakah pengirim berisiko, apakah tindakannya melanggar mandat vault, apakah oracle tidak sehat, apakah dompet sudah ditandai, apakah pengguna memenuhi syarat, atau apakah strategi otomatis melebihi batasnya.
Newton dibuat untuk lapisan yang hilang itu.
Ia membawa logika kebijakan dan data eksternal ke bentuk yang bisa digunakan smart contract dengan aman. Kontrak tidak perlu memahami setiap sumber data secara langsung. Kontrak hanya perlu memverifikasi apakah Newton menghasilkan attestation yang valid untuk transaksi yang persis tersebut.
Itu pemisahan yang jelas.
Sisi kebijakan menangani aturan.
Sisi eksekusi menangani transaksi.
Attestation menghubungkan keduanya.
Mari kita uraikan dengan benar.
Langkah pertama adalah Policy/Kebijakan.
Kebijakan adalah aturan yang menentukan apakah sebuah transaksi boleh diizinkan. Kebijakan bisa sederhana, seperti “jangan izinkan transfer ke alamat yang diblokir.” Kebijakan juga bisa lebih canggih, seperti “izinkan aksi vault ini hanya jika risiko pihak lawan dapat diterima, oracle sehat, APY berada dalam rentang, dan pengguna memenuhi aturan kelayakan.”
Ini penting karena aturan DeFi dunia nyata jarang berupa kondisi satu baris.
Sebuah vault mungkin memerlukan pemeriksaan risiko.
Sebuah treasury mungkin memerlukan batasan pengeluaran.
Sebuah aplikasi stablecoin mungkin memerlukan pemindaian sanksi.
Produk RWA mungkin memerlukan pemeriksaan identitas atau yurisdiksi.
Dompet otomatis mungkin memerlukan batas izin.
Tanpa Newton, para pembangun sering harus memilih di antara dua opsi yang lemah. Mereka sama ada meng-hardcode aturan sederhana ke dalam kontrak atau mereka menyimpan aturan kompleks di luar chain (offchain).
Aturan yang hardcoded bisa menjadi terlalu kaku. Aturan offchain bisa menjadi terlalu lemah.
Newton memberi jalan tengah. Kebijakan bisa memakai logika yang lebih kaya dan data di luar rantai, tetapi hasilnya tetap bisa diverifikasi onchain sebelum eksekusi.
Karena itulah lapisan kebijakan bukan sekadar fitur. Itu adalah fondasi dari seluruh sistem. Jika kebijakannya lemah, otorisasinya juga lemah. Jika kebijakannya kuat, jelas, dan terhubung ke data yang berguna, maka pengecekan transaksi menjadi jauh lebih bermakna.
Langkah kedua adalah Intent.
Sebuah maksud/intent adalah permintaan transaksi dalam bentuk yang terstruktur. Ia menyatakan apa yang ingin dilakukan pengguna atau sistem.
Dalam kata-kata sederhana, maksud menjawab:
Siapa yang memulai transaksi?
Ke mana transaksi akan dikirim?
Seberapa banyak nilai yang sedang dikirim?
Fungsi apa yang dipanggil?
Untuk chain mana ini ditujukan?
Kalldata persis apa yang disertakan?
Ini penting karena Newton tidak memeriksa gagasan yang samar. Newton memeriksa transaksi yang spesifik.
Itu sangat penting.
Jika seorang pengguna berkata, “Saya ingin menarik,” itu saja tidak cukup. Sistem perlu tahu jumlah penarikan yang persis, kontrak target, chain, pemanggilan fungsi, dan data transaksi. Tanpa itu, persetujuan akan terlalu luas.
Sistem otorisasi yang aman tidak boleh menyetujui maksud umum. Sistem itu harus menyetujui tindakan yang benar-benar spesifik.
Misalnya, jika seorang manajer vault ingin memindahkan dana, kebijakan tidak seharusnya hanya menyetujui “aktivitas vault”. Ia harus menyetujui sebuah aksi spesifik dengan detail spesifik. Jika manajer kemudian mengubah penerima, jumlah, atau pemanggilan fungsi, itu harus memerlukan pemeriksaan baru.
Ini melindungi sistem dari persetujuan yang terlalu longgar.
Intent juga membantu mencegah masalah lintas-chain atau replay karena ia menyertakan konteks chain. Transaksi yang ditujukan untuk satu chain tidak boleh dianggap valid di tempat lain.
Jadi maksud itu seperti formulir permintaan lengkap transaksi. Newton memakainya untuk memahami apa yang sedang diusulkan sebelum operator mengevaluasinya.
Langkah ketiga adalah Tugas.
Begitu maksud/intent siap, maksud itu menjadi sesuatu yang bisa dievaluasi oleh operator Newton. Gateway membuat sebuah tugas, dan tugas itu memberi tahu jaringan operator apa yang perlu diperiksa.
Tugas menghubungkan tiga hal:
Niat/intent transaksi.
Kebijakan yang harus diterapkan.
Data kebijakan yang dibutuhkan untuk evaluasi.
Di sinilah Newton mulai bertindak seperti jaringan otorisasi yang benar-benar nyata.
Operator mengambil kebijakan dan mengevaluasi apakah maksud memenuhi kebijakan tersebut. Mereka tidak hanya membaca status blockchain. Mereka juga bisa memakai sumber data kebijakan tergantung pada aturan. Ini dapat mencakup data kepatuhan, sinyal identitas, data risiko dompet, feed pasar, kesehatan oracle, konteks vault, atau informasi lain yang diperlukan oleh kebijakan.
Di sinilah Newton menjadi lebih kuat daripada pengecekan smart contract normal.
Kontrak normal mungkin tidak tahu apakah sebuah dompet berisiko. Ia mungkin tidak tahu apakah seorang pengguna lolos verifikasi. Ia mungkin tidak tahu apakah kondisi pasar di luar kontrak telah berubah. Alur tugas Newton membuat pengecekan-pengecekan itu terjadi di luar kontrak inti, sementara tetap memberi kontrak hasil yang dapat diverifikasi.
Itulah keseimbangannya.
Kontrak tetap cukup sederhana untuk dieksekusi dengan aman.
Mesin kebijakan menangani pengambilan keputusan yang lebih kaya.
Hasil akhir menjadi dapat digunakan di onchain.
Struktur ini sangat berguna untuk vault DeFi.
Bayangkan sebuah kebijakan vault mengatakan kurator hanya boleh memindahkan modal jika tujuan (destinasi) disetujui, data oracle sehat, dan paparan risiko tetap berada dalam mandat. Kurator membuat sebuah intent. Newton mengubahnya menjadi tugas. Operator mengevaluasinya. Jika aksi lolos, sistem menghasilkan bukti. Jika gagal, vault tidak boleh mengeksekusi aksi tersebut.
Jauh lebih baik daripada baru kemudian mengetahui bahwa kurator memindahkan modal di luar aturan yang disepakati.
Langkah keempat adalah Attestation.
Ini salah satu bagian paling penting dari Newton.
Sebuah attestation adalah bukti bahwa operator Newton mengevaluasi kebijakan dan menyetujui maksud. Ini bukan sekadar pesan yang bilang “diizinkan”. Ini adalah bukti kriptografis yang terhubung ke tugas tertentu, kebijakan, kontrak klien, masa berlaku, dan maksud.
Ini penting karena smart contract seharusnya tidak mempercayai persetujuan acak.
Jika sebuah kontrak akan mengizinkan sebuah transaksi karena Newton menyetujuinya, kontrak tersebut perlu cara untuk memverifikasi persetujuan itu. Kontrak perlu tahu bahwa persetujuan tersebut berasal dari proses yang benar, untuk kebijakan yang benar, untuk maksud yang benar, dan dalam jendela waktu yang benar.
Attestation memberikan struktur tersebut.
Ini dapat mencakup hal-hal seperti ID tugas, ID kebijakan, alamat klien kebijakan, blok kedaluwarsa (expiration block), maksud itu sendiri, dan tanda tangan pengguna atas maksud tersebut. Ini mencegah persetujuan digunakan secara longgar atau diterapkan untuk tindakan yang berbeda.
Itu penting.
Jika sebuah attestation menyetujui satu transaksi, ia tidak boleh menyetujui transaksi lain. Jika dibuat untuk satu chain, ia tidak boleh valid di chain lain. Jika sudah kedaluwarsa, ia tidak boleh lagi bekerja. Jika sudah pernah digunakan, ia tidak boleh dipakai ulang.
Begitulah otorisasi menjadi terkendali.
Dokumentasi Newton juga menjelaskan attestation BLS dalam produksi. Makna sederhananya adalah operator mengevaluasi tugas, menandatangani hasilnya, dan tanda tangan bisa diagregasi. Lalu smart contract dapat memverifikasi bukti itu dengan lebih efisien, alih-alih mengecek setiap operator satu per satu.
Ini penting untuk skalabilitas. Jika setiap pemeriksaan kebijakan memerlukan kerja onchain yang berat, itu akan menjadi mahal dan lambat. Bukti teragregasi membantu menjaga verifikasi di sisi kontrak tetap lebih bersih.
Langkah kelima adalah PolicyClient.
Di sinilah hasil akhirnya bertemu dengan smart contract.
PolicyClient adalah bagian penegakan di sisi kontrak. Itulah yang memungkinkan smart contract memvalidasi attestation Newton sebelum mengeksekusi aksi yang dilindungi.
Bagian ini penting karena kebijakan tidak berarti jika kontrak mengabaikannya.
Peringatan di frontend bisa dilewati.
Peringatan dasbor dapat diabaikan.
Aturan offchain bisa terlewat.
Namun, jika kontrak pintar memerlukan attestation yang valid, maka transaksi harus lulus kebijakan sebelum dieksekusi.
Karena itulah PolicyClient adalah titik penegakan yang sesungguhnya.
Sebuah kontrak yang menggunakan Newton dapat mewarisi atau mengintegrasikan NewtonPolicyClient. Sebelum kontrak mengeksekusi fungsi yang dilindungi, kontrak tersebut memeriksa attestation. Jika attestation valid, fungsi berlanjut. Jika attestation tidak valid, sudah kedaluwarsa, tidak cocok (mismatched), atau sudah digunakan, fungsi seharusnya gagal.
Di sinilah arsitektur Newton menjadi praktis.
Kontrak dapat memeriksa apakah ID kebijakan sesuai dengan kebijakan yang dikonfigurasi. Kontrak juga dapat memeriksa apakah pengirim maksud sama dengan pemanggil (caller). Ia bisa memeriksa apakah chain ID sudah benar. Ia dapat memeriksa apakah attestation telah kedaluwarsa. Ia bisa memeriksa apakah attestation tersebut sudah pernah digunakan. Ia dapat memeriksa apakah maksud yang disetujui cocok dengan aksi yang sedang dieksekusi.
Artinya persetujuan tersebut tidak bersifat abstrak.
Itu terikat pada jalur eksekusi yang persis.
Inilah yang membuat Newton berbeda dari persetujuan API yang sederhana.
Sebuah API terpusat biasa mungkin akan berkata ya atau tidak, tapi kontrak harus mempercayainya. Desain Newton lebih cocok untuk sistem onchain karena persetujuan menjadi sesuatu yang bisa diverifikasi oleh kontrak.
Bagi saya, ini cara paling kuat untuk menjelaskan Newton:
Ini tidak hanya membantu tim menulis aturan.
Ini membantu smart contract menegakkan aturan.
Itulah perbedaan antara kebijakan sebagai dokumentasi dan kebijakan sebagai infrastruktur.
Sekarang mari hubungkan seluruh alur dalam satu contoh.
Bayangkan sebuah dompet treasury ingin mengirim dana.
Tim punya aturan: tidak ada transfer di atas jumlah tertentu kecuali penerima telah disetujui dan dompet tidak berinteraksi dengan alamat yang ditandai.
Aturan itu menjadi kebijakan.
Seseorang membuat permintaan transaksi untuk mengirim dana. Permintaan itu menjadi maksud/intent. Permintaan tersebut mencakup pengirim, penerima, jumlah, chain, dan calldata.
Newton menerima maksud ini dan membuat sebuah tugas. Operator mengevaluasi maksud tersebut terhadap kebijakan. Mereka memeriksa apakah jumlahnya sesuai dengan aturan dan apakah penerima lolos pemeriksaan yang diperlukan.
Jika maksud lolos, operator menandatangani hasilnya. Tanda tangan tersebut menjadi sebuah attestation.
Kontrak treasury menggunakan PolicyClient untuk memvalidasi attestation. Jika valid, transfer dijalankan. Jika tidak valid, kontrak memblokir transaksi.
Itu adalah logika lengkapnya.
Kebijakan menentukan apa yang diizinkan.
Maksud/intent menggambarkan apa yang diminta.
Tugas mengirimkannya untuk dievaluasi.
Attestation membuktikan bahwa itu telah disetujui.
PolicyClient menegakkannya di onchain.
Ini sederhana, tetapi dampaknya besar.
Artinya aplikasi DeFi dapat beralih dari “kami punya aturan” menjadi “kontrak kami memerlukan bukti bahwa aturan telah diikuti.”
Itu peningkatannya.
Ini juga menjelaskan mengapa Newton memulai dari area seperti vault, kepatuhan, identitas, keamanan, dan risiko. Tepat di situlah aturan perlu lebih dari sekadar kata-kata.
Aturan vault tidak hanya boleh muncul di dokumen strategi.
Aturan kepatuhan tidak hanya boleh hidup di laporan offchain.
Aturan keamanan tidak hanya perlu dipicu setelah eksploit terjadi.
Aturan risiko tidak hanya boleh diperiksa setelah kerugian terjadi.
Jika aturan itu penting, aturan tersebut harus berada sebelum eksekusi.
Ini sangat relevan karena DeFi menjadi semakin otomatis.
Strategi otomatis dan dompet agen itu berguna, tetapi juga bisa menciptakan risiko baru. Jika sistem otomatis punya kebebasan yang terlalu besar, satu instruksi yang salah atau kondisi yang buruk bisa memindahkan dana ke arah yang keliru. Model yang lebih aman bukan memberi akses tak terbatas pada otomatisasi. Model yang lebih aman adalah memberi batas kebijakan yang jelas.
Newton cocok ke arah itu.
Dompet otomatis bisa diizinkan untuk bertindak, tetapi hanya dalam batas aturan. Ia bisa melakukan perdagangan, membayar, melakukan rebalancing, atau mengeksekusi tugas, namun ia tetap perlu persetujuan dari lapisan kebijakan sebelum tindakan sensitif terjadi.
Ini membuat otomatisasi lebih mudah digunakan karena mengurangi kepercayaan buta.
Hal yang sama berlaku untuk stablecoin dan RWA.
Stablecoin memerlukan aturan transfer dalam banyak kasus. RWA memerlukan pemeriksaan kelayakan dan kepatuhan. Institusi memerlukan jejak audit dan bukti bahwa aturan benar-benar ditegakkan. Sistem-sistem ini tidak hanya memerlukan settlement. Sistem-sistem ini membutuhkan settlement yang terkendali.
Alur Newton memberi mereka cara untuk menambahkan kontrol itu tanpa mengubah setiap smart contract menjadi mesin kepatuhan raksasa.
Karena itulah saya melihat Newton sebagai lapisan otorisasi, bukan sekadar alat DeFi.
Ia berada di antara maksud pengguna dan settlement onchain. Ia memeriksa aturan sebelum transaksi menjadi final. Ia memberi kontrak sebuah bukti yang bisa diverifikasi. Ia memungkinkan pembangun menambahkan kondisi yang lebih kaya tanpa bergantung hanya pada frontend atau peninjauan manual.
Inilah juga mengapa proyek ini bisa menjadi lebih penting jika policy packs menjadi bisa digunakan ulang. Jika pengembang dapat memakai kebijakan siap pakai untuk pemeriksaan sanksi, batas pengeluaran, risiko vault, identitas, keamanan dompet, kesehatan oracle, atau aturan pihak lawan, maka Newton menjadi lebih dari sekadar satu integrasi. Ia menjadi infrastruktur aturan yang dibagikan.
Itu efek jaringan yang kuat.
Semakin banyak kebijakan, semakin berguna Newton.
Semakin banyak integrasi, semakin berharga kebijakan.
Semakin banyak penyedia data meningkatkan kualitas kebijakan.
Semakin banyak operator meningkatkan kepercayaan pada evaluasi.
Semakin banyak kontrak yang memakai PolicyClient menciptakan permintaan penegakan yang nyata.
Di sinilah NEWT bisa punya cerita yang lebih dalam daripada sekadar perhatian pasar. Relevansi jangka panjang token bergantung pada apakah jaringan menjadi berguna untuk pekerjaan otorisasi dunia nyata. Jika Newton menjadi lapisan umum untuk pemeriksaan kebijakan, maka token terhubung ke sebuah sistem yang mengoordinasikan eksekusi kebijakan, partisipasi operator, dan tata kelola jaringan.
Bagian itu layak untuk diperhatikan.
Tentu saja, proyek ini tetap harus membuktikan adopsi. Arsitekturnya kuat, tetapi infrastruktur hanya berarti ketika pembangun menggunakannya dalam produk nyata. Uji sesungguhnya adalah apakah vault, dompet, aplikasi stablecoin, platform RWA, dan sistem otomatis benar-benar menjadikan Newton bagian dari alur eksekusi mereka.
Namun masalah yang sedang diselesaikan Newton adalah hal yang nyata.
DeFi sudah tahu cara memindahkan nilai. Yang masih dibutuhkan adalah kontrol yang lebih baik tentang kapan nilai diizinkan untuk bergerak.
Karena itu alur Policy → Intent → Task → Attestation → PolicyClient itu penting. Ini bukan hanya diagram teknis. Ini adalah jalur dari aturan menuju eksekusi.
Sebuah aturan dimulai sebagai kebijakan.
Sebuah transaksi menjadi maksud/intent.
Jaringan mengevaluasinya sebagai sebuah tugas.
Hasilnya menjadi sebuah attestation.
Kontrak menegakkannya melalui PolicyClient.
Begitulah Newton mengubah aturan menjadi logika eksekusi di onchain.
Dan karena itulah saya berpikir nilai asli Newton bukan hanya pada apa yang ditambahkannya ke DeFi saat ini. Nilai aslinya ada pada jenis DeFi yang dibuatnya menjadi mungkin di kemudian hari: vault dengan mandat yang dapat ditegakkan, dompet dengan kontrol pengeluaran yang nyata, sistem otomatis dengan batas izin, stablecoin dengan aturan transfer yang lebih kuat, serta produk onchain yang dapat membuktikan bahwa suatu transaksi diizinkan sebelum terselesaikan.
