​

Security Architecture

​

Overview

Glider is a platform for creating and automating onchain portfolios. This automation is achieved primarily using a proprietary mix of session key management, smart account architecture, and an offchain orchestration Engine. We reach users across our front-end application at glider.fi and through external integrations leveraging our B2B APIs. Glider is built around three core concepts: strategies, smart accounts, and portfolios.

• A strategy defines a target asset allocation, such as a directly indexed Mag7 ETF or yield-generating stablecoin strategies.
• A smart account is a non-custodial smart wallet that can both hold assets and execute onchain actions. Unlike a traditional wallet, it can be programmed with permissions and automation.
• A portfolio combines a chosen strategy with one or more dedicated smart accounts that own the portfolio’s assets and execute its investment logic. Each time a user invests in a new strategy, Glider creates them a portfolio.

Portfolios are represented onchain as separately managed ZeroDev Kernel (EVM) or Swig (SVM) smart accounts. This account holds the strategy’s underlying tokens for the user and handles deposits, withdrawals, and automation. Automation runs through “agents”: offchain services that use session keys to perform actions like swaps, rebalancing, and processing deposits/withdrawals. This is what enables the one-click, gasless UX our users expect while preserving their ownership of assets.

​

Portfolios & Session Keys

For each user portfolio, Glider creates a smart account owned by the end user’s wallet. During enrollment, the user signs an authorization that lets a Glider-managed automation agent operate the account on behalf of the portfolio’s strategy. The smart account is exposed simply as a deposit address: any tokens sent there are swapped by Glider’s rebalancing Engine into the portfolio strategy’s target allocations. During portfolio enrollment, the user is generated uniquely an agent and a session key. They are stored separately: the agent in the KMS/HSM on Google Cloud VPC, and the session key is encrypted at rest in our secure database. Both are required to perform any operations on behalf of the user. More on this below. Our offchain systems manage the strategy blueprints (i.e. what to swap onchain, what assets to hold, at what weights we rebalance the portfolio) that interface with the rebalancing Engine. The Engine is highly privileged and is the only part of our architecture that interfaces with the session keys and agent to create the calldata needed for Glider to create an automated, frictionless investing UX for our users and integrators. The Engine has no external or public-facing APIs whatsoever. Glider’s flexible permission platform allows custom session key workflows and custom key solutions should an integrator have specific requirements. Contact us directly if you believe this applies to you.

​

Enrollment Flows

Portfolio creation is the only time Glider requests a signature from a user. That signature authorizes the session key that Glider’s automation Engine uses to manage the portfolio, whether its created on the front-end or via B2B APIs. The same signature underpins all of Glider’s enrollment paths,. The difference is only who presents the request to the user. On the Glider front-end, Glider handles it directly. Through the B2B API, the integrator relays it between the user and Glider. In both cases, the user signs in their own wallet, and the resulting message is bound uniquely to the:

• user wallet,
• smart-account index,
• target chains,
• smart account address,
• enrollment flow ID.

Glider recomputes and verifies this message before creating the smart account and session-key record. Binding these fields prevents the signature from being reused for a different user, portfolio, chain set, or smart account. At any time, the user can rotate, revoke, or re-sign their session keys.

​

Front-End Enrollment

When a user enrolls through glider.fi, Glider generates the authorization message, the user signs it in their connected wallet, and Glider verifies the signature and provisions the portfolio, all within a single session. No key material or signing authority leaves the user’s wallet or Glider’s infrastructure.

​

B2B Enrollment

When an external integrator enrolls a user through our API, the integrator relays the signing request but never handles any signing material itself:

1. The integrator calls Glider to request an enrollment message.
2. Glider returns a message for the user to sign—covering the user wallet, smart-account index, target chains, and smart account address, alongside the requested permissions in a JSON blob.
3. The user signs the message in their own wallet.
4. The integrator submits that signature back to Glider.
5. Glider verifies the signature and creates the smart accounts, links them to the selected strategy, and stores the session-key authorization needed for automation.

The integrator receives portfolio and smart-account identifiers. It does not receive the user’s private key, Glider’s KMS signing key, or the stored session-key material used by Glider’s execution Engine.

​

Key Management

Glider-managed automation agent keys are stored in Google Cloud KMS using HSMs. Private signing material is never exposed to application code. In order to automate portfolios, we use the combination of the agent authority in the KMS and the session key together; one alone is not enough to execute anything on behalf of a user, providing an additional layer of security. This process is the same, whether users are interacting with Glider via the front-end or through an external integration. Glider services store references to managed signer identities and key versions, then request signatures through Glider’s internal KMS service when automation needs to submit an onchain operation. This is privileged access that can only come from our internal systems. These functions never touch public endpoints. Glider does not have the ability to see agent signing keys. The KMS service is separated from public APIs and protected by service-to-service authentication. Platform APIs, execution services, and orchestration workers call it through Glider-controlled infrastructure. Integrators and the webapp do not connect directly to Glider KMS, do not manage Glider agent keys, and do not need access to Glider’s VPC or cloud environment. The user signature creates the authorization path. Glider stores the resulting session-key capability and KMS key reference; KMS holds the actual agent private key material; runtime execution combines the stored session-key authorization with a fresh KMS-backed agent signature.

​

Permission Model for Session Keys

Glider leverages permissions built into the smart account frameworks for automation. There are two important layers of authority:

• User owner authority: the user’s wallet remains the root owner of the smart account. The enrollment signature ties them together.
• Glider automation authority: during enrollment, the user authorizes a revocable session key that lets Glider’s automation Engine perform the onchain actions needed to run the portfolio (e.g., swapping, bridging, lending/borrowing, rebalancing, and other strategy-driven operations).

This broad automation capability enables the portfolio agent to react quickly to deposits/withdrawals, market movements, and strategy changes without requiring the user to sign individual transactions. This authorization is not a permanent, binding change to wallet ownership (e.g., it’s not equivalent to adding Glider as a long-lived onchain owner like a 1/1 Safe signer). Glider treats this automation capability as highly sensitive. It is protected by KMS-backed signing, internal service authentication, tenant/API-key authorization, strategy ownership checks, chain validation, idempotency controls, execution policy, logging, and reconciliation against indexed onchain state. Withdrawals are handled separately from automated portfolio execution. A withdrawal requires a fresh user-signed authorization that binds the recipient, assets, amounts, smart account, nonce, and expiry. Due to our permission systems, integrator API keys have intentionally limited surface area; customer funds never face withdrawal risk, even with a leaked API key.

​

Integrator Security Impact

When building with Glider, the integrator and Glider never custody user funds. The user always maintains agency over their portfolios and their own wallet. The integrator is responsible for presenting the Glider-generated signing request to the user, protecting its Glider API keys, and requesting only the API scopes it needs. This is Glider’s unique approach: we don’t own the smart accounts, and they have no private keys of their own. They exist natively onchain. We use each user’s signing authority (their wallet) to create new accounts they control, then leverage our permissions model to carry out their chosen strategies. Glider never manages, modifies, or needs access to the user’s wallet, and never requires seed phrases or private keys. What we do store is the operational data needed to run the portfolio: tenant identity, API-key scope, user wallet address, portfolio and strategy identifiers, smart-account addresses, session-key authorization records, schedules, and onchain/indexed activity. If the Glider front-end or B2B API shuts down, assets can always be claimed by interacting directly with the smart accounts onchain. While we don’t anticipate this, the funds are always safe and owned by the user’s wallet. These accounts always belong to the user, regardless of if Glider is here today or tomorrow. Have more questions? Reach out and let us know.