RWA（Aset Dunia Nyata） sedang menjadi arah penting dalam integrasi mendalam antara Web3 dan keuangan tradisional. Dibandingkan DeFi tradisional, protokol RWA tidak hanya menampung perputaran aset di chain, tetapi juga secara langsung memetakan aset dunia nyata seperti obligasi, saham, properti, peralatan, hak penghasilan, dan lain-lain, dengan batas keamanan yang meluas dari “keamanan kode” ke “pengakuan hak, tata kelola yang sesuai regulasi, dan eksekusi di luar chain”.

Dari sudut pandang audit, tantangan inti RWA tidak lagi sekadar mencegah pencurian dana, tetapi bagaimana memastikan logika kode, aturan bisnis, dan hak hukum dunia nyata tetap konsisten: satu perubahan izin bisa berarti pembekuan aset; satu transfer paksa bisa mempengaruhi hak kredit di dunia nyata.

Artikel ini akan mengulas secara sistematis modul inti, risiko umum, dan fokus audit dari protokol RWA, mulai dari klasifikasi keluarga protokol, implementasi standar, hingga praktik audit keamanan, membantu pengembang dan auditor dengan cepat membangun metodologi keamanan yang berorientasi pada pemetaan aset dunia nyata.

Mengingat keterbatasan ruang, artikel ini akan menampilkan kerangka inti, modul kunci, dan kesimpulan utama terlebih dahulu. Jika ingin melihat konten lengkap, silakan kunjungi GitHub: [Link].

1. Pendahuluan: Dari sudut pandang audit kode terhadap RWA

1.1 Dimensi keamanan gabungan dan tantangan audit yang diperkenalkan oleh protokol RWA

Dari sudut pandang audit kode, perbedaan terbesar antara protokol RWA dan DeFi biasa ada tiga poin.

Pertama, esensi aset berbeda: kode hanyalah sebuah “pemetaan”.
Kedua, izin dan peran lebih padat dan sensitif.
Ketiga, proses bisnis melibatkan chain dan off-chain secara bersamaan.

Dalam DeFi tradisional, siklus hidup sebuah transaksi biasanya sepenuhnya ditangani kontrak: dari panggilan, perhitungan, hingga pembaruan status dilakukan di chain.

Sedangkan di RWA, jalur umum adalah:
Pengguna memanggil redeem() atau forcedTransfer() di chain → kontrak memperbarui status dan mencatat event → sistem off-chain menerima notifikasi, melakukan pengiriman aset nyata, transfer kepemilikan, atau likuidasi → hasilnya kemudian dikembalikan melalui mekanisme tertentu (atau tetap di luar chain).

1.2 Misi utama audit RWA

Dalam sebuah proyek RWA tipikal, tujuan audit keamanan tidak lagi sekadar “mencegah dana dicuri hacker secara langsung”, tetapi harus menjaga tiga garis dasar:

• Kebenaran dan keamanan: kode tidak boleh error.
• Konsistensi: perilaku kode harus sesuai aturan yang dinyatakan proyek.
• Auditabilitas: saat muncul masalah di masa depan, bukti di chain harus dapat menjelaskan semuanya.

1.3 Perspektif dan batasan artikel ini

Artikel ini membahas RWA dari sudut pandang audit keamanan.

• Untuk pengembang, artikel ini bisa dianggap sebagai “desain yang diturunkan dari audit balik ke awal”.
• Untuk auditor, bisa dipakai sebagai “panduan dan checklist audit RWA”.

Selain pengalaman “audit kontrak pintar” yang sudah ada, ditambahkan pengetahuan khusus tentang struktur protokol RWA dan fokus auditnya.

Tujuannya agar pengembang dapat mengembangkan protokol RWA secara spesifik, dan auditor tidak lagi terbatas pada bagian chain saja, tetapi memiliki sistem metodologi yang khusus untuk skenario pemetaan aset dunia nyata.

Artikel ini tidak akan membahas secara detail:

