---
title: "Rotasi penandatangan multisig"
description: "Prosedur yang mengutamakan verifikasi untuk mengganti penandatangan multisig sambil mempertahankan kuorum, memeriksa kumpulan pemilik dan ambang on-chain yang tepat, serta merespons kunci yang disusupi dengan aman."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Rotasi penandatangan multisig

> Hanya untuk tujuan edukasi; bukan nasihat investasi, hukum, atau keamanan. Kesalahan rotasi dapat memindahkan kendali, membatalkan persetujuan tertunda, atau mengunci akun multisig secara permanen.

<a id="answer"></a>

## Jawaban langsung

Rotasi penandatangan multisig mengubah akun yang berwenang menyetujui transaksi. Biasanya proses ini tidak memerlukan alamat dompet baru atau pemindahan aset: transaksi berhak istimewa mengubah kumpulan pemilik akun dan terkadang ambang persetujuannya. Setiap implementasi berbeda, jadi verifikasi kontrak yang digunakan dan status on-chain saat ini alih-alih menganggap label antarmuka menjelaskan kewenangan secara akurat.

Rotasi yang aman terlebih dahulu membuktikan kendali atas setiap penandatangan baru, mempertahankan kuorum yang dapat mengeksekusi tetapi tidak terpusat selama perubahan, menghapus penandatangan lama, lalu memverifikasi status akhir on-chain. Kehilangan kuorum yang diperlukan sebelum eksekusi dapat membuat rotasi pemilik biasa mustahil dilakukan; menurunkan ambang demi kemudahan dapat membuka jendela pengambilalihan.

Orang, perangkat penandatangan, kunci pribadi, dan alamat pemilik on-chain adalah catatan yang terpisah. Dokumentasikan alamat yang tepat, kustodian, domain kendali independen, status cadangan, dan alasan rotasi. Rotasi yang sah tidak pernah mengharuskan siapa pun mengungkap frasa seed atau kunci pribadi.

<a id="mechanism"></a>

## Cara kerjanya

1. **Inventarisasi kewenangan saat ini.** Dari chain dan alamat akun yang diverifikasi secara independen, baca implementasi yang digunakan, daftar pemilik, ambang, nonce, modul aktif, guard, fallback handler, jalur pemulihan, dan setiap timelock. Modul atau mekanisme pemulihan dapat mengeksekusi di luar ambang pemilik biasa, sementara guard yang ketat dapat memblokir rotasi yang sebenarnya valid.
2. **Tentukan status tujuan sebelum menandatangani.** Catat kumpulan pemilik dan ambang yang tepat setelah perubahan. Pastikan ambang tidak melebihi jumlah pemilik dan setidaknya sebanyak itu penandatangan independen akan tetap beroperasi. Pemisahan geografis bukan kemandirian jika satu orang, brankas kata sandi, akun cloud, atau administrator mengendalikan semua perangkat.
3. **Daftarkan dan autentikasi penandatangan baru.** Buat atau pulihkan kunci baru di lingkungan kustodi yang dimaksud, verifikasi alamat pada perangkat tepercaya, dan buktikan kendali melalui tantangan yang disepakati atau tanda tangan uji. Konfirmasikan alamat melalui saluran terautentikasi kedua; jangan hanya mengandalkan teks obrolan yang disalin atau antarmuka dompet.
4. **Pilih urutan dengan status perantara yang aman.** Beberapa kontrak dapat mengganti satu pemilik secara atomik. Safe, misalnya, menyediakan `swapOwner`; Safe juga menyediakan `addOwnerWithThreshold`, `removeOwner`, dan `changeThreshold`. Jika sebuah implementasi memerlukan beberapa transaksi, analisis kumpulan pemilik dan ambang setelah setiap tahap. Tambah dan verifikasi kapasitas sebelum menghapusnya, kecuali kompromi aktif membuat urutan itu tidak aman.
5. **Dekode dan simulasikan transaksi yang tepat.** Periksa secara independen chain ID, alamat akun, target, pemilih fungsi, alamat pemilik lama dan baru, ambang hasil, nonce, value, dan jenis operasi. Perlakukan `delegatecall`, batching, perubahan modul, dan perubahan guard sebagai efek berisiko tinggi yang terpisah. Setiap penandatangan harus menyetujui payload yang telah didekode dan hash transaksi yang sama.
6. **Eksekusi dengan kewenangan yang ada.** Kuorum valid saat ini mengesahkan rotasi kecuali jalur pemulihan terdokumentasi menyatakan sebaliknya. Dalam keadaan darurat, koordinasikan hanya melalui kontak terautentikasi dan gunakan penandatangan yang tidak disusupi. Jika kuorum normal maupun kewenangan pemulihan yang dikonfigurasi sebelumnya tidak tersedia, panggilan pengelolaan pemilik standar tidak dapat memulihkan akses.
7. **Verifikasi dan tutup perubahan.** Setelah konfirmasi, tanyakan langsung kumpulan pemilik dan ambang, periksa peristiwa atau trace yang dipancarkan sesuai implementasi, dan pastikan alamat lama tidak lagi berwenang. Libatkan penandatangan baru dalam transaksi rendah risiko atau bernilai nol yang telah disetujui dan membutuhkan ambang yang dimaksud. Tinjau transaksi tertunda, cabut akses off-chain dan cadangan milik penandatangan lama, serta arsipkan proposal, tanda tangan, hash transaksi, blok, dan status akhir.

