Model kepatuhan

Bloom menjalankan framework Arc milik Plume tanpa modifikasi. Kepatuhan adalah ditegakkan oleh kontrak token itu sendiri — bukan oleh pemfilteran off-chain, filter sequencer, atau kebijakan venue apa pun. Itulah sifat yang membuatnya portabel: aturan ikut bersama token ke jalur eksekusi apa pun, di kedua jalur dompet.

Arsitektur penegakan

ArcToken._update (setiap transfer/mint/burn)
   └─ RestrictionsRouter (satu per chain, registri tipe modul)
        ├─ TRANSFER_RESTRICTION → WhitelistRestrictions (per token)
        ├─ YIELD_RESTRICTION    → YieldBlacklistRestrictions (per token)
        └─ GLOBAL_SANCTIONS     → (slot tersedia; belum ada modul global yang diterapkan)

• WhitelistRestrictions — allowlist. Selama transfersAllowed bernilai false (mode gated), transfer yang salah satu sisinya tidak ada di daftar akan revert dengan error bertipe TransferRestricted() (0xe827105e). Pemeriksaan ini berjalan di dalam token pada setiap perpindahan saldo — transfer dompet EVM, transfer bertanda tangan Solana, penjualan storefront, dan perpindahan likuiditas awal semuanya melewati gerbang yang sama. Tidak ada jalan memutar kecuali melalui kekuasaan admin milik penerbit sendiri.

• YieldBlacklistRestrictions — mengecualikan alamat dari distribusi yield; porsi pro-rata mereka tetap berada di kontrak token.

• GLOBAL_SANCTIONS — router mendukung modul seluruh-chain yang diterapkan ke setiap token (misalnya daftar sanksi). Saat ini belum ada yang diterapkan; slot ini adalah tempat alami untuk modul yang dioperasikan di tingkat chain.

Model kepercayaan, dinyatakan secara jujur

Flag allowlist adalah keputusan off-chain dari penerbit. KYC/AML terjadi dalam proses penerbit (vendor mereka, aturan mereka); chain mencatat dan menegakkan hasil — isWhitelisted(addr). Pendaftaran dan peninjauan adalah mekanisme di sekitar keputusan itu — bagaimana investor mengajukan, bagaimana penerbit memutuskan, dan jejak audit yang ditinggalkannya — dan hal itu tidak mengubah model ini: tetap keputusan penerbit, tetap hanya boolean on-chain, dan tidak ada dokumen di mana pun. Ini adalah model Arc framework sendiri sebagaimana digunakan di Plume. Ini sengaja bukan sistem identitas on-chain: tidak ada klaim identitas, tidak ada pernyataan on-chain, tidak ada bukti kriptografis tentang kepemilikan alamat. Standar yang membawa identitas on-chain yang dapat diverifikasi (misalnya ERC-3643) menukar transfer yang jauh lebih berat demi sifat itu; Arc menukar mekanisme yang lebih ringan untuk kepercayaan yang dipegang penerbit. Bloom menampilkannya secara jujur alih-alih menyiratkan lebih dari itu.

Kekuasaan penerbit (berbentuk agen transfer)

ArcToken.initialize memberikan setiap peran kepada penggerak wizard:

Peran	Kewenangan
ADMIN_ROLE / DEFAULT_ADMIN_ROLE	tautkan/ganti modul pembatasan, kelola peran
MINTER_ROLE / BURNER_ROLE	pengelolaan pasokan
YIELD_MANAGER_ROLE / YIELD_DISTRIBUTOR_ROLE	tetapkan token yield, jalankan distribusi
UPGRADER_ROLE	lakukan upgrade token via UUPS (dipegang penerbit; berikan ke factory untuk upgrade yang dimediasi factory)
Modul whitelist WHITELIST_ADMIN_ROLE	tambah/hapus alamat, aktif/nonaktifkan mode gated

Konsekuensi yang perlu diketahui: sebuah dompet investor yang hilang hanya dapat dipulihkan melalui tindakan penerbit (whitelist alamat pengganti dan, jika perlu, gunakan kewenangan mint/burn/upgrade sesuai proses hukum mereka — Arc tidak memiliki primitif forced-transfer bawaan). Karena itu, penjagaan kunci oleh penerbit adalah bagian dari postur kepatuhan; penampil peran di aplikasi membuat pemegang setiap kewenangan terlihat.

Apa yang ditambahkan Rome — dan apa yang dipertahankan registerToken

Pengguna dompet Solana muncul sebagai alamat EVM sintetis (diturunkan dari public key Solana mereka). Bagi lapisan kepatuhan, mereka adalah alamat biasa: penerbit memasukkan mereka ke whitelist, gerbang memeriksa mereka, yield mencapai mereka — satu allowlist mencakup kedua dunia dompet. Implikasi kustodi ada di LANES.md.

Karena Rome membatasi jumlah akun per transaksi, token diterapkan secara bertahap dan memperoleh status factory melalui ArcTokenFactoryV2.registerToken alih-alih sekali jalan createTokenpemanggil harus memegang token ADMIN_ROLE, dan pendaftaran hanya sekali. Tidak ada yang melemahkan permukaan kepatuhan melalui jalur bertahap ini.