Fase 2 · Standar Token & Tokenisasi RWA

ERC-3643 & ERC-1400 — security token & KYC

ERC-20 sengaja dirancang permissionless — siapa pun bisa menerima token siapa pun. Tapi saham dan sebagian besar RWA diatur hukum: hanya investor terverifikasi yang boleh memegangnya, dan regulator harus bisa membekukan atau memulihkan aset dalam kondisi tertentu. ERC-3643 menambahkan lapisan kepatuhan itu di atas fondasi ERC-20.

Sumber asli eips.ethereum.org Resmi Rangkuman ~8 menit baca

Intisari

ERC-3643 (dulu dikenal sebagai T-REX) dan ERC-1400 adalah standar permissioned token — transfer hanya berhasil kalau kedua pihak lolos pemeriksaan kepatuhan, bukan cuma pemeriksaan saldo seperti ERC-20.
Komponen inti: Identity Registry (siapa saja yang sudah KYC dan boleh memegang token) dan Compliance Module (aturan tambahan — batas kepemilikan, batasan yurisdiksi, dst.).
Berbeda dari ERC-20, transfer bisa ditolak on-chain kalau penerima belum terverifikasi — bukan diblokir manual oleh backend setelah kejadian.
Menyediakan fungsi agent yang bisa freeze saldo atau melakukan forced transfer — dibutuhkan hukum untuk pemulihan aset (mis. perintah pengadilan, akun pemegang saham meninggal).
Ini pengorbanan sadar terhadap prinsip "trustless" murni: sistem yang sepenuhnya patuh regulasi butuh otoritas yang bisa campur tangan — dan itu bukan bug, itu syarat legalitasnya.

Kenapa ERC-20 tidak cukup untuk saham

ERC-20 dirancang agar siapa pun bisa mengirim token ke siapa pun, tanpa pemeriksaan identitas. Untuk saham atau RWA yang diatur regulasi sekuritas, ini masalah serius: hukum di hampir semua yurisdiksi mengharuskan hanya investor yang lolos KYC/AML yang boleh memegang instrumen semacam ini, dan sering ada batasan tambahan — jumlah maksimum pemegang, larangan yurisdiksi tertentu, periode lock-up.

Dua komponen inti

Komponen	Fungsinya	Analog Web2
Identity Registry	Daftar on-chain address yang sudah lolos KYC, ditautkan ke identitas terverifikasi (`OnchainID`)	Tabel `verified_users`
Compliance Module	Aturan tambahan yang dicek sebelum transfer diizinkan — batas kepemilikan, negara yang diperbolehkan, dst.	Middleware validasi bisnis sebelum `COMMIT`

// Sketsa sederhana — implementasi nyata memakai modul terpisah dari
// paket referensi ERC-3643, ini untuk menunjukkan konsepnya
function transfer(address ke, uint256 jumlah) public override returns (bool) {
    require(identityRegistry.isVerified(msg.sender), "Pengirim belum KYC");
    require(identityRegistry.isVerified(ke), "Penerima belum KYC");
    require(compliance.canTransfer(msg.sender, ke, jumlah), "Melanggar aturan kepatuhan");

    return super.transfer(ke, jumlah);
}

Bedanya dengan "memblokir manual setelah kejadian". Sistem naif mungkin membiarkan transfer ERC-20 biasa terjadi, lalu backend mendeteksi pelanggaran dan membekukan akun secara administratif setelah fakta. ERC-3643 mencegahnya sebelum transaksi masuk block — transaksi yang melanggar kepatuhan langsung revert, dicatat sebagai gagal di blockchain itu sendiri, bukan ditangani di luar rantai setelah kerusakan terjadi.

Kemampuan agent: `freeze` dan forced transfer

Ini bagian yang paling terasa asing bagi yang datang dari filosofi "code is law" murni — dan justru bagian yang membuat standar ini bisa dipakai untuk instrumen keuangan sungguhan:

Kemampuan	Kapan dipakai
`setAddressFrozen(address, bool)`	Investigasi hukum, sanksi, perintah pengadilan
`forcedTransfer(dari, ke, jumlah)`	Pemegang saham meninggal dan ahli waris butuh pemulihan aset, atau perintah pengadilan
`recoveryAddress(address lama, address baru)`	Investor kehilangan akses ke wallet-nya, identitas sudah diverifikasi ulang lewat proses KYC

Ini bukan celah keamanan — ini syarat legal. Instrumen keuangan teregulasi harus punya jalur pemulihan yang diawasi otoritas berwenang, persis seperti bank bisa membekukan rekening atas perintah pengadilan. Bedanya dengan sistem terpusat: siapa yang menjadi "agent" dan kapan wewenang itu boleh dipakai tercatat dan bisa diaudit di kontrak itu sendiri — bukan kebijakan internal yang tidak transparan.

ERC-1400: pendekatan alternatif

ERC-1400 menyelesaikan masalah yang sama dengan pendekatan modular berbeda — memecah token jadi partition (kelas saham berbeda dalam satu kontrak) dan menambahkan canTransfer() sebagai fungsi preflight check yang bisa dipanggil sebelum transaksi sungguhan dikirim, supaya frontend bisa menampilkan alasan penolakan sebelum pengguna membayar gas untuk transaksi yang pasti gagal. Keduanya (ERC-3643 dan ERC-1400) dipakai di industri; ERC-3643 lebih umum untuk penerbitan baru karena spesifikasinya lebih preskriptif dan sudah diadopsi beberapa platform tokenisasi besar.

Latihan: baca bagian "Rationale" di EIP-3643, lalu buat daftar: aturan kepatuhan apa saja yang menurutmu wajib ada untuk platform tokenisasi saham di Indonesia (pertimbangkan OJK, batas kepemilikan asing, dst.) — ini latihan berpikir, bukan latihan kode, tapi akan langsung dipakai saat merancang Compliance Module sungguhan.

Rangkuman ini sengaja dipangkas ke bagian yang dipakai di roadmap. Buka sumber aslinya saat kamu butuh detail lengkap atau referensi parameter.