• Regulasi negara dan kasus hukum tertentu (hanya menyebutkan keberadaan batasan tersebut bila relevan).
• Penjelasan dasar Solidity atau standar ERC, menganggap pembaca sudah berpengalaman di DeFi/NFT.
• Penilaian “proyek bagus” dari sudut Tokenomics, melainkan fokus pada keamanan dan keandalan model RWA yang diklaim.

2. Sekilas modul protokol RWA dan kode

2.1 Dari bisnis: Tentukan dulu kategori RWA

Dari sudut pandang audit keamanan bisnis, kita bisa mengklasifikasikan proyek secara kasar ke dalam empat kategori berikut:

1. RWA berbentuk sekuritas / saham / obligasi
2. RWA properti / real estate
3. RWA barang fisik / peralatan / batch produk
4. RWA hak penghasilan / struktur / kepemilikan terbagi

2.2 Dari standar ke implementasi: “Memahami cukup” keluarga protokol RWA umum

2.2.1 Standar sekuritas yang sesuai regulasi
Standar ini menyelesaikan: bagaimana menerbitkan dan mengedarkan “sekunder yang diatur” / produk sekuritisasi di chain, sambil memenuhi KYC, batas transfer, operasi paksa, dan regulasi lainnya.

2.2.2 Standar properti / real estate
Inti tantangan properti RWA bukan “bagaimana menerbitkan Token”, tetapi “bagaimana mengstrukturkan dan mengamankan berbagai informasi properti ke dalam kontrak”.

2.2.3 Standar perangkat fisik / pertukaran barang nyata
Standar ini biasanya menyelesaikan dua masalah: bagaimana mengikat Token/NFT dengan barang nyata; dan dalam hubungan ikatan tersebut, bagaimana melakukan pertukaran, penggunaan, dan pembatalan.

2.2.4 Standar aset terstruktur / interface umum RWA
Standar ini lebih fokus pada “struktur aset kompleks” dan “antarmuka seragam”.

2.3 Arsitektur kontrak RWA tipikal

Tak peduli kategori apa proyek termasuk, selama protokol RWA cukup lengkap, struktur kode umumnya akan memiliki modul-modul berikut:

1. Modul inti Token
2. Modul izin dan peran
3. Modul kepatuhan / whitelist
4. Modul penebusan / likuidasi
5. Modul metadata / informasi aset
6. Modul upgrade dan tata kelola

2.4 Metode cepat identifikasi RWA dalam 3 langkah

Langkah pertama: baca materi bisnis, tentukan tipe aset dan standar.
Langkah kedua: cari kata kunci di kode.
Langkah ketiga: buat diagram arsitektur.

3. Dekonstruksi mendalam keluarga protokol: model regulasi standar RWA utama

Artikel ini akan mengulas secara mendalam dari kode, menganalisis standar RWA utama yang ada saat ini.

I. RWA berbentuk sekuritas: analisis mendalam ERC-1400 (UniversalToken)

1. Arsitektur kontrak secara keseluruhan

ERC-1400 (UniversalToken) dikembangkan oleh ConsenSys, merupakan platform penerbitan dan pengelolaan token sekuritas berbasis standar ERC1400, dengan fitur pengelolaan bagian (partition), mekanisme kepemilikan (hold), verifikasi sertifikat, penerbitan dana, dan pertukaran token. Platform ini utamanya untuk penerbitan, transaksi, dan pengelolaan sekuritas yang patuh regulasi, dengan kontrol izin yang granular dan fitur pengawasan.

Kerangka kerja ini dapat dibagi menjadi enam modul inti:

• Inti: Implementasi ERC1400 mencakup seluruh logika utama sekuritas, termasuk penerbitan, penebusan, transfer, dan buku besar bagian (Partition).
• Manajemen peran (Roles): Mengimplementasikan RBAC (Role-Based Access Control) yang detail.
• Validator: “Otak kepatuhan” RWA, berisi logika pemeriksaan regulasi seperti whitelist, blacklist, verifikasi sertifikat, kontrol penangguhan transaksi, dan lain-lain.
• Ekstensi: Menyediakan implementasi produk untuk skenario bisnis tertentu.
• Modul ekstensi pengguna: Melalui hook pengirim dan penerima, token dapat diprogram.
• Modul alat: Menyediakan utilitas seperti DomainAware, ERC1820, dan alat batch.

