Choose ECDSA for server wallets, agents, existing wallet clients, or any integration that already produces Ethereum signatures. You are responsible for securing and recovering the key.
Initialize the SDK and a viem secp256k1 account once for either VM:
Use the signer as the account owner:
Follow account configuration for deployment and restoration. For remote signing requirements, see Custom signing.
Never expose a private key in client code, logs, or source control. Use a key management system for production server signers.
Use more than one owner
For EVM, use multisig when several ECDSA owners should control one account. Use multi-factor authentication when you need different validator types, such as ECDSA and passkeys.
Manage EVM owners
Use the SDK actions to change an account after deployment:
Manage Solana authorities
An authorized all or manageAuthority role can add or remove one non-root key per transaction. Continue the Solana setup above with a separate local account additionalOwner (or pass its secp256k1 public key, never its EVM address):
Choose permissions explicitly:
allButManageAuthority: spend and run instructions, but not change authorities.
all: spend, run instructions, and manage non-root authorities.
manageAuthority: manage non-root authorities, but not spend or run instructions. It can grant all to another key, so it still confers takeover power.
Send one change through the shared transaction lifecycle. Authority changes are always sponsored, including rent for a new role; do not add source or sponsored fields. Settle any previous submission before retrying. getAuthorityStatus(addAuthority) returns applied only for the exact requested permission; conflict is not ready.
The root is permanent. Removing the root, a missing key, or the last authority-management role is refused. Multiple roles are not threshold multisig or MFA. Keep local signer configuration synchronized with the roles onchain; see Solana support.