Agus Wira.
← Kembali ke project
Web3DAppSmart ContractHackathon

BOTPass

DApp check-in event di BOT Chain. Peserta mencatat kehadiran lewat wallet, lalu siapa pun dapat memeriksa statusnya langsung dari smart contract tanpa mengakses data pribadi peserta.

Role
Solo builder. Saya menentukan use case, merancang alur wallet, membuat frontend dan smart contract, serta menangani testing dan deployment.
Timeline
25 Juli–6 Agustus 2026. Dibuat untuk submission BOTChain Build Week Hackathon dan tidak dikembangkan lagi setelah kompetisi selesai.

Stack

  • Solidity 0.8.20
  • OpenZeppelin Contracts 5.0.2
  • Hardhat
  • ethers.js
  • Vite
  • Vanilla JavaScript
  • HTML
  • CSS
  • MetaMask

Problem

Saya menemukan BOTChain Build Week Hackathon ketika belum memahami BOT Chain maupun cara membuat DApp di jaringannya. Pendaftarannya gratis, jadi saya memakainya sebagai kesempatan untuk mencoba bidang yang baru bagi saya.

Hackathon ini berlangsung online dan terbuka untuk semua orang. Ini menjadi pengalaman pertama saya mengikuti hackathon online. Untuk menyelesaikan submission, saya harus mempelajari ekosistem BOT Chain dari awal sambil membuat project yang benar-benar berjalan di jaringan tersebut.

Problem yang saya pilih

Daftar hadir yang disimpan di spreadsheet hanya dapat diperiksa melalui pihak yang mengelolanya. Peserta tidak memiliki bukti yang dapat mereka periksa sendiri, sedangkan pihak lain harus meminta akses kepada panitia.

BOTPass mengambil satu bagian kecil dari masalah tersebut: mencatat bahwa sebuah wallet melakukan check-in pada suatu event. Catatan disimpan di smart contract agar status kehadiran dan jumlah peserta dapat dibaca dari jaringan publik. BOTPass tidak menyimpan nama, email, nomor telepon, atau NIK.

Guidebook hackathon lebih menghargai satu fitur yang selesai daripada banyak fitur yang hanya bekerja sebagian. Karena itu, scope BOTPass dibatasi pada empat langkah: membuat event, membuka check-in, mengirim transaksi kehadiran, dan memeriksa hasilnya.

Approach

Penyelenggara secara eksplisit mengizinkan penggunaan AI tools. Selama proses pengembangan, saya memakai AI untuk membantu memahami konsep, menulis code, dan melakukan debugging. Saya tetap perlu memeriksa hasilnya melalui dokumentasi, test, dan deployment langsung ke BOT Chain.

Alur penggunaan

Ada tiga peran dalam BOTPass:

PeranAksi utamaWalletGas
PenyelenggaraMembuat event dan membuka/menutup check-inYaYa
PesertaCheck-in untuk wallet miliknya sendiriYaYa
PemeriksaMembaca status kehadiran dan jumlah pesertaTidakTidak

Pemeriksa tidak perlu memasang wallet karena proses verifikasi hanya melakukan read call. Wallet dan gas diperlukan ketika pengguna mengubah state, misalnya saat membuat event atau melakukan check-in.

Aturan satu wallet untuk satu check-in berada di smart contract. Jika aturan tersebut hanya ada di JavaScript, pengguna masih dapat melewati UI dan memanggil contract secara langsung.

Frontend membedakan beberapa kondisi 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 tidak perlu membaca error mentah dari RPC untuk mengetahui masalahnya.

Architecture

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

Smart contract ditulis dengan Solidity 0.8.20 dan memakai Ownable2Step dari OpenZeppelin Contracts 5.0.2. Contract menyimpan detail event, status check-in, relasi antara event dan wallet, serta jumlah kehadiran.

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

Frontend memakai HTML, CSS, vanilla JavaScript, ethers.js, dan Vite. BOTPass tidak memiliki backend atau database peserta. Read-only provider menangani pembacaan data, sedangkan signer hanya dibuat ketika pengguna mengirim transaksi.

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

Outcome

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

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

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

BOTPass tidak menjadi pemenang hackathon. Pengembangannya berhenti setelah submission, tetapi frontend dan contract Mainnet masih dapat diakses.

Lessons

Bagian tersulit dari hackathon ini adalah mempelajari sistem yang sebelumnya belum saya pahami sambil tetap mengejar submission. Saya menggunakan AI sebagai alat bantu untuk memahami, menulis, dan memperbaiki code, lalu menggunakan test dan deployment untuk memeriksa apakah hasilnya benar-benar bekerja.

Saya juga belajar membedakan bukti on-chain dari klaim di luar sistem. Smart contract dapat membuktikan bahwa sebuah wallet melakukan check-in yang valid, tetapi tidak dapat memastikan siapa pemilik wallet atau apakah orang tersebut benar-benar berada di lokasi acara.

Pemisahan read-only provider dan signer membuat pemeriksa dapat membaca status tanpa memasang wallet. Akses wallet baru diminta ketika pengguna perlu mengubah state. Aturan yang menjaga integritas data, seperti satu wallet untuk satu check-in, tetap harus berada di smart contract karena validasi frontend dapat dilewati.