2. Analisis kontrak inti ERC1400 (UniversalToken) secara mendalam**

2.1 Rincian struktur data utama
2.1.1 Informasi dasar token
Selain metadata standar ERC20, kontrak menambahkan parameter yang bermakna sebagai sekuritas:

• granularity: memastikan unit transaksi terkecil (terfragmentasi).
• isControllable: mengizinkan regulator atau penerbit melakukan transfer paksa atau penebusan.
• isIssuable: mengontrol apakah token bisa diterbitkan lagi.
• migrated: saat upgrade kontrak, memungkinkan migrasi ke versi baru dan pencatatan di registry.

2.1.2 Bagian (Partition) - inovasi utama ERC1400
Partition adalah mekanisme inovatif yang membagi token dalam kontrak menjadi beberapa bagian independen, masing-masing memiliki saldo dan total pasokan sendiri.

2.1.3 Sistem izin operator (Operator)

ERC1400 mendesain sistem izin operator tiga tingkat:

• Global Controllers: alamat yang mewakili penerbit sekuritas, regulator, atau entitas dengan hak istimewa khusus.
• Authorized Operators: yang diberi izin oleh pemilik token, mirip approve ERC20 tapi lebih luas.
• Partition Operators: izin khusus untuk bagian tertentu.

2.1.4 Sistem pengelolaan dokumen

• Mengintegrasikan standar ERC1643 untuk pengelolaan dokumen, menyelesaikan masalah legalitas “pengakuan hak di chain dan bukti off-chain”.
• Dokumen diatur melalui URI, hash, dan timestamp.
• Hak pengaturan dan penghapusan dokumen dibatasi pada pengelola resmi.
• Sistem ini bisa menyimpan berbagai dokumen penting.

2.2 Analisis modul fungsi utama

2.2.1 Fungsi penerbitan (Issuance)
Penerbitan token adalah awal siklus hidup sekuritas. ERC1400 mendesain mekanisme penerbitan yang fleksibel dan aman, terbatas pada yang memiliki peran Minter atau owner dan saat flag penerbitan aktif.
Dukungan mode: penerbitan sederhana dan bagian (partition). Penerbitan sederhana menambah token ke bagian default, cocok untuk skenario sederhana. Penerbitan bagian memungkinkan menentukan bagian tertentu.
Dalam praktik nyata, mekanisme ini cocok untuk berbagai skenario: IPO/STO, private placement, opsi karyawan, dividen saham, dll.

2.2.2 Fungsi penebusan (Redemption)
Penebusan adalah bagian penting, menandakan keluar dan penghancuran aset serta pengurangan pasokan. ERC1400 menyediakan empat jalur penebusan:

• Penebusan aktif oleh pemilik (bakar token sendiri).
• Penebusan oleh operator yang diberi izin.
• Penebusan bagian tertentu.
• Semua proses penebusan melalui verifikasi lengkap, termasuk hook pengirim dan validator token, memastikan kepatuhan.

Dalam praktik nyata, mekanisme ini cocok untuk: buyback saham, likuidasi perusahaan, obligasi callable, penarikan saham yang melanggar aturan.

2.2.3 Mekanisme transfer dan pemeriksaan kepatuhan
Transfer adalah fungsi utama transaksi sekuritas. ERC1400 mendesain mekanisme transfer multi-layer:

• Transfer bagian default yang kompatibel ERC20.
• Transfer bagian tertentu.
• Pemeriksaan kepatuhan berlapis selama proses transfer, sesuai regulasi.

Dalam praktik nyata, cocok untuk: transaksi pasar sekunder, settlement DVP, transfer antar rekening kustodian, cross-border compliance.

