This guide walks you through your first login to Wallet-as-a-Service (Palisade) and the key decisions you need to make before inviting your team.
Make sure you have:
- An invitation email from Palisade
- A mobile device with an authenticator app (for example, Google Authenticator or Authy) for two-factor authentication (2FA)
Check your spam folder. If you still can't find the email, contact support@palisade.co.
- Open the invitation email from Palisade.
- Select the activation link.
- Set your password and configure two-factor authentication (2FA).
- Go to the Palisade console URL provided during onboarding.
- On the Enter Your Organization page, enter your organization name, then select Continue.
- Enter your email address and password, then select Continue.
- Enter the 2FA code from your authenticator app, then select Continue.
For details on authentication methods including single sign-on, see Create your organization.
After you sign in, the console displays the following main sections in the sidebar:
- Home — View a summary of your organization's activity, including asset totals, vault and wallet counts, address book entries, and pending notifications.
- Vaults — Create and manage vaults and the wallets within them.
- Controls — Configure approval groups (tab: Approval groups) and MPC quorums (tab: MPC Quorums).
- Devices — Add and manage mobile and CloudSign devices for MPC signing (tabs: Internal, External).
- Connections — Open WalletConnect connections to external dapps.
- Address book — Manage counterparties and their blockchain addresses (tabs: Counterparties, Addresses).
- Notifications — View pending approval requests.
- Settings — Access organization management including User management, API credentials, Webhooks, Backup & Recovery, Workflows (sweeps), and Audit logs.
A new organization has no vaults, wallets, devices, or policies configured. Use this guide and the recommended setup order to build out each component.
Before you invite users or create wallets, decide on these key areas:
Palisade supports two authentication methods: username and password (the default) and single sign-on (SSO) with a third-party identity provider.
Palisade locks the authentication method for each user when you send the invitation, and you can't change it afterward. If your organization uses SSO, configure it before sending any invitations. See Configure single sign-on.
Decide which roles your team members need. Palisade provides six roles:
| Role | Purpose |
|---|---|
| Owner | Full access to all features and settings, including organization-level configuration. |
| Administrator | Full access to all features and settings. Cannot change organization-level settings. |
| Proposer | Can manage wallets and initiate transactions. |
| Approver | Can review and approve transactions and other pending actions. |
| Viewer | Read-only access to wallets, transactions, and reports. |
| Auditor | Read-only audit access to organization activity and configurations. |
At minimum, most organizations need:
- At least 2 owners or administrators for redundancy
- At least 1 proposer to initiate transactions
- At least 2 approvers for multi-party approval
Plan how you want to distribute MPC key shards across devices. Consider:
- How many devices hold key shards (more devices = higher resilience)
- How many devices must sign each transaction (higher threshold = stronger security)
- Who controls each device (distribute across team members for separation of duties)
- Device types — mobile devices for manual review, CloudSign for automated signing, or a mix
Decide which operations require human approval before they take effect:
- Transactions
- Address book entries
- Policy rule changes
- API credential creation
- User invitations
- Device registration
A fintech company uses Palisade to manage institutional ETH and XRP custody. Their team has 6 people:
| Person | Role | Responsibility |
|---|---|---|
| Sarah (CTO) | Owner | Organization settings, emergency access |
| James (Ops lead) | Administrator | Day-to-day platform management |
| Maria (Trader) | Proposer | Initiates transactions |
| Ravi (Trader) | Proposer | Initiates transactions |
| Lisa (Compliance) | Approver | Reviews and approves transactions |
| Tom (Compliance) | Approver | Reviews and approves transactions |
Their decisions:
- Authentication — SSO with Okta, configured before sending invitations.
- Quorum design — one 3-of-5 Cloud quorum using CloudSign instances for automated signing. The higher threshold balances security with availability.
- Vault structure — two vaults: "Hot Wallet Operations" for daily trading and "Cold Storage" for reserve holdings.
- Approval structure — transaction approval group with Lisa and Tom as approvers, threshold of 1. Address and policy approvals require both (threshold of 2) since these changes are less frequent but higher risk.
- Policies — per-transaction limit of 50 ETH on hot wallets, rolling 24-hour limit of 500 ETH. Cold storage has lower limits and restricted destinations.
- Freeze controls — automatic freeze enabled on cold storage wallets for compliance review of every deposit.
This gives them separation of duties (traders propose, compliance approves), automated signing (CloudSign), and layered controls (policies + approvals + freeze).
After you have planned your organization structure, follow the recommended setup order in the overview page to configure each component. The first step is to Configure single sign-on if your organization uses SSO, or Manage users and roles to invite your team.