SDK Generations¶
The platform runs SDK v3. SDK v2 strategies created before the switch remain on the platform in
read-only form. Both generations are published under the distribution name almanak; the major
version tells them apart.
SDK v2 (almanak 2.x) |
SDK v3 (almanak 3.x) |
|
|---|---|---|
| Repository layout | strategy.py, config.json, pyproject.toml with [tool.almanak.run] |
strategy.py, config.yaml, optional backtest.yaml / backtest-economic.yaml |
| Strategy contract | IntentStrategy with intents such as Swap, LP or Borrow |
Hook functions (decide, on_outcome) over explicit connector declarations |
| Configuration | config.json, overridable per deployment |
config.yaml, validated against the SDK schema; the platform passes it through unchanged |
| Permissions | almanak strat permissions exports a Zodiac Roles manifest before deployment |
The running deployment exports owner transactions; the deployment waits in Action required until they are executed |
| Dashboard | Streamlit page served by the deployment | JSON dashboard evaluated inside the deployment pod and rendered on the deployment page |
| Backtests | Platform backtest runner with start and end dates | backtest.yaml or backtest-economic.yaml from the repository, run by the platform runner |
| Status | Read-only: existing strategies and chats stay viewable, live deployments can be stopped | Active: every new strategy, chat and deployment |
New strategies are written for SDK v3. Pin almanak>=3 in your repository; see the
Almanak SDK documentation for the authoring guide. Projects that
still build on the 2.x line outside the platform should pin almanak<3, because an unpinned
almanak now installs 3.x.
Which generation is my strategy?¶
The platform classifies a repository when it is linked and records the generation on the strategy.
The resolved almanak version decides: a lockfile or pyproject.toml that resolves to almanak
3.x makes the strategy SDK v3, and the repository must then contain strategy.py and config.yaml.
Anything that resolves below 3.0 is an SDK v2 strategy and is read-only.
The Strategy Library shows the generation on every strategy and deployment. A strategy never changes generation in place: to move a v2 strategy to SDK v3, rewrite it for v3 and link that repository.
What the platform does with each generation¶
- Deploy: new deployments use SDK v3. The deploy flow, the deployment controls and the dashboard follow the strategy's generation, and the platform refuses a mismatch instead of guessing.
- Backtest: v3 runs take one of the repository's backtest files (or an edited copy of it) and validate it inside the runner. v2 backtests no longer run; past v2 results stay viewable.
- Almanak Code: new sessions use the SDK v3 assistant and validate the workspace with
almanak check. Sessions attached to v2 strategies are read-only. - Supported protocols: the supported protocols list names the generations that ship each protocol.
The switch to SDK v3¶
The platform moved from SDK v2 to SDK v3 in one step. There is no switch between the two generations: before the change the platform ran v2 only, and now it runs v3 only.
What stays available for SDK v2:
- Strategies and chats remain listed and viewable, including chat history, code and past backtest results. You can no longer send messages in a v2 chat, start a new chat on a v2 strategy, run a backtest or deploy it.
- Live deployments keep running. You can view their state and dashboards, stop them, tear them down and withdraw funds. Redeploying, restarting or updating a v2 deployment to a newer commit is no longer possible.