2.3 Sistem hook (pengait) yang dapat dipasang - modul kepatuhan yang dapat disesuaikan
Selama proses transfer, pemeriksaan kepatuhan dilakukan melalui hook yang disediakan ERC1400.

2.3.1 Hook pengirim (Sender Hook)
Dipanggil sebelum token meninggalkan alamat pengirim, memungkinkan kustomisasi logika transfer. Pengguna dapat mendaftar hook sendiri.
Contoh aplikasi: pembatasan volume transaksi, pengenaan pajak otomatis, pencatatan audit, monitoring transaksi internal.

2.3.2 Validator token (Validator Hook)
Merupakan inti sistem kepatuhan, didaftarkan melalui ERC1820 secara global. Berbeda dari hook pengirim, validator adalah bagian dari kontrak token sendiri.
Contoh aplikasi: verifikasi KYC/AML whitelist, screening sanksi, circuit breaker, pertahanan akuisisi jahat, verifikasi sertifikat off-chain.

2.3.3 Hook penerima (Recipient Hook)
Dipanggil setelah token tiba di alamat penerima, memungkinkan penerima melakukan logika khusus.
Contoh: reinvestasi dividen otomatis, pencatatan otomatis, pendaftaran hak suara otomatis, proses pembelian/redeem ETF.

3. Penjelasan modul kontrak ekstensi

Artikel ini akan membahas detail implementasi dan pilihan teknologi dari modul ekstensi dalam UniversalToken.

3.1 Validator ERC1400Tokens - Mesin kepatuhan
3.1.1 Verifikasi sertifikat
Fitur ini menggabungkan persetujuan off-chain dan eksekusi on-chain. Verifikasi dilakukan di luar chain, hanya hasilnya yang diverifikasi di chain. Mendukung mode Nonce dan Salt.

3.1.2 Manajemen whitelist/blacklist dinamis
Menggunakan RBAC dan OpenZeppelin Role untuk mengelola daftar putih/hitam.

3.1.3 Fitur hold (penguncian dana) bersyarat
Memungkinkan mengunci dana tanpa transfer nyata, melalui state machine dan sistem saldo tiga lapis. Ada enam status berbeda, masing-masing dengan makna dan hak tertentu.

3.1.4 Pengaturan granularitas bagian (Partition)
Dukung pengaturan granularity berbeda untuk setiap bagian, cocok untuk memetakan lot size di pasar tradisional.

3.2 ERC1400TokensChecker - Validator transfer
Memberikan antarmuka query untuk simulasi dan pengecekan kelayakan transfer tanpa biaya gas.

3.3 ERC20HoldableToken - Versi ringan hold
Untuk skenario sederhana, kompatibel ERC20, menambahkan konsep saldo yang dapat digunakan (spendableBalance).

3.4 ERC1400HoldableToken dan ERC1400HoldableCertificateToken - Token modular

• ERC1400HoldableToken: cocok untuk skenario KYC/AML tanpa tanda tangan real-time.
• ERC1400HoldableCertificateToken: cocok untuk pengawasan ketat, transaksi real-time, dan verifikasi sertifikat.

Perbandingan dan panduan pemilihan skenario:

• Fiat digital dan pembayaran.
• Ekuitas private di SPV.
• Sekuritas teratur dan terpantau.

4. Modul manajemen peran

Sistem manajemen peran ERC-1400 tidak datar, melainkan berlapis:

• Pengelola utama (Owner & Controller): pengaturan sistem, parameter, dan pengelolaan regulator.
• Penerbit dan oracle: pengelolaan penerbitan dan harga.
• Operator dan pelaksana transaksi: melakukan transfer rutin dan eksekusi transaksi.
• Pengelola risiko dan kepatuhan: verifikasi identitas, whitelist, blacklist, dan pengelolaan sertifikat.

4.1 Pengelola utama: Owner dan Controller
4.2 Pengelola aset: Minter, PriceOracle, TokenController
4.3 Eksekutor operasional: Operator, TradeExecuter
4.4 Pengelola risiko dan kepatuhan: CertificateSigner, Allowlist/Blocklist Admin, Pauser

