Setiap kali ngobrol sama sesama engineer atau rekan-rekan developer di Indonesia yang sering ambil maupun mendelegasikan proyek teknis jarak jauh, pola masalah yang muncul hampir selalu berputar di titik yang sama. Kerumitan utamanya jarang terletak pada waktu kita menulis kode, merapikan skrip otomasi, atau menyusun dokumentasi arsitektur, melainkan pada ketidakpastian di tahap pemeriksaan hasil akhir. Di banyak kesepakatan kerja konvensional, deskripsi tugas di awal hanya ditulis beberapa baris secara garis besar, tetapi begitu hasil pekerjaan diserahkan, tolok ukur pemeriksaannya tiba-tiba melebar mengikuti selera subjektif pihak yang memeriksa di hari itu.
Kalau kita bedah secara jujur dari sisi rekayasa sistem, inti persoalannya sebenarnya sederhana: di sebagian besar alur kerja maupun platform perantara tradisional, fungsi penyimpanan dana sudah lama berhasil diotomatisasi lewat rekening bersama, tetapi fungsi penilaian kelayakan hasil kerja masih dibiarkan mengambang sampai pekerjaan selesai. Selama definisi tentang apa yang membuat sebuah kiriman layak diterima baru dirumuskan belakangan setelah berkas dikirim, celah sengketa dan revisi tanpa ujung akan selalu terbuka lebar.
Berangkat dari pengamatan atas masalah urutan waktu tersebut, belakangan ini saya cukup tertarik mempelajari pendekatan yang diterapkan oleh protokol Verdikta Bounties di jaringan Base (https://bounties.verdikta.org). Hal yang menurut saya paling menarik bukanlah sekadar mekanisme penitipan dananya di dalam kontrak pintar, melainkan aturan arsitekturnya yang memaksa seluruh kriteria penilaian dikunci secara terbuka di depan sebelum ada orang yang mulai mengerjakan tugas. Saat pembuat tugas mengunci dana di dalam kontrak escrow Base, mereka juga wajib mempublikasikan dokumen rubrik penilaian yang disimpan di IPFS dan diikat langsung ke kontrak. Rubrik tersebut membagi aturan secara tegas menjadi dua tahap: gerbang syarat mutlak yang wajib lulus seratus persen di tahap pertama, serta deretan kriteria kualitas yang masing-masing memiliki bobot persentase beserta angka ambang batas kelulusan di tahap kedua.
Begitu seseorang mengirimkan bundel hasil kerjanya, proses pemeriksaan tidak lagi diserahkan kepada suasana hati pembuat tugas, melainkan dieksekusi oleh panel juri kecerdasan buatan (AI) terdesentralisasi yang terdiri dari beberapa model independen. Setiap model di dalam panel tersebut memeriksa bukti kerja berdasarkan rubrik IPFS tadi, lalu menerbitkan rincian skor angka untuk setiap kriteria lengkap dengan catatan alasan tertulisnya secara terbuka dan dapat diaudit publik. Apabila nilai gabungan dari panel berhasil melampaui ambang batas kelulusan yang telah ditetapkan, kontrak pintar secara otomatis langsung mencairkan dana escrow ke dompet pengirim pertama yang memenuhi syarat, sedangkan jika tenggat waktu berakhir tanpa ada kiriman yang lulus, dana kembali utuh ke pembuat tugas. Dari sisi efisiensi biaya, protokol ini tidak memungut komisi platform (0% biaya platform), sehingga pengirim hanya perlu menanggung biaya gas jaringan Base dan deposit pemrosesan orakel sekitar 0.00024 ETH untuk membiayai putaran evaluasi panel.
Tentu saja, mengganti penilai manusia dengan panel model AI di atas kontrak pintar bukanlah solusi ajaib tanpa celah, dan ada tiga batasan nyata yang menurut saya wajib dicermati secara realistis. Pertama, model AI hanya mampu memverifikasi bukti digital yang disertakan di dalam kiriman—seperti kode sumber, teks, tautan halaman publik, atau tangkapan layar—sehingga sistem ini sama sekali tidak bisa dipakai untuk memvalidasi pekerjaan fisik di dunia nyata. Kedua, keadilan hasil akhir bergantung penuh pada kualitas penulisan rubrik di awal: jika pembuat tugas merumuskan kalimat kriteria yang kabur atau bertabrakan, maka evaluasi otomatis yang paling transparan sekalipun tetap akan menghasilkan skor yang timpang, dan karena rubriknya sudah terkunci di on-chain, kesalahan spesifikasi itu tidak bisa diedit di tengah jalan. Ketiga, eksekusi kontrak pintar bersifat kaku terhadap angka ambang batas, sehingga kiriman pekerjaan yang sebenarnya sudah sangat rapi tetapi berhenti tipis satu poin di bawah batas lulus tetap akan ditolak otomatis tanpa ruang negosiasi manusia.
Meskipun memiliki batasan tersebut, memindahkan perumusan tolok ukur penilaian ke depan dan mewajibkan alasan tertulis yang bisa diaudit untuk setiap poin pemeriksaan menurut saya adalah langkah desain yang jauh lebih sehat dibanding penolakan sepihak tanpa alasan. Bagi rekan-rekan di komunitas #indonesia yang sering berkutat dengan proyek perangkat lunak atau tugas berbasis web3, apakah kalian merasa sistem rubrik terkunci seperti ini membantu memberikan kepastian, atau justru membuat ruang kompromi teknis menjadi terlalu sempit?