<a id="example"></a>

## Contoh terperinci

Anggap akun `3-of-5` memiliki pemilik `A`, `B`, `C`, `D`, dan `E`, lalu `B` harus diganti oleh `F`. Tim terlebih dahulu memastikan `F` mengendalikan alamat yang tepat seperti diusulkan dan tetap independen dari pemilik lain. Untuk deployment Safe yang kompatibel, tim menyiapkan `swapOwner(prevOwner, B, F)`. Panggilan itu sendiri merupakan transaksi Safe sehingga membutuhkan `3` konfirmasi valid dari kumpulan pemilik saat ini. Hasil yang didekode harus mempertahankan jumlah pemilik `5` dan ambang `3`.

Setelah transaksi dikonfirmasi, tim membaca `getOwners` dan `getThreshold`, memastikan `B` tidak ada dan `F` ada, lalu meminta `F` bersama dua pemilik lain menjalankan pengujian bernilai `0` yang telah disetujui. Tim juga meninjau transaksi tertunda: tanda tangan atau persetujuan awal dari `B` mungkin tidak lagi memenuhi pemeriksaan pemilik setelah penghapusan, jadi proposal yang terpengaruh harus dibatalkan atau dibuat ulang, bukan dianggap tetap dapat dieksekusi.

Jika `B` mungkin telah disusupi, tim tidak meminta penandatangan tersebut menyetujui penghapusannya. Tiga pemilik lain yang tidak disusupi menjalankan penggantian, lalu memeriksa modul, izin pemulihan, allowance, session key, dan transaksi yang sudah dieksekusi, karena menghapus `B` tidak membalikkan tindakan sebelumnya atau mencabut kewenangan yang diberikan melalui jalur lain. Jika tersedia kurang dari `3` pemilik yang tidak disusupi, hanya jalur pemulihan atau administratif yang telah dikonfigurasi sebelumnya yang mungkin membantu; berbagi frasa seed atau memercayai layanan "pemulihan" yang tidak diminta bukan pengganti kuorum.

<a id="risks"></a>

## Risiko dan kontrol

- **Akun atau alamat yang salah.** Verifikasi chain ID, alamat multisig, implementasi, dan alamat pemilik baru pada perangkat dan sumber independen. Address poisoning dan kesalahan penyalinan dapat memberikan kendali kepada penyerang.
- **Kehilangan kuorum.** Modelkan setiap status perantara. Menghapus pemilik terlalu awal, menaikkan ambang di atas penandatangan yang tersedia, atau merotasi beberapa perangkat berkorelasi sekaligus dapat membuat akun tidak dapat digunakan.
- **Pemusatan sementara.** Ambang yang lebih rendah atau penandatangan yang baru ditambahkan dapat menciptakan periode ketika lebih sedikit pihak mengendalikan akun. Utamakan penggantian atomik jika didukung dan jangan turunkan ambang hanya untuk menyederhanakan prosedur.
- **Kustodi berkorelasi.** Alamat berbeda tidak independen jika seed, perangkat, cadangan, komunikasi, atau administratornya berbagi satu domain kegagalan. Uji pemulihan tanpa memusatkan rahasia.
- **Kewenangan tersembunyi.** Modul, guard, fallback handler, session key, timelock, dan kontrak pemulihan dapat melewati atau memblokir jalur pemilik. Inventarisasi dan verifikasi sebelum dan sesudah rotasi.
- **Perlombaan dengan penandatangan yang disusupi.** Sebelum penghapusan dikonfirmasi, penandatangan yang dicurigai dapat mendahului, menguras aset, mengubah konfigurasi, atau menyetujui transaksi lain. Gunakan prosedur insiden, pengiriman transaksi privat bila sesuai, dan pemantauan status berkelanjutan; jangan menganggap transaksi yang dikirim telah memenangkan perlombaan.
- **Persetujuan tertunda yang usang.** Perubahan pemilik dan ambang dapat membatalkan tanda tangan yang dikumpulkan atau mengubah persetujuan mana yang mencukupi. Evaluasi ulang setiap transaksi antrean terhadap status akhir dan batalkan proposal yang usang.
- **Penyelesaian palsu.** Notifikasi berhasil pada antarmuka tidak membuktikan status yang dimaksud. Tunggu kebijakan konfirmasi yang diwajibkan, lalu baca status kontrak dan verifikasi payload transaksi, peristiwa, serta hasil eksekusi.
- **Pencabutan akses tidak lengkap.** Menghapus pemilik on-chain tidak menghapus kunci yang disalin, akses organisasi, kredensial relayer, entri brankas kata sandi, atau kewenangan pada kontrak dan chain lain. Cabut masing-masing secara terpisah dan simpan jejak audit.

