BOTPass

Problem

Kalau daftar hadir disimpan di spreadsheet, orang lain hanya bisa percaya bahwa data di dalamnya benar. Peserta tidak punya bukti yang bisa diperiksa sendiri, sedangkan pihak luar tetap harus meminta akses ke panitia.

BOTPass mengambil bagian paling kecil dari masalah itu: mencatat bahwa sebuah wallet melakukan check-in pada sebuah event. Catatannya disimpan di contract, jadi status kehadiran dan jumlah peserta dapat dibaca lagi dari jaringan publik. BOTPass tidak menyimpan nama, email, nomor telepon, atau NIK.

Proyek ini kubuat untuk BOTChain Build Week Hackathon. Guidebook-nya lebih menghargai satu fitur yang bekerja penuh daripada banyak fitur yang setengah jadi. Karena itu, scope BOTPass sengaja pendek: buat event, buka check-in, kirim transaksi kehadiran, lalu periksa hasilnya.

Approach

Pengembangan difokuskan pada tiga alur yang dapat diverifikasi dari awal sampai akhir. Ukuran keberhasilannya bukan jumlah fitur, tetapi konsistensi aturan di contract, kejelasan state pada antarmuka, dan bukti bahwa setiap alur bekerja di jaringan yang dituju:

Peran	Aksi utama	Wallet	Gas
Penyelenggara	Membuat event dan membuka/menutup check-in	Ya	Ya
Peserta	Check-in untuk wallet miliknya sendiri	Ya	Ya
Pemeriksa	Membaca status kehadiran dan jumlah peserta	Tidak	Tidak

Pemeriksa tidak perlu memasang wallet karena verifikasi hanya melakukan read call. Wallet dan gas baru diperlukan saat ada perubahan state, seperti membuat event atau check-in.

Aturan satu-wallet-satu-check-in juga hidup di contract, bukan hanya di frontend. Kalau aturan ini ditaruh di JavaScript, orang masih bisa melewati UI dan memanggil contract secara langsung.

Frontend membedakan beberapa keadaan gagal: jaringan salah, event belum ada, check-in masih tertutup, waktu event belum mulai atau sudah lewat, saldo BOT tidak cukup, transaksi ditolak, dan wallet sudah pernah check-in. Pengguna jadi tahu apa yang terjadi tanpa harus membaca error mentah dari RPC.

Architecture

Browser
  |
  +-- read-only provider --------> BOT Chain RPC
  |                                  |
  |                                  v
  |                             BOTPass contract
  |                                  |
  +-- MetaMask + signer -------------+
                                     |
                                     v
                              state dan event log
                                     |
                                     v
                                BOTScan

Contract ditulis dengan Solidity 0.8.20 dan memakai Ownable2Step dari OpenZeppelin Contracts 5.0.2. Di dalamnya ada detail event, status check-in, relasi event–wallet, dan attendance count.

Penyelenggara dapat membuat event serta membuka atau menutup check-in. Peserta hanya bisa mencatat wallet yang sedang memanggil contract. Getter terpisah menyediakan detail event, status sebuah wallet, dan jumlah kehadiran.

Frontend-nya memakai HTML, CSS, vanilla JavaScript, ethers.js, dan Vite. Tidak ada backend atau database attendee. Provider read-only menangani pembacaan data, sedangkan signer hanya dibuat saat pengguna perlu mengirim transaksi.

Untuk Mainnet, deployment script memeriksa Chain ID 677, alamat deployer, saldo, gas estimate, source tree, dan artifact sebelum meminta konfirmasi. Setelah transaksi sukses, runtime bytecode pada alamat baru dibandingkan dengan artifact. Alamat contract juga tidak langsung masuk ke frontend produksi sebelum deployment record dan hash-nya cocok.

Outcome

Contract Mainnet BOTPass berada di 0xFd7…33133 pada Chain ID 677. Source Solidity-nya sudah terverifikasi di BOTScan dengan compiler 0.8.20, EVM paris, dan optimizer 200 runs.

Frontend dapat dibuka di botpass.online, sedangkan source lengkapnya tersedia di GitHub.

Suite Hardhat menghasilkan 107 passing. Test-nya mencakup lifecycle event, otorisasi owner, batas waktu, check-in duplikat, getter kehadiran, pemisahan Testnet/Mainnet, deployment record, dan guard pada jalur deployment.

Saat case study ini diterbitkan, proses penjurian hackathon masih berlangsung. Karena itu, outcome di atas dibatasi pada bukti teknis yang sudah dapat diperiksa dan tidak mencantumkan klaim hasil kompetisi atau angka penggunaan.

Lessons

Pelajaran utamanya adalah membedakan bukti on-chain dari klaim di luar sistem. Contract dapat membuktikan bahwa sebuah wallet melakukan check-in yang valid, tetapi tidak dapat menyimpulkan siapa pemilik wallet atau apakah orang tersebut benar-benar berada di lokasi acara.

Pemisahan read-only provider dan signer juga penting. Pemeriksa dapat membaca status tanpa memasang wallet, sedangkan akses wallet hanya diminta saat pengguna benar-benar perlu mengubah state. Pola ini mengurangi friksi tanpa mengaburkan batas keamanan.

Terakhir, aturan kritis seperti satu-wallet-satu-check-in harus berada di contract. Validasi frontend tetap berguna untuk pengalaman pengguna, tetapi tidak boleh menjadi satu-satunya lapisan yang menjaga invariant produk.