When a transaction is created in a Utila vault, two separate questions decide how it gets signed:
Who is permitted to sign this transaction?
Who should sign this specific transaction?
The first is answered by allowed signers, the second by designated signers. They are stored independently on the transaction and serve different purposes. Allowed signers control permission. Designated signers control notification and routing. Keeping them separate is what lets you enforce segregation of duties in policy while still directing a given transaction to the right signer.
Allowed signers
Allowed signers are determined by your vault's transaction policy. Every transaction is evaluated against your policy rules in priority order, and the first matching rule defines who is allowed to sign:
Initiator: only the user who created the transaction can sign it.
Approver: only the approvers named in the rule can sign it.
Specific signers: only the members named in the rule can sign it.
Any vault signer: the rule sets no signer restriction, so any vault member with a signing role (Owner, Admin, or Signer) can sign.
Allowed signers are a hard permission boundary. A user who is not in the allowed set cannot sign the transaction, regardless of their vault role and regardless of whether they were designated. This is the mechanism behind segregation of duties: you can require that the person who initiates a transaction is not the person who signs it.
If you want to control who can sign, configure your transaction policy rules.
Designated signers
Designated signers are set by the initiator when the transaction is created, most commonly via API . They express who is expected to sign, and they drive two things:
Notifications: designated signers receive the mobile push notification that a transaction is awaiting signature. This alerts the right people without adding noise for every other vault member.
Co-signer routing: the co-signer only picks up transactions that designate its service account. This keeps a service account from signing transactions it was never meant to handle.
Designating a signer does not grant or restrict permission to sign. It is purely a routing and notification hint. Members who are not designated can still sign the transaction, as long as your policy's allowed signers permit them. They simply do not receive a notification for it. And if a designated signer is not in the allowed set, the designation has no practical effect: that user is not notified and cannot sign, while the allowed signers can still sign normally.
If you want to control who should sign a specific transaction, set designated signers when you initiate it.
The difference at a glance
| Allowed signers | Designated signers |
Set by | Your vault's transaction policy | The transaction initiator |
Controls | Who is permitted to sign | Who is notified, and co-signer routing |
Effect on signing | Hard boundary: only allowed signers can sign | None: routing and notification only |
Typical use | Segregation of duties, approval requirements | Alerting a specific signer, routing to an co-signer |
A simple way to remember it: allowed signers answer "who is allowed to sign," designated signers answer "who should sign this one."
How they work together
The two fields are evaluated independently at each stage of signing.
Signing permission. When a user attempts to sign, the only check is the policy's allowed signers. If allowed signers are set, the user must be in the list. Designated signers play no part in this check, so a member who is allowed by policy can always sign, even if the transaction was designated to someone else.
Notifications. Targeting follows a simple order:
If designated signers are set, the notification goes to the designated signers who are also allowed to sign.
If no designated signers are set but allowed signers are, the allowed signers are notified.
If neither is set, all eligible vault members are notified.
Co-signer pickup. The co-signer only acts on a transaction that is awaiting signature and designates its service account. If the policy restricts signers, the co-signer must also be in the allowed set. Transactions with no designated signer are never picked up by the co-signer, even when policy would permit it to sign.
Examples
Example 1: Segregation of duties. Your payout rule requires signing by your Finance approver group. Anyone on the team can initiate a payout, but only Finance members are allowed signers, so an initiator can never sign their own transaction. Here, permission lives entirely in policy, and you may not need to set designated signers at all.
Example 2: Route to an co-signer. Your backend initiates payouts that should be signed automatically. Your policy allows the co-signer's service account to sign, and each transaction designates that service account. The co-signer picks up only those transactions and signs them, and no human is notified.