<a id="misconceptions"></a>

## Kesalahpahaman umum

- **"Rotasi berarti memindahkan semua aset ke dompet baru."** Banyak multisig smart account memperbarui pemilik pada alamat akun yang sama. Migrasi adalah operasi berbeda dan mungkin hanya diperlukan oleh implementasi atau rencana insiden tertentu.
- **"Menambahkan penandatangan baru lebih dulu selalu aman."** Hal itu melindungi ketersediaan, tetapi dapat memperluas kumpulan berwenang untuk sementara. Saat kompromi aktif berlangsung, penggantian atomik atau urutan darurat lain mungkin lebih aman.
- **"Ambang `3-of-5` berarti tiga orang mana pun yang disebutkan tersedia."** Kontrak menghitung akun pemilik yang valid, bukan orang, departemen, atau perangkat. Kustodi bersama dan kunci yang tidak dapat diakses mengurangi kemandirian dan ketersediaan efektif.
- **"Menghapus pemilik yang disusupi membatalkan kerusakan."** Setelah dikonfirmasi, penghapusan mencegah penggunaan jalur pemilik itu di masa depan; penghapusan tidak membalikkan transaksi yang sudah dieksekusi atau mencabut izin yang dibuat di tempat lain.
- **"Antarmuka dompet merupakan bukti yang cukup."** Antarmuka dan layanan pengindeksan dapat kedaluwarsa, salah konfigurasi, atau berbahaya. Dekode transaksi dan baca status akhir kontrak dari endpoint yang diverifikasi secara independen.
- **"Tanpa kuorum, dukungan pelanggan dapat mengatur ulang dompet."** Multisig kustodi mandiri hanya memiliki jalur kewenangan yang dikodekan atau dikonfigurasi sebelumnya on-chain. Tanpa kuorum valid atau jalur pemulihan, akses dapat hilang secara permanen.

<a id="related"></a>

## Topik terkait

- [Dompet perangkat keras](/id/crypto/hardware-wallet/)
- [Dompet multisig](/id/crypto/multisig-wallet/)
- [Pengelolaan kunci pribadi](/id/crypto/private-key-management/)
- [Risiko pemulihan pemilik smart account](/id/crypto/smart-account-owner-recovery-risk/)
- [Simulasi transaksi](/id/crypto/transaction-simulation/)

<a id="sources"></a>

## Sumber

- [Bagaimana Safe Smart Account bekerja?](https://docs.safe.global/advanced/smart-account-overview) - Safe Documentation (diakses: 2026-08-21)
- [addOwnerWithThreshold](https://docs.safe.global/reference-smart-account/owners/addOwnerWithThreshold) - Safe Documentation (diakses: 2026-08-21)
- [removeOwner](https://docs.safe.global/reference-smart-account/owners/removeOwner) - Safe Documentation (diakses: 2026-08-21)
- [swapOwner](https://docs.safe.global/reference-smart-account/owners/swapOwner) - Safe Documentation (diakses: 2026-08-21)
- [changeThreshold](https://docs.safe.global/reference-smart-account/owners/changeThreshold) - Safe Documentation (diakses: 2026-08-21)
- [OwnerManager.sol](https://github.com/safe-fndn/safe-smart-account/blob/main/contracts/base/OwnerManager.sol) - Safe Ecosystem Foundation (diakses: 2026-08-21)
- [Rekomendasi Pengelolaan Kunci: Bagian 1 - Umum](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final) - NIST (diakses: 2026-08-21)

Source: https://wiki.fcontext.com/id/crypto/multisig-signer-rotation/index.mdx