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 offchain orchestration. We reach users through our front-end application at glider.fi and through external integrations using 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 & 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, Glider selects a managed automation signer and creates the smart-account permission payload that the user authorizes. The provider-managed signing key and the stored session-key authorization are separate controls; both are required for Glider automation. Our offchain systems manage strategy blueprints—what assets to hold, at what weights, and when to rebalance—and pass approved work into Glider’s execution services. Those services are privileged internal consumers of session-key authorizations and managed signer identities. Integrators submit supported actions through the Platform API; they do not call the internal signing service directly.Enrollment Flows
Portfolio enrollment is when the user grants the initial automation authorization, whether enrollment starts in the Glider front end or through the B2B API. Other sensitive flows can require a fresh user signature, including withdrawals, adding chains, and rotating session-key permissions. The same authorization model underpins Glider’s enrollment paths. The difference is 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.
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:- The integrator calls Glider to request an enrollment message.
- 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.
- The user signs the message in their own wallet.
- The integrator submits that signature back to Glider.
- Glider verifies the signature and creates the smart accounts, links them to the selected strategy, and stores the session-key authorization needed for automation.
Key Management
Glider-managed automation keys are stored through a managed KMS provider; production providers use non-exportable key material and can be backed by hardware security modules. Private signing material is not returned to application code. Portfolio automation combines the managed signer with the user-authorized session-key permission; one without the other is not a complete execution path. This is the same whether a user enrolls through the front end or 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. Integrators and client applications cannot retrieve the private key material. 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).