5. Modul alat: meningkatkan interoperabilitas dan kegunaan sistem
ERC-1400 tidak hanya standar token, tetapi juga menyediakan ekosistem alat:

• ERC1820: registrasi dinamis layanan.
• EIP-712: tanda tangan terstruktur.
• Tools batch: operasi massal.
• FundIssuer: penerbitan dana secara siklus.
• Swaps: pertukaran atomik dan DVP.

II. RWA berbentuk sekuritas: analisis mendalam ERC-3643 (T-REX)

1. Arsitektur kontrak secara keseluruhan

Dari sudut pandang audit, ERC-3643 dibagi menjadi tiga bagian utama:

• Token: kontrak aset.
• Identity Registry: pendaftaran identitas.
• Compliance: kepatuhan.

Selain itu, menggunakan pola proxy-implementation untuk upgrade, dan dilengkapi dengan factory dan role management.

2. Analisis mendalam kontrak utama ERC-3643

2.1 Rincian struktur data utama
Data ERC-3643 tersebar di berbagai komponen, saling merujuk membentuk jaringan status.

• Pointer kepatuhan di kontrak token.
• Registry di IdentityRegistry.
• Modul compliance di Compliance.

2.2 Analisis modul fungsi utama

• Transfer dan operasi paksa:
  • Proses transfer mengikuti ERC-20, dengan pemeriksaan freeze dan token.
  • Mendukung transfer paksa dan pembatasan.
• Pemeriksaan kepatuhan ganda:
  • Menggunakan registry untuk verifikasi identitas dan kredensial.
• Modular compliance:
  • Mengelola status dan sinkronisasi antar modul.

3. Modul ekstensi kontrak

3.1 Registry system

• TrustedIssuersRegistry: whitelist penerbit.
• ClaimTopicsRegistry: daftar tipe kredensial.

3.2 Modul compliance legacy

• DefaultCompliance dan BasicCompliance.

3.3 Modul manajemen peran

• Owner: pengelola utama.
• Agent: operator harian.
• Role: mengelola mint, burn, forcedTransfer, freeze.

3.4 Modul alat

• Factory: deploy kontrak dengan CREATE2.
• ImplementationAuthority: pengelolaan upgrade.

III. Analisis standar dan skenario vertikal

1. RWA properti: ERC-6065 (Real Estate Token)

Skenario: REITs, pinjaman berbasis properti NFT, platform transaksi lintas negara.

2. IoT dan aset fisik: ERC-4519

Skenario: platform sewa bersama, pelacakan logistik, verifikasi identitas pemilik saat pengangkutan, mobilitas dan pinjaman berbasis NFT.

3. Antarmuka kepatuhan umum: ERC-7943 (uRWA)

Skenario: pool likuiditas DeFi patuh KYC, penerbitan sekuritas teratur, jaringan pembayaran stabil, dan pengawasan anti pencucian uang.

4. Praktik pengkodean aman
Tanpa mengabaikan standar protokol, implementasi kode yang ketat adalah fondasi kepatuhan dan inovasi bisnis.

4.1 Desain izin dan peran: rencanakan “siapa bisa melakukan apa”

• Peran umum: owner, multi-sig governance, admin upgrade, compliance, whitelist, freeze, registry, redeem, oracle, risk, treasury.
• Pengembang: buat matriks peran-izin, gunakan kerangka izin yang jelas, pisahkan tanggung jawab.
• Auditor: identifikasi fungsi risiko tinggi, cocokkan dengan matriks izin.

4.2 State machine dan invariants: tuliskan siklus hidup bisnis di kode

• Definisikan status dan transisi.
• Pastikan invariants selalu terpenuhi.
• Validasi dari dokumen dan kode, hindari shortcut.

4.3 Pemetaan aset dan konsistensi keuangan: jangan sampai chain dan off-chain “berbeda angka”

