Guard Signer

Guard Signer gives protected Funding Account actions multisig protection by default.

A user wallet still submits the on-chain transaction. Guard Signer adds a second signature from a Polyester-managed signer after the user passes account security checks.

A stolen wallet is not enough

Protected whitelist changes need both the user's on-chain authority and a Guard Signer approval. An attacker with only the user's wallet cannot add a new destination or disable whitelist protection.

Why it matters

Whitelists are only useful if changing the whitelist is harder than using it.

Without Guard Signer, an attacker who steals a user's wallet could try to modify the whitelist directly on-chain, then move funds to a destination they control. Guard Signer blocks that path. The protected contract call requires an approval from the Polyester-managed guard signer, and Polyester only issues that approval after checking the authenticated account, policy, and required step-up.

Compromise	What Guard Signer changes
Stolen wallet only	The attacker can attempt an on-chain transaction, but cannot produce the Guard Signer approval.
Stolen session only	The attacker can reach the website session, but cannot complete the user's on-chain transaction.
Stolen wallet and session	The attacker still faces fresh MFA and policy checks before Polyester issues an approval.

This is the practical benefit: whitelist edits become a two-party action. The user's wallet starts the change. Polyester's guard signer approves only the exact protected action after account-level security checks pass.

This also makes whitelists more useful. Once whitelist protection is enabled, an attacker cannot simply steal one credential and change the trusted destinations. They must clear the same layered checks that protect the account.

What Guard Signer protects

Guard Signer is used for actions that change which destinations are trusted for future transfers.

Protected action	Purpose
Add external whitelist destinations	Trust external withdrawal addresses for a Funding Account
Remove external whitelist destinations	Remove trusted external withdrawal addresses
Add internal whitelist destinations	Trust internal transfer recipients
Remove internal whitelist destinations	Remove trusted internal transfer recipients
Disable external whitelist requirement	Relax the external withdrawal whitelist requirement
Disable internal whitelist requirement	Relax the internal transfer whitelist requirement

Enabling a stricter whitelist requirement does not need a Guard Signer approval. Relaxing a requirement does.

Approval model

The client sends the business action. Polyester derives the approval details.

Field	Source
Target account	Authenticated session or API key, plus optional subaccount selector
Fresh MFA step-up	Required for high-risk interactive whitelist changes
Smart wallet address	Polyester account state
Target contract	Protected action configuration
Function selector	Protected action configuration
Parameters hash	Derived from the requested business arguments
Nonce and nonce space	Current on-chain Guard Registry state
Deadline	Derived by Polyester

This keeps the frontend from supplying security-critical fields such as nonce, deadline, target contract, selector, or params hash.

Typical flow

Create or reuse a guard signer wallet for the target account.
Read Guard Signer status.
If the signer is not initialized, submit the signer initialization transaction on-chain.
Poll status until the stored signer and on-chain signer match.

Client responsibilities

Clients send only the business inputs for the protected action.

Do send:

the protected action identifier
the action-specific arguments
optional subaccount selector when targeting a subaccount

Do not send:

root account ID
internal account ID
smart wallet address as trusted identity
nonce
nonce space
deadline
target contract
function selector
params hash

Account identity comes from authentication

Polyester resolves the root account from the authenticated request. A client-supplied account field is not trusted as authority.

Approval payload

The API returns a GuardApproval payload.

Guard Signer does not submit the transaction

The Guard Signer API returns an approval payload. The client still submits the matching contract call with the user's wallet or smart wallet.

Field	Description
`nonce_space`	Nonce lane used for the signed approval. Normal flows use `0`.
`deadline_unix`	Unix timestamp in seconds after which the approval expires.
`signature`	EIP-712 signature over the Guard Registry approval message.

The approval must be submitted with the exact protected action it was created for. Changing the destination list, action, target contract, or encoded arguments invalidates the approval.

External and internal whitelist arguments

External whitelist updates use destination payload bytes for the target external chain.

For EVM destinations, pass the same normalized destination bytes used by withdrawal requests. In practice, this means lowercasing the 0x... address and encoding that string as bytes.

Internal whitelist updates use EVM account addresses.

Whitelist type	Argument shape
External whitelist	`polychain_chain_id` plus `0x`-prefixed destination payload bytes
Internal whitelist	EVM account addresses such as `0xabc...`

Relationship to MFA and transfer security

Guard Signer protects whitelist and account-control changes in the same security stack used for transfers and withdrawals.

Control	Role
Session or API-key auth	Identifies the caller
Account policy	Checks whether the caller can perform the action
MFA step-up	Confirms high-risk interactive actions
Wallet-signed intent	Binds a user to an exact transfer or withdrawal request
Guard Signer approval	Adds the second signature for whitelist and account-control changes

See Withdrawals and Transfers Security for the transfer authorization model.

Operational notes

Guard Signer approvals are short-lived.
Approvals are bound to the account, target, selector, parameter hash, nonce, and deadline.
Batch approval responses preserve request order. Submit each approval with the matching batched action.
Exporting guard signer key material is a high-risk action and requires explicit authorization.

Guard Signer keeps protected account-control changes explicit. The user still controls the final on-chain submission.