EthanValeX
1.8k Posting
EthanValeX
Sharing market insights, real-world DCA & futures strategies.
No hype. No FOMO. Just discipline.
Follow me.
Pemilik U
Pedagang Rutin
5.9 Tahun
122 Mengikuti
506 Pengikut
1.5K+ Disukai
Posting
Semua
Kuotasi
Video
Lihat terjemahan
Last night, I was reading Grvt’s explanation of Validium when one uncomfortable detail made me stop.
User funds may be difficult to steal, yet they can still become unavailable.
At first, those two outcomes sounded contradictory.
Grvt uses zero-knowledge proofs to prove that a state transition is valid without publishing the full transaction data to Ethereum. The network can verify that balances and positions were updated according to the rules, while traders avoid exposing their entire activity on a public ledger.
For an exchange, that privacy has real value.
Public positions can reveal strategy, make large traders easier to track, and create opportunities for front-running or copy trading. Grvt’s private Validium reduces that information leakage without asking Ethereum to process every piece of trading data.
But the proof only answers one question:
Was the state transition valid?
It does not answer another:
Will the data behind that transition remain available when users need it?
Grvt’s operator keeps transaction data off-chain. Ethereum receives proof that the new state is correct, but it does not receive enough data to reconstruct the full trading history itself.
That creates a very specific boundary.
If the operator submits an invalid transition, the proof should fail. But if the operator stops serving data, the blockchain may still know that the latest state is valid while users lose the information needed to reconstruct their accounts or exit normally.
So Grvt does not ask users to trust the operator with the correctness of every trade.
It asks them to trust the operator with continued access to the history behind those trades.
That is the price hidden inside private execution: less information exposed to the market, but greater dependence on whoever preserves the missing data.
Can an exchange call itself self-custodial if users own the funds, but the operator still controls the data required to leave?
@grvt_io #grvt
User funds may be difficult to steal, yet they can still become unavailable.
At first, those two outcomes sounded contradictory.
Grvt uses zero-knowledge proofs to prove that a state transition is valid without publishing the full transaction data to Ethereum. The network can verify that balances and positions were updated according to the rules, while traders avoid exposing their entire activity on a public ledger.
For an exchange, that privacy has real value.
Public positions can reveal strategy, make large traders easier to track, and create opportunities for front-running or copy trading. Grvt’s private Validium reduces that information leakage without asking Ethereum to process every piece of trading data.
But the proof only answers one question:
Was the state transition valid?
It does not answer another:
Will the data behind that transition remain available when users need it?
Grvt’s operator keeps transaction data off-chain. Ethereum receives proof that the new state is correct, but it does not receive enough data to reconstruct the full trading history itself.
That creates a very specific boundary.
If the operator submits an invalid transition, the proof should fail. But if the operator stops serving data, the blockchain may still know that the latest state is valid while users lose the information needed to reconstruct their accounts or exit normally.
So Grvt does not ask users to trust the operator with the correctness of every trade.
It asks them to trust the operator with continued access to the history behind those trades.
That is the price hidden inside private execution: less information exposed to the market, but greater dependence on whoever preserves the missing data.
Can an exchange call itself self-custodial if users own the funds, but the operator still controls the data required to leave?
@grvt_io #grvt
Saya dulu mengira bagian yang paling menakutkan adalah melewatkan pemeriksaan validasi.
Dokumentasi Newton membuat saya berpikir bahwa kasus yang lebih menakutkan adalah ketika pemeriksaan itu ada, tetapi berada di tempat yang salah.
Satu baris di panduan Smart Contract Integration membuat saya berhenti:
Validasi sebelum eksekusi.
Awalnya, itu terdengar seperti kebersihan Solidity dasar.
Periksa dulu.
Kemudian jalankan logikanya.
Kedengarannya jelas.
Tapi dalam desain @NewtonProtocol , urutan mengubah segalanya.
Sebuah kontrak dapat memanggil _validateAttestation(). Ia bisa memeriksa maksud, kebijakan, kedaluwarsa, chainId, dan pemanggil. Di atas kertas, mungkin terlihat seperti aplikasi menggunakan Newton dengan benar.
Namun jika logika bisnis sudah berjalan sebelum validasi itu, kebijakan tidak lagi berdiri sebagai penjaga di gerbang.
Kebijakan berdiri setelah konsekuensinya.
Dana bisa saja sudah berpindah.
Sebuah vault mungkin sudah ditarik.
Sebuah token mungkin sudah dicetak.
Kontrak eksternal mungkin sudah dipanggil.
Pada titik itu, pemeriksaan Newton yang sama tidak lagi menghalangi eksekusi.
Ia hanya menggambarkan sesuatu yang mungkin sudah terjadi.
Itulah bagian yang terus saya pikirkan.
Pertanyaannya bukan hanya apakah sebuah kontrak memanggil Newton.
Pertanyaannya adalah di mana pemanggilan itu ditempatkan di dalam alur eksekusi.
Saya menyebutnya sebagai Disiplin Urutan Eksekusi.
Otorisasi tidak hanya perlu ada dalam alur. Ia perlu ditempatkan sebelum perubahan status yang berarti dimulai.
Jika validasi datang sebelum logika bisnis, kebijakan bertindak seperti gerbang.
Jika validasi datang setelah logika bisnis, kebijakan berubah menjadi bukti/nota.
Bagian tersulitnya adalah kontrak yang kompleks bisa mengaburkan “sebelum” dan “setelah.” Panggilan internal, panggilan eksternal, hook, callback, dan logika vault semuanya dapat menimbulkan konsekuensi lebih cepat dari yang diharapkan.
Jadi validasi tidak bisa sekadar muncul sebelum satu baris kode yang terlihat.
Validasi harus melindungi seluruh jalur eksekusi.
Mungkin otorisasi onchain tidak hanya soal menulis aturan yang lebih kuat.
Ini tentang memastikan tidak ada tindakan yang dimulai sebelum aturan-aturan itu diperiksa.
$NEWT $LAB #Newt
Dokumentasi Newton membuat saya berpikir bahwa kasus yang lebih menakutkan adalah ketika pemeriksaan itu ada, tetapi berada di tempat yang salah.
Satu baris di panduan Smart Contract Integration membuat saya berhenti:
Validasi sebelum eksekusi.
Awalnya, itu terdengar seperti kebersihan Solidity dasar.
Periksa dulu.
Kemudian jalankan logikanya.
Kedengarannya jelas.
Tapi dalam desain @NewtonProtocol , urutan mengubah segalanya.
Sebuah kontrak dapat memanggil _validateAttestation(). Ia bisa memeriksa maksud, kebijakan, kedaluwarsa, chainId, dan pemanggil. Di atas kertas, mungkin terlihat seperti aplikasi menggunakan Newton dengan benar.
Namun jika logika bisnis sudah berjalan sebelum validasi itu, kebijakan tidak lagi berdiri sebagai penjaga di gerbang.
Kebijakan berdiri setelah konsekuensinya.
Dana bisa saja sudah berpindah.
Sebuah vault mungkin sudah ditarik.
Sebuah token mungkin sudah dicetak.
Kontrak eksternal mungkin sudah dipanggil.
Pada titik itu, pemeriksaan Newton yang sama tidak lagi menghalangi eksekusi.
Ia hanya menggambarkan sesuatu yang mungkin sudah terjadi.
Itulah bagian yang terus saya pikirkan.
Pertanyaannya bukan hanya apakah sebuah kontrak memanggil Newton.
Pertanyaannya adalah di mana pemanggilan itu ditempatkan di dalam alur eksekusi.
Saya menyebutnya sebagai Disiplin Urutan Eksekusi.
Otorisasi tidak hanya perlu ada dalam alur. Ia perlu ditempatkan sebelum perubahan status yang berarti dimulai.
Jika validasi datang sebelum logika bisnis, kebijakan bertindak seperti gerbang.
Jika validasi datang setelah logika bisnis, kebijakan berubah menjadi bukti/nota.
Bagian tersulitnya adalah kontrak yang kompleks bisa mengaburkan “sebelum” dan “setelah.” Panggilan internal, panggilan eksternal, hook, callback, dan logika vault semuanya dapat menimbulkan konsekuensi lebih cepat dari yang diharapkan.
Jadi validasi tidak bisa sekadar muncul sebelum satu baris kode yang terlihat.
Validasi harus melindungi seluruh jalur eksekusi.
Mungkin otorisasi onchain tidak hanya soal menulis aturan yang lebih kuat.
Ini tentang memastikan tidak ada tindakan yang dimulai sebelum aturan-aturan itu diperiksa.
$NEWT $LAB #Newt
Kepatuhan lintas-rantai hancur begitu “verified” berubah menjadi “katanya dari seseorang.”
Itu masalah yang menurut saya sedang coba dipersempit oleh @NewtonProtocol .
Di atas kertas, memindahkan otorisasi antar-rantai terdengar sederhana.
Satu rantai memeriksa kebijakannya.
Rantai lain menerima hasilnya.
Transaksinya berlanjut.
Tapi penyelesaian tidak seharusnya bekerja seperti kiriman tangkapan layar yang diteruskan.
Jika nilai bergerak di rantai tujuan, rantai itu tidak hanya seharusnya menerima pesan bahwa kebijakannya lolos. Rantai itu harus bisa memverifikasi persetujuannya sendiri di rantai sebelum eksekusi.
Di sinilah jalur sertifikat Newton untuk BN254 menjadi lebih menarik daripada namanya.
Intinya bukan nama kurvanya.
Intinya adalah persetujuan lintas-rantai perlu membawa bentuk yang bisa diperiksa oleh verifikator tujuan di onchain: tanda tangan teragregasi, snapshot operator, dan titik referensi dari rantai sumber.
Tanpa konteks itu, sebuah bukti bisa berpindah antar-rantai sambil kehilangan alasan mengapa ia dipercaya sejak awal.
Itu mengubah wawasan bagi saya.
Kepatuhan lintas-rantai bukan hanya tentang mengirim aturan antar jaringan.
Ini tentang memastikan bahwa rantai tempat penyelesaian terjadi masih memiliki hak yang tepat untuk berkata tidak.
Batas itu penting saat stablecoin, RWA, posisi vault, dan transaksi agen menjadi makin multichain. Pemeriksaan kebijakan pada satu rantai tidak boleh menjadi lebih lemah hanya karena asetnya muncul di tempat lain.
Komprominya adalah kompleksitas.
Keadaan verifikator perlu tetap segar. Snapshot operator harus tetap bermakna. Sertifikat perlu diperiksa sebelum eksekusi, bukan dianggap seperti dokumen administrasi setelah kejadian.
Tapi tanpa itu, kepatuhan lintas-rantai berubah menjadi jembatan kepercayaan, bukan lapisan verifikasi.
Apakah Newton membuat otorisasi lintas-rantai bisa dibawa tanpa mengubah rantai tujuan menjadi penerima buta?
#Newt $NEWT $LAB
Itu masalah yang menurut saya sedang coba dipersempit oleh @NewtonProtocol .
Di atas kertas, memindahkan otorisasi antar-rantai terdengar sederhana.
Satu rantai memeriksa kebijakannya.
Rantai lain menerima hasilnya.
Transaksinya berlanjut.
Tapi penyelesaian tidak seharusnya bekerja seperti kiriman tangkapan layar yang diteruskan.
Jika nilai bergerak di rantai tujuan, rantai itu tidak hanya seharusnya menerima pesan bahwa kebijakannya lolos. Rantai itu harus bisa memverifikasi persetujuannya sendiri di rantai sebelum eksekusi.
Di sinilah jalur sertifikat Newton untuk BN254 menjadi lebih menarik daripada namanya.
Intinya bukan nama kurvanya.
Intinya adalah persetujuan lintas-rantai perlu membawa bentuk yang bisa diperiksa oleh verifikator tujuan di onchain: tanda tangan teragregasi, snapshot operator, dan titik referensi dari rantai sumber.
Tanpa konteks itu, sebuah bukti bisa berpindah antar-rantai sambil kehilangan alasan mengapa ia dipercaya sejak awal.
Itu mengubah wawasan bagi saya.
Kepatuhan lintas-rantai bukan hanya tentang mengirim aturan antar jaringan.
Ini tentang memastikan bahwa rantai tempat penyelesaian terjadi masih memiliki hak yang tepat untuk berkata tidak.
Batas itu penting saat stablecoin, RWA, posisi vault, dan transaksi agen menjadi makin multichain. Pemeriksaan kebijakan pada satu rantai tidak boleh menjadi lebih lemah hanya karena asetnya muncul di tempat lain.
Komprominya adalah kompleksitas.
Keadaan verifikator perlu tetap segar. Snapshot operator harus tetap bermakna. Sertifikat perlu diperiksa sebelum eksekusi, bukan dianggap seperti dokumen administrasi setelah kejadian.
Tapi tanpa itu, kepatuhan lintas-rantai berubah menjadi jembatan kepercayaan, bukan lapisan verifikasi.
Apakah Newton membuat otorisasi lintas-rantai bisa dibawa tanpa mengubah rantai tujuan menjadi penerima buta?
#Newt $NEWT $LAB
Saya terus kembali ke satu detail kecil dalam desain Newton’s Data Oracle.
Berkas skemanya.
Awalnya, wasm_args_schema.json dan params_schema.json terlihat seperti dokumentasi pengembang. Cara untuk memberi tahu pemanggil field apa yang harus dikirim, tipe apa yang digunakan, dan bagaimana menghindari permintaan yang tidak valid.
Bermanfaat, tapi tidak terlalu dalam.
Namun semakin saya melihatnya, semakin saya menyadari bahwa skema sedang melakukan sesuatu yang lebih penting di dalam @NewtonProtocol .
Skema mendefinisikan bentuk dunia yang diperbolehkan untuk dipertimbangkan oleh sebuah kebijakan.
Kebijakan Rego tidak mengevaluasi realitas secara langsung. Ia mengevaluasi data terstruktur. Data Oracle menerima wasm_args, memproses konteks eksternal, lalu mengembalikan JSON ke data.wasm. Konfigurasi PolicyClient tampak sebagai data.params.
Jika bentuk-bentuk itu longgar, kebijakan mungkin tetap benar sebagai kode, tetapi rapuh sebagai alat penegakan.
Jika sebuah oracle mengharapkan vaultAddress tetapi menerima vault_address, kebijakan mungkin masih bisa berjalan. Tapi ia tidak lagi melakukan penalaran atas objek yang dimaksudkan oleh pembuatnya.
Di situlah Schema Discipline menjadi penting.
Newton tidak hanya meminta para builder menulis aturan. Newton meminta mereka mendeklarasikan kontrak data yang bergantung pada aturan-aturan itu sebelum evaluasi dimulai.
Itu mengubah batas tanggung jawab.
Pemanggil tidak bisa begitu saja mengirim sembarang blob input yang nyaman. Oracle tidak dapat diam-diam mengasumsikan field ada dalam bentuk apa pun yang ia sukai. Kebijakan tidak dapat berpura-pura bahwa logikanya independen dari bentuk data yang memberinya masukan.
Skema menjadi kesepakatan antara pemanggil, oracle, dan kebijakan.
Skema tidak memutuskan apakah transaksi harus diotorisasi. Tapi skema menentukan apakah sistem bahkan sedang melihat jenis objek yang tepat sebelum otorisasi dimulai.
Meski begitu, skema punya batas.
Ia bisa memvalidasi struktur, tetapi bukan kebenaran. Sebuah field bisa terbentuk dengan benar dan tetap menjadi data yang basi, dimanipulasi, atau menyesatkan secara ekonomi.
Bagian itulah yang terus saya pikirkan.
Di Newton, keselamatan kebijakan tidak dimulai dari aturan.
Ia dimulai dari bentuk data yang diizinkan untuk dipercaya oleh aturan.
$NEWT $LAB #Newt
Berkas skemanya.
Awalnya, wasm_args_schema.json dan params_schema.json terlihat seperti dokumentasi pengembang. Cara untuk memberi tahu pemanggil field apa yang harus dikirim, tipe apa yang digunakan, dan bagaimana menghindari permintaan yang tidak valid.
Bermanfaat, tapi tidak terlalu dalam.
Namun semakin saya melihatnya, semakin saya menyadari bahwa skema sedang melakukan sesuatu yang lebih penting di dalam @NewtonProtocol .
Skema mendefinisikan bentuk dunia yang diperbolehkan untuk dipertimbangkan oleh sebuah kebijakan.
Kebijakan Rego tidak mengevaluasi realitas secara langsung. Ia mengevaluasi data terstruktur. Data Oracle menerima wasm_args, memproses konteks eksternal, lalu mengembalikan JSON ke data.wasm. Konfigurasi PolicyClient tampak sebagai data.params.
Jika bentuk-bentuk itu longgar, kebijakan mungkin tetap benar sebagai kode, tetapi rapuh sebagai alat penegakan.
Jika sebuah oracle mengharapkan vaultAddress tetapi menerima vault_address, kebijakan mungkin masih bisa berjalan. Tapi ia tidak lagi melakukan penalaran atas objek yang dimaksudkan oleh pembuatnya.
Di situlah Schema Discipline menjadi penting.
Newton tidak hanya meminta para builder menulis aturan. Newton meminta mereka mendeklarasikan kontrak data yang bergantung pada aturan-aturan itu sebelum evaluasi dimulai.
Itu mengubah batas tanggung jawab.
Pemanggil tidak bisa begitu saja mengirim sembarang blob input yang nyaman. Oracle tidak dapat diam-diam mengasumsikan field ada dalam bentuk apa pun yang ia sukai. Kebijakan tidak dapat berpura-pura bahwa logikanya independen dari bentuk data yang memberinya masukan.
Skema menjadi kesepakatan antara pemanggil, oracle, dan kebijakan.
Skema tidak memutuskan apakah transaksi harus diotorisasi. Tapi skema menentukan apakah sistem bahkan sedang melihat jenis objek yang tepat sebelum otorisasi dimulai.
Meski begitu, skema punya batas.
Ia bisa memvalidasi struktur, tetapi bukan kebenaran. Sebuah field bisa terbentuk dengan benar dan tetap menjadi data yang basi, dimanipulasi, atau menyesatkan secara ekonomi.
Bagian itulah yang terus saya pikirkan.
Di Newton, keselamatan kebijakan tidak dimulai dari aturan.
Ia dimulai dari bentuk data yang diizinkan untuk dipercaya oleh aturan.
$NEWT $LAB #Newt
Detail yang membuat saya berpikir ulang tentang model otorisasi Newton bukanlah tanda tangan itu sendiri.
Melainkan batas ini:
intent.from == msg.sender
Awalnya, ini terlihat seperti pemeriksaan kontrak pintar yang sederhana.
Tentu, pemanggil harus cocok dengan alamat di dalam intent. Tidak ada yang mengejutkan di sana.
Namun semakin saya memikirkannya, semakin pemeriksaan kecil itu mulai terasa seperti pusat masalah replay.
Tanda tangan hanya membuktikan bahwa seseorang telah menyetujui sesuatu pada suatu waktu.
Itu tidak otomatis membuktikan bahwa persetujuan tersebut kembali melalui pemanggil yang tepat, pada rantai yang tepat, di bawah kebijakan yang tepat, sebelum kedaluwarsa, dan sebelum persetujuan itu sudah digunakan.
Di situlah batas validasi @NewtonProtocol menjadi penting.
Newton tidak memperlakukan otorisasi sebagai izin longgar yang dapat mengambang setelah ditandatangani. Intent membawa konteks: sender, kontrak target, calldata, value, chainId, dan tanda tangan fungsi. Kontrak kemudian memvalidasi bahwa otorisasi tersebut masih terikat pada jalur eksekusi yang untuknya ia diciptakan.
Itu mengubah cara saya memandang perlindungan replay.
Tujuannya bukan hanya menanyakan apakah persetujuan itu pernah ada.
Tujuannya adalah mempersempit masa hidup persetujuan tersebut.
Persetujuan itu tidak bisa lepas dari pemanggil. Tidak bisa berpindah ke rantai lain. Tidak bisa bertahan di luar konteks kebijakan yang menghasilkannya. Tidak bisa melewati jendela kedaluwarsanya. Tidak bisa digunakan dua kali.
Tanda tangan tetap penting, tetapi batas di sekitar tanda tangan sama pentingnya.
Kedengarannya seperti detail implementasi yang kecil, tetapi sebenarnya itu adalah pilihan desain yang lebih dalam. Newton membuat otorisasi bersifat kontekstual, bukan mudah dibawa secara default.
Tanda tangan bukan izin selamanya.
Tanda tangan adalah izin di dalam batas tertentu.
Dan mungkin bagian onchain automation yang paling dibutuhkan adalah ini: bukan hanya persetujuan yang lebih kuat, tetapi persetujuan yang tidak bisa berpindah dari konteks yang menciptakannya.
Apakah perlindungan replay membuat otorisasi lebih aman, atau apakah ia mengingatkan kita bahwa setiap persetujuan yang bisa digunakan ulang sebenarnya sudah menjadi permukaan risiko?
#Newt $NEWT $LAB
Melainkan batas ini:
intent.from == msg.sender
Awalnya, ini terlihat seperti pemeriksaan kontrak pintar yang sederhana.
Tentu, pemanggil harus cocok dengan alamat di dalam intent. Tidak ada yang mengejutkan di sana.
Namun semakin saya memikirkannya, semakin pemeriksaan kecil itu mulai terasa seperti pusat masalah replay.
Tanda tangan hanya membuktikan bahwa seseorang telah menyetujui sesuatu pada suatu waktu.
Itu tidak otomatis membuktikan bahwa persetujuan tersebut kembali melalui pemanggil yang tepat, pada rantai yang tepat, di bawah kebijakan yang tepat, sebelum kedaluwarsa, dan sebelum persetujuan itu sudah digunakan.
Di situlah batas validasi @NewtonProtocol menjadi penting.
Newton tidak memperlakukan otorisasi sebagai izin longgar yang dapat mengambang setelah ditandatangani. Intent membawa konteks: sender, kontrak target, calldata, value, chainId, dan tanda tangan fungsi. Kontrak kemudian memvalidasi bahwa otorisasi tersebut masih terikat pada jalur eksekusi yang untuknya ia diciptakan.
Itu mengubah cara saya memandang perlindungan replay.
Tujuannya bukan hanya menanyakan apakah persetujuan itu pernah ada.
Tujuannya adalah mempersempit masa hidup persetujuan tersebut.
Persetujuan itu tidak bisa lepas dari pemanggil. Tidak bisa berpindah ke rantai lain. Tidak bisa bertahan di luar konteks kebijakan yang menghasilkannya. Tidak bisa melewati jendela kedaluwarsanya. Tidak bisa digunakan dua kali.
Tanda tangan tetap penting, tetapi batas di sekitar tanda tangan sama pentingnya.
Kedengarannya seperti detail implementasi yang kecil, tetapi sebenarnya itu adalah pilihan desain yang lebih dalam. Newton membuat otorisasi bersifat kontekstual, bukan mudah dibawa secara default.
Tanda tangan bukan izin selamanya.
Tanda tangan adalah izin di dalam batas tertentu.
Dan mungkin bagian onchain automation yang paling dibutuhkan adalah ini: bukan hanya persetujuan yang lebih kuat, tetapi persetujuan yang tidak bisa berpindah dari konteks yang menciptakannya.
Apakah perlindungan replay membuat otorisasi lebih aman, atau apakah ia mengingatkan kita bahwa setiap persetujuan yang bisa digunakan ulang sebenarnya sudah menjadi permukaan risiko?
#Newt $NEWT $LAB
Token RWA dapat terlihat seperti koin meme di jaringan.
Itu persis yang mengganggu saya.
Sebuah dompet melihat saldo.
Sebuah kontrak mengekspos transfer().
Sebuah penjelajah blok menampilkan aset ERC-20.
Tapi saya tidak berpikir RWA bisa meminjam asumsi koin meme bahwa transfer harus terbuka secara default.
Dalam aset dunia nyata, kepemilikan hanyalah satu bagian dari cerita. Bagian yang lebih sulit adalah apakah pemegangnya masih berhak untuk mentransfer saat transaksi terjadi.
Kondisi itu dapat berubah.
Sertifikat kredensial bisa kedaluwarsa. Suatu yurisdiksi bisa menjadi dibatasi. Sebuah dana dapat memperbarui aturan investor. Pihak lawan dapat menjadi tidak memenuhi syarat. Token itu masih bisa tampak dapat dipindahkan, sementara izin di baliknya sudah basi.
Di situlah kepatuhan frontend terasa lemah bagi saya.
Frontend dapat menyembunyikan tombol transfer. Tapi jika kontraknya masih menerima transfer(), pembatasannya hanya bersifat kosmetik. Pengguna dapat mengarahkan melalui antarmuka lain atau memanggil kontrak secara langsung.
Itu bukan penegakan.
Itu adalah asumsi UI.
Inilah mengapa <0>@NewtonProtocol </0> lebih cocok dengan masalah RWA dibanding dasbor kepatuhan biasa.
Sudut pandang penting Newton bukan bahwa kebijakan dapat mendeskripsikan pembatasan. Melainkan bahwa evaluasi kebijakan dapat berada di dalam jalur otorisasi sebelum aset bergerak. Kebijakan menjadi sesuatu yang dapat diandalkan oleh kontrak pintar.
Sebelum eksekusi, konteks kebijakan yang berlaku dapat memeriksa kelayakan, status kredensial, yurisdiksi, batas transfer, atau risiko pihak lawan.
Yang menonjol bagi saya adalah masalah kelayakan yang sudah basi.
Jika perubahan aturan tidak diperiksa dekat dengan eksekusi, sebuah RWA bisa terlihat patuh sementara jalur transfer yang sebenarnya tetap terbuka.
Bagian yang belum sepenuhnya saya putuskan adalah komprominya.
Apakah otorisasi tingkat transaksi membuat RWA lebih aman, atau justru mengubah aset ter-tokenisasi menjadi produk teregulasi yang mengenakan pakaian ERC-20?
#Newt $LAB $NEWT
Itu persis yang mengganggu saya.
Sebuah dompet melihat saldo.
Sebuah kontrak mengekspos transfer().
Sebuah penjelajah blok menampilkan aset ERC-20.
Tapi saya tidak berpikir RWA bisa meminjam asumsi koin meme bahwa transfer harus terbuka secara default.
Dalam aset dunia nyata, kepemilikan hanyalah satu bagian dari cerita. Bagian yang lebih sulit adalah apakah pemegangnya masih berhak untuk mentransfer saat transaksi terjadi.
Kondisi itu dapat berubah.
Sertifikat kredensial bisa kedaluwarsa. Suatu yurisdiksi bisa menjadi dibatasi. Sebuah dana dapat memperbarui aturan investor. Pihak lawan dapat menjadi tidak memenuhi syarat. Token itu masih bisa tampak dapat dipindahkan, sementara izin di baliknya sudah basi.
Di situlah kepatuhan frontend terasa lemah bagi saya.
Frontend dapat menyembunyikan tombol transfer. Tapi jika kontraknya masih menerima transfer(), pembatasannya hanya bersifat kosmetik. Pengguna dapat mengarahkan melalui antarmuka lain atau memanggil kontrak secara langsung.
Itu bukan penegakan.
Itu adalah asumsi UI.
Inilah mengapa <0>@NewtonProtocol </0> lebih cocok dengan masalah RWA dibanding dasbor kepatuhan biasa.
Sudut pandang penting Newton bukan bahwa kebijakan dapat mendeskripsikan pembatasan. Melainkan bahwa evaluasi kebijakan dapat berada di dalam jalur otorisasi sebelum aset bergerak. Kebijakan menjadi sesuatu yang dapat diandalkan oleh kontrak pintar.
Sebelum eksekusi, konteks kebijakan yang berlaku dapat memeriksa kelayakan, status kredensial, yurisdiksi, batas transfer, atau risiko pihak lawan.
Yang menonjol bagi saya adalah masalah kelayakan yang sudah basi.
Jika perubahan aturan tidak diperiksa dekat dengan eksekusi, sebuah RWA bisa terlihat patuh sementara jalur transfer yang sebenarnya tetap terbuka.
Bagian yang belum sepenuhnya saya putuskan adalah komprominya.
Apakah otorisasi tingkat transaksi membuat RWA lebih aman, atau justru mengubah aset ter-tokenisasi menjadi produk teregulasi yang mengenakan pakaian ERC-20?
#Newt $LAB $NEWT
Meluangkan waktu untuk memikirkan stablecoin sebagai uang lintas negara, dan satu pertanyaan terus kembali kepada saya.
Bisakah token yang sama mengikuti aturan yang berbeda tanpa merusak pengalaman pembayaran?
Di blockchain, transfer stablecoin terlihat sederhana.
Aset yang sama.
Kontrak yang sama.
Logika penyelesaian yang sama.
Tapi di dunia nyata, sebuah pembayaran jarang sekali hanya sekadar pembayaran. Pengirim bisa berada di satu yurisdiksi, penerima di yurisdiksi lain, jumlahnya mungkin melewati ambang pelaporan, dan koridor itu sendiri bisa membawa ekspektasi kepatuhan yang berbeda.
Di sinilah @NewtonProtocol menjadi menarik bagi saya.
Newton’s Mainnet Beta angle bukan hanya soal memeriksa dompet secara teoritis. Ini menempatkan evaluasi kebijakan sebelum penyelesaian, sehingga aturan dapat menjadi bagian dari jalur pembayaran yang sebenarnya, bukan sekadar laporan setelah uang sudah berpindah.
Itu mengubah desainnya.
Sebuah jaringan pembayaran tidak harus memperlakukan setiap transfer stablecoin sebagai identik secara hukum. Jaringan itu dapat menerapkan logika kebijakan yang berbeda tergantung pada konteks pengirim, konteks penerima, jumlah, koridor, kelayakan, atau tingkat paparan risiko.
Pada awalnya, itu terdengar seperti hambatan tambahan.
Tapi mungkin adopsi stablecoin lintas batas perlu lapisan seperti ini jika ingin melampaui pengguna yang lahir dari ekosistem kripto. Jalur pembayaran yang sudah ada sebelumnya memang bekerja di dalam logika yurisdiksional. Bedanya, Newton mencoba membuat aturan-aturan itu dapat diprogram dan ditegakkan pada tingkat transaksi.
Namun, komprominya nyata.
Jika aturannya terlalu longgar, jaringan pembayaran yang teregulasi mungkin tidak mempercayai sistem. Jika aturannya terlalu ketat, stablecoin bisa kehilangan rasa uang global terbuka yang membuatnya kuat sejak awal.
Itu bagian yang belum sepenuhnya saya putuskan.
Apakah otorisasi berbasis yurisdiksi membuat pembayaran stablecoin lebih mudah digunakan untuk dunia nyata, atau apakah perlahan-lahan mengubah uang terbuka menjadi perbatasan yang bisa diprogram?
#Newt $NEWT $LAB
Bisakah token yang sama mengikuti aturan yang berbeda tanpa merusak pengalaman pembayaran?
Di blockchain, transfer stablecoin terlihat sederhana.
Aset yang sama.
Kontrak yang sama.
Logika penyelesaian yang sama.
Tapi di dunia nyata, sebuah pembayaran jarang sekali hanya sekadar pembayaran. Pengirim bisa berada di satu yurisdiksi, penerima di yurisdiksi lain, jumlahnya mungkin melewati ambang pelaporan, dan koridor itu sendiri bisa membawa ekspektasi kepatuhan yang berbeda.
Di sinilah @NewtonProtocol menjadi menarik bagi saya.
Newton’s Mainnet Beta angle bukan hanya soal memeriksa dompet secara teoritis. Ini menempatkan evaluasi kebijakan sebelum penyelesaian, sehingga aturan dapat menjadi bagian dari jalur pembayaran yang sebenarnya, bukan sekadar laporan setelah uang sudah berpindah.
Itu mengubah desainnya.
Sebuah jaringan pembayaran tidak harus memperlakukan setiap transfer stablecoin sebagai identik secara hukum. Jaringan itu dapat menerapkan logika kebijakan yang berbeda tergantung pada konteks pengirim, konteks penerima, jumlah, koridor, kelayakan, atau tingkat paparan risiko.
Pada awalnya, itu terdengar seperti hambatan tambahan.
Tapi mungkin adopsi stablecoin lintas batas perlu lapisan seperti ini jika ingin melampaui pengguna yang lahir dari ekosistem kripto. Jalur pembayaran yang sudah ada sebelumnya memang bekerja di dalam logika yurisdiksional. Bedanya, Newton mencoba membuat aturan-aturan itu dapat diprogram dan ditegakkan pada tingkat transaksi.
Namun, komprominya nyata.
Jika aturannya terlalu longgar, jaringan pembayaran yang teregulasi mungkin tidak mempercayai sistem. Jika aturannya terlalu ketat, stablecoin bisa kehilangan rasa uang global terbuka yang membuatnya kuat sejak awal.
Itu bagian yang belum sepenuhnya saya putuskan.
Apakah otorisasi berbasis yurisdiksi membuat pembayaran stablecoin lebih mudah digunakan untuk dunia nyata, atau apakah perlahan-lahan mengubah uang terbuka menjadi perbatasan yang bisa diprogram?
#Newt $NEWT $LAB
Terverifikasi
Saya terus memikirkan satu bagian yang tidak nyaman dari keuangan lintas-rantai:
Bridge tidak hanya memindahkan aset.
Mereka juga memindahkan risiko.
Kebanyakan orang membahas lintas-rantai seolah-olah satu-satunya masalah adalah kecepatan, biaya, dan likuiditas. Bisakah aset bergerak lebih cepat? Bisakah pengguna menghindari rute yang mahal? Bisakah DeFi terasa lebih mulus di seluruh jaringan?
Pertanyaan-pertanyaan itu penting.
Namun ada masalah yang lebih senyap di bawahnya.
Ketika sebuah aset berpindah dari satu chain ke chain lain, aturan yang melindunginya tidak selalu ikut bergerak dengan kekuatan yang sama.
Satu chain mungkin memiliki pemeriksaan kebijakan yang ketat. Chain lain mungkin bergantung pada kontrol tingkat aplikasi. Yang lain mungkin hanya mendeteksi aktivitas mencurigakan setelah transaksi itu sudah terjadi.
Itu menciptakan kelemahan yang aneh.
Risiko tidak perlu merusak bagian terkuat dari sistem. Risiko hanya perlu menemukan jalur terlemah.
Di sinilah @NewtonProtocol menjadi menarik bagi saya.
Newton Mainnet Beta bukan sekadar menambahkan lapisan lain ke DeFi. Ini tentang otorisasi sebelum settlement. Niat transaksi bisa diperiksa terhadap kebijakan yang aktif terlebih dahulu, lalu menerima bukti otorisasi tanda tangan lulus/gagal sebelum eksekusi.
Perbedaan itu penting.
Monitoring memberi tahu Anda apa yang salah setelah uang berpindah.
Otorisasi bertanya apakah uang memang harus berpindah sejak awal.
Tantangan sesungguhnya adalah apakah aplikasi akan menerima infrastruktur kebijakan bersama, alih-alih setiap pihak membangun kontrol yang terisolasi. Kripto menyukai komposabilitas, tetapi setiap tim masih ingin mengendalikan batasnya sendiri.
Itulah yang masih harus dibuktikan Newton.
Namun jika aset menjadi lintas-rantai secara default, kebijakan tidak bisa tetap terkurung di dalam satu chain.
Karena risiko masa depan bukan hanya transaksi yang buruk.
Risiko masa depan adalah transaksi-transaksi buruk yang menemukan chain paling mudah untuk bersembunyi.
$LAB $NEWT #Newt
Bridge tidak hanya memindahkan aset.
Mereka juga memindahkan risiko.
Kebanyakan orang membahas lintas-rantai seolah-olah satu-satunya masalah adalah kecepatan, biaya, dan likuiditas. Bisakah aset bergerak lebih cepat? Bisakah pengguna menghindari rute yang mahal? Bisakah DeFi terasa lebih mulus di seluruh jaringan?
Pertanyaan-pertanyaan itu penting.
Namun ada masalah yang lebih senyap di bawahnya.
Ketika sebuah aset berpindah dari satu chain ke chain lain, aturan yang melindunginya tidak selalu ikut bergerak dengan kekuatan yang sama.
Satu chain mungkin memiliki pemeriksaan kebijakan yang ketat. Chain lain mungkin bergantung pada kontrol tingkat aplikasi. Yang lain mungkin hanya mendeteksi aktivitas mencurigakan setelah transaksi itu sudah terjadi.
Itu menciptakan kelemahan yang aneh.
Risiko tidak perlu merusak bagian terkuat dari sistem. Risiko hanya perlu menemukan jalur terlemah.
Di sinilah @NewtonProtocol menjadi menarik bagi saya.
Newton Mainnet Beta bukan sekadar menambahkan lapisan lain ke DeFi. Ini tentang otorisasi sebelum settlement. Niat transaksi bisa diperiksa terhadap kebijakan yang aktif terlebih dahulu, lalu menerima bukti otorisasi tanda tangan lulus/gagal sebelum eksekusi.
Perbedaan itu penting.
Monitoring memberi tahu Anda apa yang salah setelah uang berpindah.
Otorisasi bertanya apakah uang memang harus berpindah sejak awal.
Tantangan sesungguhnya adalah apakah aplikasi akan menerima infrastruktur kebijakan bersama, alih-alih setiap pihak membangun kontrol yang terisolasi. Kripto menyukai komposabilitas, tetapi setiap tim masih ingin mengendalikan batasnya sendiri.
Itulah yang masih harus dibuktikan Newton.
Namun jika aset menjadi lintas-rantai secara default, kebijakan tidak bisa tetap terkurung di dalam satu chain.
Karena risiko masa depan bukan hanya transaksi yang buruk.
Risiko masa depan adalah transaksi-transaksi buruk yang menemukan chain paling mudah untuk bersembunyi.
$LAB $NEWT #Newt
Terverifikasi
Orang zaman dulu punya pepatah “kuasa raja kalah oleh aturan kampung.”
Saya pikir DeFi juga begitu.
Smart contract seperti bagian hukum yang ditulis secara terbuka: semua orang bisa melihat, semua orang bisa memeriksa. Tapi setiap aplikasi punya lapisan kondisi sendiri. Slot mana yang dipakai, batas maksimum berapa, wilayah mana yang diizinkan, jika oracle error harus diproses bagaimana, sampai risk score sejauh mana transaksi sebaiknya diblokir.
Masalahnya, kondisi-kondisi itu biasanya tersebar. Sebagian ada di frontend. Sebagian di backend. Sebagian dalam konfigurasi admin. Sebagian lagi disisipkan langsung ke dalam contract. Semakin banyak tambal-lapisan seperti itu, sistem makin sulit diaudit dan makin sulit dijelaskan ketika transaksi ditolak.
Di sinilah saya melihat @NewtonProtocol menarik perhatian.
Newton menggunakan Rego/OPA untuk mengubah kondisi-kondisi tersebut menjadi satu lapisan policy tersendiri, yang dicek sebelum settlement. Transaksi masuk lebih dulu, operator network memeriksa policy, lalu mengembalikan signed pass/fail attestation, dan barulah smart contract memutuskan apakah transaksi boleh dijalankan atau tidak.
Seperti sebuah mobil menuruni tanjakan—mesin yang bekerja dengan baik belum cukup. Ia juga perlu rem yang tahu kapan harus bekerja dengan tepat. Vault DeFi juga demikian: contract bisa berjalan dengan benar, tapi jika kesehatan oracle buruk, leverage melewati ambang, atau dompet tidak memenuhi syarat, sistem perlu tahu kapan waktunya menghentikan dana.
Saya menyebut ini Stop Logic.
Lapisan logika ini membantu smart contract tidak hanya tahu cara menjalankan, tapi juga tahu kapan harus berhenti.
Namun arah ini juga punya jebakan. Ketika hak untuk menolak transaksi ada di policy, pertanyaannya bukan hanya apakah contract sudah diaudit. Melainkan: siapa yang menulis policy, siapa yang memperbaruinya, dan apakah user paham alasan mengapa mereka diblokir.
Smart contract terbaik adalah yang mampu mengeksekusi.
Tapi DeFi yang matang tidak hanya butuh sesuatu yang tahu cara berjalan.
Ia butuh sesuatu yang tahu cara berhenti.
$NEWT $LAB #Newt
Saya pikir DeFi juga begitu.
Smart contract seperti bagian hukum yang ditulis secara terbuka: semua orang bisa melihat, semua orang bisa memeriksa. Tapi setiap aplikasi punya lapisan kondisi sendiri. Slot mana yang dipakai, batas maksimum berapa, wilayah mana yang diizinkan, jika oracle error harus diproses bagaimana, sampai risk score sejauh mana transaksi sebaiknya diblokir.
Masalahnya, kondisi-kondisi itu biasanya tersebar. Sebagian ada di frontend. Sebagian di backend. Sebagian dalam konfigurasi admin. Sebagian lagi disisipkan langsung ke dalam contract. Semakin banyak tambal-lapisan seperti itu, sistem makin sulit diaudit dan makin sulit dijelaskan ketika transaksi ditolak.
Di sinilah saya melihat @NewtonProtocol menarik perhatian.
Newton menggunakan Rego/OPA untuk mengubah kondisi-kondisi tersebut menjadi satu lapisan policy tersendiri, yang dicek sebelum settlement. Transaksi masuk lebih dulu, operator network memeriksa policy, lalu mengembalikan signed pass/fail attestation, dan barulah smart contract memutuskan apakah transaksi boleh dijalankan atau tidak.
Seperti sebuah mobil menuruni tanjakan—mesin yang bekerja dengan baik belum cukup. Ia juga perlu rem yang tahu kapan harus bekerja dengan tepat. Vault DeFi juga demikian: contract bisa berjalan dengan benar, tapi jika kesehatan oracle buruk, leverage melewati ambang, atau dompet tidak memenuhi syarat, sistem perlu tahu kapan waktunya menghentikan dana.
Saya menyebut ini Stop Logic.
Lapisan logika ini membantu smart contract tidak hanya tahu cara menjalankan, tapi juga tahu kapan harus berhenti.
Namun arah ini juga punya jebakan. Ketika hak untuk menolak transaksi ada di policy, pertanyaannya bukan hanya apakah contract sudah diaudit. Melainkan: siapa yang menulis policy, siapa yang memperbaruinya, dan apakah user paham alasan mengapa mereka diblokir.
Smart contract terbaik adalah yang mampu mengeksekusi.
Tapi DeFi yang matang tidak hanya butuh sesuatu yang tahu cara berjalan.
Ia butuh sesuatu yang tahu cara berhenti.
$NEWT $LAB #Newt
Terverifikasi
Kebijakan yang sama, tetapi parameter berbeda: Newton sedang memakai ulang hukum, atau sedang membungkus ulang kepercayaan?
Awalnya, saya mengira policy di Newton Protocol itu seperti kumpulan aturan yang tetap: ditulis sekali, di-upload, lalu semua aplikasi yang memakainya menghasilkan pola kontrol yang sama.
Tapi kalau dibaca lebih teliti, ternyata tidak sesederhana itu.
Newton memisahkan logika Rego dari bagian konfigurasi masing-masing PolicyClient. Artinya, policy yang sama bisa dipakai ulang, tetapi setiap aplikasi memasang parameternya sendiri: threshold berbeda, batas exposure berbeda, daftar approved-address berbeda.
Ini poin yang menarik.
Dan ini juga poin yang perlu ditanyakan dengan saksama.
Karena aturan yang sama tidak otomatis berarti tingkat kepercayaan yang sama. Satu vault bisa menggunakan risk policy yang sama, tetapi dengan batas yang lebih lebar. Aplikasi lain menggunakan logika yang sama, namun mengencangkan parameternya lebih ketat. Dari luar semuanya terlihat seperti “sudah lewat policy”, tetapi batas eksekusi yang sebenarnya berada di bagian konfigurasi.
Saya menyebutnya Parameter Trust.
Kepercayaan tidak hanya ada di hukum.
Kepercayaan ada pada siapa yang diberi wewenang untuk menjalankan hukum tersebut dengan parameter apa.
Bahkan expireAfter pun tidak sesederhana detail teknis. Kalau terlalu singkat, pengguna mungkin tidak sempat menyelesaikan transaksi. Kalau terlalu panjang, approval menjadi bertahan lebih lama, sehingga window keamanan lebih lebar.
Kelebihan @NewtonProtocol adalah setiap kali update konfigurasi akan membuat policyId baru, sehingga batas yang berubah menjadi terlihat. Tapi terlihat belum tentu berarti dipahami. Pengguna masih perlu tahu di balik policyId baru itu, apa sebenarnya yang telah berubah.
Dengan $NEWT , saya tidak akan hanya melihat jumlah policy yang dipakai ulang.
Saya ingin melihat siapa yang mengontrol parameternya.
Karena policy yang bisa dipakai ulang belum tentu menciptakan trust yang bisa dipakai ulang.
Sekumpulan aturan yang sama bisa menghasilkan dua tingkat keamanan yang sangat berbeda, jika orang yang memegang parameternya berbeda.
#Newt $NFP
Awalnya, saya mengira policy di Newton Protocol itu seperti kumpulan aturan yang tetap: ditulis sekali, di-upload, lalu semua aplikasi yang memakainya menghasilkan pola kontrol yang sama.
Tapi kalau dibaca lebih teliti, ternyata tidak sesederhana itu.
Newton memisahkan logika Rego dari bagian konfigurasi masing-masing PolicyClient. Artinya, policy yang sama bisa dipakai ulang, tetapi setiap aplikasi memasang parameternya sendiri: threshold berbeda, batas exposure berbeda, daftar approved-address berbeda.
Ini poin yang menarik.
Dan ini juga poin yang perlu ditanyakan dengan saksama.
Karena aturan yang sama tidak otomatis berarti tingkat kepercayaan yang sama. Satu vault bisa menggunakan risk policy yang sama, tetapi dengan batas yang lebih lebar. Aplikasi lain menggunakan logika yang sama, namun mengencangkan parameternya lebih ketat. Dari luar semuanya terlihat seperti “sudah lewat policy”, tetapi batas eksekusi yang sebenarnya berada di bagian konfigurasi.
Saya menyebutnya Parameter Trust.
Kepercayaan tidak hanya ada di hukum.
Kepercayaan ada pada siapa yang diberi wewenang untuk menjalankan hukum tersebut dengan parameter apa.
Bahkan expireAfter pun tidak sesederhana detail teknis. Kalau terlalu singkat, pengguna mungkin tidak sempat menyelesaikan transaksi. Kalau terlalu panjang, approval menjadi bertahan lebih lama, sehingga window keamanan lebih lebar.
Kelebihan @NewtonProtocol adalah setiap kali update konfigurasi akan membuat policyId baru, sehingga batas yang berubah menjadi terlihat. Tapi terlihat belum tentu berarti dipahami. Pengguna masih perlu tahu di balik policyId baru itu, apa sebenarnya yang telah berubah.
Dengan $NEWT , saya tidak akan hanya melihat jumlah policy yang dipakai ulang.
Saya ingin melihat siapa yang mengontrol parameternya.
Karena policy yang bisa dipakai ulang belum tentu menciptakan trust yang bisa dipakai ulang.
Sekumpulan aturan yang sama bisa menghasilkan dua tingkat keamanan yang sangat berbeda, jika orang yang memegang parameternya berbeda.
#Newt $NFP
Terverifikasi
Jika transaksi ditanya ulang setelah 6 bulan, apakah Newton Protocol dapat memberikan bukti tanda terima (receipt)?
Beberapa waktu lalu saya pergi ke bagian garansi untuk earphone. Staf bertanya soal faktur. Saya ingat dengan sangat jelas kalau saya membelinya di sana, ingat juga tanggal saya membelinya, ingat bahkan pegawai yang berdiri di konter. Tapi, ingatan itu tidak membantu apa-apa. Kalau tidak ada bukti tanda terima, semua penjelasan hanya akan terdengar seperti perasaan.
Saya teringat kisah soal onchain. Di sana, setiap transaksi memiliki jejak sejarah, tetapi tidak semua transaksi memiliki alasan.
Blockchain sangat bagus dalam menyimpan transaksi: siapa yang mengirim, mengirim berapa, mengirim kapan, kontrak mana yang menerima. Namun, untuk arus dana institusional, itu belum cukup. Karena riwayat transaksi hanya menjawab apa yang sudah terjadi.
Ia belum menjawab pertanyaan yang lebih sulit:
Mengapa transaksi itu diizinkan terjadi?
Di sinilah saya merasa @NewtonProtocol cukup menarik. Newton tidak hanya ingin transaksi bisa diverifikasi sebelum settlement. Ia juga dapat menciptakan semacam bukti kepatuhan (compliance receipt): bukti bahwa kebijakan telah diperiksa, kondisi telah lolos, attestation telah ditandatangani, lalu smart contract barulah mengizinkan transaksi untuk berlanjut.
Newton tidak hanya membantu DeFi untuk bisa berkata “bisa”.
Newton membantu DeFi menyimpan bukti untuk “anggukan” itu.
Poin ini terdengar kecil, tetapi sangat penting untuk stablecoin, RWA, vault, atau institusi. Karena keuangan berskala besar tidak beroperasi dengan kalimat “percayalah”. Ia membutuhkan jejak audit yang cukup jelas supaya nanti saat ditanya ulang, sistem tidak perlu mengorek log-log, menjelaskan dengan lisan, atau bergantung pada kredibilitas pihak perantara.
Dengan $NEWT , saya akan melihat compliance receipt yang sesungguhnya, bukan sekadar angka yang disebut di judul.
DeFi menjadi matang bukan saat semua transaksi berjalan lebih cepat.
Tapi saat setiap transaksi yang penting meninggalkan alasan yang cukup jelas agar diizinkan untuk berjalan.
#Newt
$VOOI $BASED
Beberapa waktu lalu saya pergi ke bagian garansi untuk earphone. Staf bertanya soal faktur. Saya ingat dengan sangat jelas kalau saya membelinya di sana, ingat juga tanggal saya membelinya, ingat bahkan pegawai yang berdiri di konter. Tapi, ingatan itu tidak membantu apa-apa. Kalau tidak ada bukti tanda terima, semua penjelasan hanya akan terdengar seperti perasaan.
Saya teringat kisah soal onchain. Di sana, setiap transaksi memiliki jejak sejarah, tetapi tidak semua transaksi memiliki alasan.
Blockchain sangat bagus dalam menyimpan transaksi: siapa yang mengirim, mengirim berapa, mengirim kapan, kontrak mana yang menerima. Namun, untuk arus dana institusional, itu belum cukup. Karena riwayat transaksi hanya menjawab apa yang sudah terjadi.
Ia belum menjawab pertanyaan yang lebih sulit:
Mengapa transaksi itu diizinkan terjadi?
Di sinilah saya merasa @NewtonProtocol cukup menarik. Newton tidak hanya ingin transaksi bisa diverifikasi sebelum settlement. Ia juga dapat menciptakan semacam bukti kepatuhan (compliance receipt): bukti bahwa kebijakan telah diperiksa, kondisi telah lolos, attestation telah ditandatangani, lalu smart contract barulah mengizinkan transaksi untuk berlanjut.
Newton tidak hanya membantu DeFi untuk bisa berkata “bisa”.
Newton membantu DeFi menyimpan bukti untuk “anggukan” itu.
Poin ini terdengar kecil, tetapi sangat penting untuk stablecoin, RWA, vault, atau institusi. Karena keuangan berskala besar tidak beroperasi dengan kalimat “percayalah”. Ia membutuhkan jejak audit yang cukup jelas supaya nanti saat ditanya ulang, sistem tidak perlu mengorek log-log, menjelaskan dengan lisan, atau bergantung pada kredibilitas pihak perantara.
Dengan $NEWT , saya akan melihat compliance receipt yang sesungguhnya, bukan sekadar angka yang disebut di judul.
DeFi menjadi matang bukan saat semua transaksi berjalan lebih cepat.
Tapi saat setiap transaksi yang penting meninggalkan alasan yang cukup jelas agar diizinkan untuk berjalan.
#Newt
$VOOI $BASED
Masuk untuk menjelajahi konten lainnya