Verdikta Bounties：技術任務如何透過智能合約託管，預先鎖定評分準則

Beberapa bulan terakhir saya bersama beberapa rekan developer di Jakarta sering berdiskusi soal satu masalah struktural yang hampir selalu muncul waktu kita mengambil atau mendelegasikan pekerjaan teknis jarak jauh (seperti pembuatan skrip otomasi, audit kontrak pintar, atau dokumentasi teknis). Mengapa proses serah-terima hasil kerja secara online sering kali berujung pada perdebatan panjang, meskipun pekerja sudah merasa mengikuti instruksi awal?

Kalau kita perhatikan pola umumnya di lapangan, akar masalahnya hampir selalu terletak pada urutan waktu penilaian. Biasanya spesifikasi tugas hanya ditulis secara garis besar di awal, lalu pekerja menyerahkan hasil akhirnya, dan baru setelah file diterima pihak pemberi kerja mulai menyusun alasan mengapa hasilnya dianggap kurang cocok. Bahkan ketika platform perantara menyediakan fitur mediasi, tolok ukur yang dipakai sering kali baru dirumuskan belakangan setelah konflik terjadi. Akibatnya, pekerja tidak punya acuan objektif yang terkunci sejak awal untuk membuktikan bahwa seluruh syarat teknis sebenarnya sudah terpenuhi.

Berangkat dari rasa penasaran terhadap masalah urutan waktu tersebut, minggu ini saya mencoba membedah dan menguji langsung alur kerja pada protokol Verdikta Bounties yang berjalan di atas jaringan Base (https://bounties.verdikta.org). Hal yang menarik perhatian saya bukanlah sekadar penggunaan kontrak pintar sebagai tempat penitipan dana, melainkan bagaimana protokol ini membalik urutan proses pemeriksaan melalui dokumen rubrik yang disimpan di IPFS dan diikat langsung ke kontrak sebelum tugas dibuka. Di dalam rubrik tersebut, pembuat tugas wajib menetapkan dua lapisan aturan secara terbuka: syarat mutlak yang bersifat lulus-atau-gugur di tahap pertama, serta rincian kriteria kualitas beserta persentase bobot nilai dan ambang batas skor kelulusan (misalnya harus mencapai minimal 92 dari 100 poin) di tahap kedua.

Saat saya mengamati bagaimana kiriman pekerjaan dievaluasi di jaringan Base, prosesnya ternyata cukup berbeda dari bayangan awal saya. Penilaian sama sekali tidak melibatkan intervensi manual dari pembuat tugas, melainkan dijalankan oleh panel juri kecerdasan buatan (AI) independen yang terdiri dari beberapa model berbeda yang mengevaluasi bukti kerja secara paralel. Alih-alih hanya mengeluarkan status diterima atau ditolak secara sepihak, setiap model di dalam panel juri tersebut menerbitkan rincian skor angka untuk masing-masing kriteria beserta catatan alasan tertulisnya yang bisa dibaca publik. Ketika skor gabungan dari panel berhasil melewati ambang batas yang telah dikunci di awal, kontrak pintar secara otomatis langsung mengirimkan dana dari escrow ke dompet pengirim pertama yang lulus, sedangkan jika waktu habis tanpa ada kiriman yang memenuhi syarat, dana dikembalikan ke pembuat tugas. Selama pengujian, protokol ini tidak memotong komisi platform (0% biaya platform); pengirim hanya perlu menyiapkan sedikit ETH di jaringan Base untuk biaya gas transaksi dan deposit pemeriksaan orakel sekitar 0.00024 ETH.

Walaupun mekanisme ini terasa jauh lebih terukur dibanding negosiasi subjektif, dari pengamatan saya ada tiga keterbatasan teknis yang patut dipertimbangkan secara realistis. Pertama, panel model AI hanya mampu memverifikasi bukti digital yang dikirimkan di dalam bundel pekerjaan—seperti repositori kode, teks, tautan halaman publik, atau tangkapan layar—sehingga pendekatan ini tidak cocok untuk pekerjaan yang membutuhkan pengujian perangkat keras fisik atau interaksi langsung di luar jaringan. Kedua, kualitas keadilan bergantung penuh pada ketepatan perumusan rubrik di awal: apabila pembuat tugas menulis kriteria yang kabur atau tumpang tindih, maka evaluasi otomatis yang transparan sekalipun tetap akan menghasilkan skor yang melenceng. Ketiga, karena batas kelulusan dieksekusi secara kaku oleh kontrak pintar, kiriman pekerjaan yang sebenarnya sudah sangat rapi tetapi memperoleh skor rata-rata sedikit di bawah ambang batas (misalnya 90.4 dari syarat 92) tetap akan dinyatakan gagal tanpa ruang negosiasi tambahan.

Saya penasaran apakah teman-teman developer di komunitas #indonesia ada yang pernah merancang sistem serupa atau mencoba mekanisme escrow otomatis berbasis rubrik seperti ini untuk proyek lepas? Menurut kalian, bagaimana cara terbaik menjaga agar spesifikasi rubrik di awal cukup ketat untuk mencegah sengketa, tetapi tidak menjadi terlalu kaku saat menilai variasi solusi teknis?