Security Posture

Glider’s B2B API is designed around a simple separation of authority:

• Integrator API keys identify the tenant. They let your backend create strategies, enroll users, read portfolios, and request user-authorized actions within the scopes granted to that key.
• Users remain the root authority for their wallets and portfolios. Enrollment and withdrawal flows require user signatures. An API key alone does not replace a user’s wallet signature.
• Glider manages automation within scoped permissions. Glider operates portfolios through smart-account session keys or delegated agent authority so scheduled and manual rebalances can execute without asking the user to sign every routine rebalance.
• Assets live onchain. Portfolio assets are held in user-specific smart accounts or chain-native managed-account structures, not in an omnibus offchain ledger controlled by an integrator API key.

This page is a concise security model for integrators. If you have questions about a specific wallet provider, signing flow, custody policy, or production rollout, contact the Glider team directly.

​

Mental Model

Think of Glider as three layers: The integrator API key is an access credential for Glider’s API. It is not a custody credential for user assets.

​

What Glider Manages Centrally

Glider centrally operates the offchain systems needed to make portfolio automation reliable:

• API-key authentication, tenant identity, and scope enforcement.
• Strategy and portfolio metadata.
• Scheduling, orchestration, indexing, and operation status.
• Market data, balance reads, policy checks, and route construction.
• Managed automation agents backed by Glider key-management infrastructure.
• Session-key records and delegated permission material needed for automation.
• Idempotency records for write flows such as enrollment and withdrawal submission.

These centralized systems are used to coordinate automation. They do not turn an integrator API key into a user wallet key, and they do not move user funds without the authorization path required by the relevant flow.

​

What Is Not Centrally Managed

Glider does not centrally manage:

• Your end-user authentication or account recovery.
• Your custody of your own API keys.
• The user’s root wallet, passkey, smart-wallet owner, or recovery policy.
• A shared omnibus balance for your users.
• Arbitrary withdrawals initiated only by an integrator API key.

Your backend should treat the Glider API key like production infrastructure secret material: store it server-side, keep it out of browsers and mobile app binaries, restrict access internally, and rotate it if exposure is suspected.

​

What Is Onchain

The onchain layer is where asset custody and settlement occur:

• Portfolio accounts are chain-specific smart accounts or managed account structures.
• Deposits, balances, swaps, rebalances, and withdrawals settle onchain.
• User signatures are verified against the expected owner for sensitive authorization flows.
• Withdrawal authorizations are bound to the portfolio, recipient, assets, nonce, expiry, chain, and verifying contract.
• For supported Solana/SVM flows, Glider uses a managed-account graph: the user’s root authority bootstraps the managed account, and Glider receives scoped subordinate authority for automation.

The API returns CAIP identifiers so integrators can reason about accounts and assets without relying on chain-specific field names. See CAIP identifiers.

​

Flow Example: Enrollment

Enrollment is a two-stage authorization flow:

1. Your backend calls POST /v2/enroll/signature with the user’s owner account, target strategy, and chains.
2. Glider verifies the strategy belongs to your tenant, resolves a managed automation agent, computes the smart-account session-key message, and returns the message plus round-trip fields.
3. The user signs the returned message in their wallet.
4. Your backend submits POST /v2/enroll with the original round-trip fields and the user’s signature.
5. Glider verifies the signature, creates the portfolio and per-chain smart accounts, stores scoped session-key material, and schedules automation.

Security properties:

• The API key proves the request came from your tenant.
• The user signature proves the owner wallet authorized enrollment.
• flowId binds retries and prevents duplicate enrollment side effects.
• Glider receives scoped automation authority, not the user’s root key.

See Two-stage enrollment.

​

Flow Example: Withdrawal

Withdrawals are also two-stage:

1. Your backend calls POST /v2/portfolios/{portfolioId}/withdraw/signature.
2. Glider validates tenant ownership, recipient shape, chain match, duplicate assets, live balances, and portfolio smart-account availability.
3. Glider returns EIP-712 typed data with a short expiry and a random nonce.
4. The user signs the typed data.
5. Your backend submits the signed message to POST /v2/portfolios/{portfolioId}/withdraw.
6. Glider re-checks ownership, expiry, balances, recipient rules, and the signature before dispatching onchain execution.

Security properties:

• The signed message includes the portfolio, recipient, assets, nonce, expiry, chain, and verifying contract.
• The nonce is the idempotency anchor for safe retries.
• Expired or tampered authorizations are rejected.
• The request is accepted asynchronously, then tracked through an operation id.

See Two-stage withdrawal.

​

Integrator Responsibilities

Integrators are responsible for:

• Keeping API keys server-side and limiting internal access.
• Calling GET /v2/whoami during integration to confirm tenant identity and granted scopes.
• Showing users exactly what they are signing and preserving returned signable payloads byte-for-byte between stages.
• Mapping your user identity to the correct wallet or smart wallet.
• Respecting idempotency anchors instead of generating new values on retry.
• Handling 401, 403, 409, 429, and 5xx responses according to the documented retry model.
• Sending Glider the X-Correlation-Id from failing responses when asking for support.

Start with Authentication, Idempotency, and Rate limiting for the operational pieces.

​

Current Surface Notes

The current v2 enrollment and withdrawal examples are EVM-oriented and use EVM wallet signatures, smart accounts, and EIP-712 where applicable. Glider’s broader account model is cross-chain and uses CAIP identifiers throughout the API, with Solana/SVM support modeled through chain-native managed accounts and scoped delegation where supported. When in doubt, ask Glider which authorization path applies to your exact wallet stack before moving production traffic.