• Pengembang: buat hubungan aset yang jelas, hindari ambiguitas.
• Auditor: identifikasi variabel yang mewakili apa, pastikan semua perubahan aset punya loop tertutup.
• Risiko: “tidak cocok” atau “sulit dibedakan” bisa menyebabkan kesalahan dan penyalahgunaan.

4.4 Upgrade dan proxy: siapkan jalan keluar dan “ubah aturan”

• Pastikan upgrade granular, lock awal, dan kompatibilitas.
• Risiko: upgrade bisa merusak keamanan, periksa siapa yang punya hak upgrade, proses transparan, dan ada backdoor.

4.5 Event dan log: bukti untuk masa depan dan regulator

• Setiap operasi penting harus memicu event: mint, burn, transfer, freeze, whitelist, blacklist, redeem, upgrade, parameter change, role change.
• Audit: pastikan event lengkap, field cukup, tidak bisa disembunyikan, dan sesuai kebutuhan bisnis.

5. Daftar audit dan pengungkapan keamanan RWA

I. Checklist audit

Ringkasan poin utama dari analisis teknis, untuk audit lengkap kontrak RWA.

1. Identifikasi arsitektur dan ruang lingkup awal

• Peran aset dan regulasi.
• Sumber keaslian.
• Kontrol izin.

2. Audit keamanan dan integritas aritmatika

• Overflows, presisi.
• Reentrancy.
• Risiko panggilan eksternal.
• Inisialisasi dan storage.

3. Verifikasi identitas dan kepatuhan

• Hook lengkap.
• Registry dan privasi.
• Logika whitelist/blacklist.

4. Manajemen siklus hidup aset

• Penerbitan dan minting.
• Penebusan.
• Operasi paksa.

5. Operasi dan tata kelola

• Peran dan izin.
• Pause darurat.
• Log event.

6. Transaksi dan integrasi off-chain

• Oracle dan penilaian.
• DVP / swaps.
• Tanda tangan.
• Batch.

7. Dokumentasi dan data

• Keamanan dokumen.
• Identifikasi aset.

8. Spesifik standar dan skenario

• ERC-1400 / 3643: sekuritas.
• ERC-6065 / 1155: properti.
• ERC-4519: IoT / fisik.
• ERC-6960: aset terstruktur.
• ERC-7943: interface umum.

II. Tabel checklist audit lengkap

Metode otomatis, AI, dan review manual.

III. Form pelaporan tambahan

Untuk memenuhi regulasi dan kontinuitas bisnis, berdasarkan pengalaman audit dan regulasi.

Penutup: Membangun jembatan keamanan antara kode dan dunia nyata

Dalam praktik audit, auditor harus tidak hanya memverifikasi kode sesuai standar EIP, tetapi juga berasumsi sebagai penyerang yang mencoba melewati whitelist KYC, manipulasi oracle, atau menyusup melalui celah hak admin. Hanya dengan pemodelan logika bisnis mendalam dan pemeriksaan risiko seumur hidup, kita bisa mengungkap jebakan teknis tersembunyi di balik proses kepatuhan.

Untuk meningkatkan kedalaman dan efisiensi pertahanan, tim keamanan menyarankan sistem perlindungan lengkap yang menggabungkan kolaborasi manusia dan mesin:

• Bantuan AI mendalam: gunakan alat audit MistAgent AI, yang memanfaatkan basis pengetahuan dari kasus nyata, mampu mengenali pola risiko kompleks dan kerentanan khusus RWA.
• Monitoring dan intelijen 24/7: setelah deployment di mainnet, integrasikan MistEye untuk pemantauan real-time dan peringatan ancaman, mendeteksi perubahan izin, transaksi besar, atau anomaly oracle, sehingga melengkapi audit statis dengan pengawasan aktif.

RWA adalah bentuk digitalisasi kepercayaan. Dengan daftar periksa yang ketat, alat AI mutakhir, dan pengawasan berkelanjutan, kita dapat membangun fondasi keamanan yang kokoh untuk proses on-chain aset dunia nyata.