Stripe dan Paradigm bersama-sama mengembangkan blockchain Layer 1 Tempo, yang pada 31 Mei mengajukan proposal TIP-1061 native multisig accounts. Rencananya, multisig akan diperkenalkan sebagai tipe akun utama di layer protokol jaringan, tanpa perlu melakukan deploy Safe atau smart contract wallet lain untuk mewujudkan kontrol multisig. TIP-1061 terutama ditujukan untuk skenario penggunaan seperti DAO, institusi, dan validator nodes, dan masih berada pada tahap rancangan.
Spesifikasi Teknis yang Telah Dikonfirmasi
Desain inti TIP-1061 mencakup rincian teknis berikut yang telah dikonfirmasi. Alamat multisig account diturunkan dari hashing konfigurasi awal (config_id); ketika daftar anggota, bobot tanda tangan, atau ambang batas diubah di kemudian hari, alamat akun tetap tidak berubah.
Didukungnya terdapat tiga jenis tanda tangan: Secp256k1, P256, dan WebAuthn. Mendukung M-of-N plane multisig (setiap pemilik weight=1) dan weighted multisig (otorisasi asimetris), misalnya pemilik dengan bobot tinggi (weight=100) bisa mengotorisasi secara mandiri, atau dua pemilik dengan bobot menengah (masing-masing weight=50) mengotorisasi bersama. Setiap multisig account maksimal mengizinkan 10 pemilik (MAX_MULTISIG_OWNERS=10).
Batasan Desain: Tidak Mendukung AccountKeychain dan EIP-7702
TIP-1061 secara tegas menetapkan bahwa native multisig account tidak mendukung akses kunci melalui AccountKeychain; jika msg.sender adalah native multisig account, pemanggil modifier AccountKeychain harus ditolak. Alasan desain yang diajukan adalah: memungkinkan satu kunci otorisasi untuk melakukan pemanggilan sebagai parent account akan mengubah sebuah private key asli menjadi kemampuan permanen untuk bertindak sebagai alamat multisig dalam ruang lingkup otorisasi apa pun, yang tidak sesuai dengan prinsip desain “identitas dengan kontrol jumlah legal”.
Selain itu, native multisig account setelah proses Bootstrap tidak boleh menginstal bytecode EVM atau kode delegasi EIP-7702.
Status Rancangan: Hal yang Masih Harus Dipastikan
Proposal saat ini masih berupa rancangan; skema penghitungan gas (dokumen menandai sebagai “to-do”) dan alamat kontrak multisig yang akan dikompilasi sebelumnya (akan dialokasikan sebelum proposal keluar dari status rancangan) juga belum diputuskan secara final. Proposal menetapkan bahwa sebelum TIP-1061 mulai berlaku, semua transaksi yang memuat TempoSignature::Multisig harus ditolak; semua transaksi yang membawa field multisig_init juga harus ditolak sebelum proposal mulai berjalan.
FAQ
Apa perbedaan mendasar antara native multisig TIP-1061 dan contract wallet seperti Safe?
TIP-1061 mengangkat verifikasi multisig ke layer protokol, sehingga kemampuan kontrol ambang batas yang sama dapat dicapai tanpa perlu deploy contract wallet seperti Safe di rantai. Ini menghilangkan biaya deploy kontrak, dan alamat akun tetap stabil setelah diturunkan dari konfigurasi awal, tidak berubah mengikuti pembaruan anggota.
Mengapa alamat multisig account dapat tetap tidak berubah setelah pembaruan anggota?
Alamat multisig account diturunkan dari hashing config_id, dan config_id dihitung berdasarkan himpunan pemilik awal (termasuk alamat, jenis tanda tangan, dan bobot) serta ambang batas. Selama akun masih ada, nilainya tidak akan berubah. Pemanggilan updateMultisigConfig setelahnya hanya memperbarui konfigurasi yang tersimpan saat ini, tanpa mengubah config_id itu sendiri maupun alamat akun turunan.
Apa skenario penggunaan target utama TIP-1061?
Di bagian motivasi, proposal secara jelas menyebutkan skenario targetnya adalah pengguna yang membutuhkan “tidak ada satu pun private key yang dapat memindahkan dana atau mengubah konfigurasi operasi secara sepihak”. Secara spesifik mencakup tim (Teams), departemen keuangan (Treasury), validator nodes, dan operator institusional (Institutional Operators).
