Skip to content
Back to skills

Olympus Architecture

ASecurity

This skill should be used when the user asks about "Olympus architecture", "Olympus V3", "Bophades", "Default Framework", "Kernel module policy", "Keycode", "permissioned module", "how Olympus works", or needs a high-level map of Olympus Kernel / modules / policies and how pieces connect.

  • 9 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added September 10, 2026
businessgotesting

Security analysis

A100/100

Pro scans all 3 files and shows the line behind each finding

Scanned September 10, 2026

npx -y skills add cyotee/indexedex --skill olympus-architecture --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Olympus Architecture?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Olympus Architecture
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/cyotee-olympus-architecture/badge)](https://www.skillsdirectory.com/skills/cyotee-olympus-architecture)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: olympus-architecture
description: This skill should be used when the user asks about "Olympus architecture", "Olympus V3", "Bophades", "Default Framework", "Kernel module policy", "Keycode", "permissioned module", "how Olympus works", or needs a high-level map of Olympus Kernel / modules / policies and how pieces connect.
license: MIT
---

# Olympus Architecture (Default Framework / Bophades)

Olympus V3 is a **Default Framework** protocol: a central **Kernel** registry installs **Modules** (state) and activates **Policies** (application logic + external UX). Policies call modules only when Kernel has granted **Permissions**.

## Stack map

```text
┌──────────────────────────────────────────────────────────────┐
│  End users / DAO MS / integrators / Crane strategies         │
├──────────────────────────────────────────────────────────────┤
│  Policies  (UX + app logic; activated by Kernel executor)    │
│  Minter · RolesAdmin · TreasuryCustodian · Emergency · …     │
├──────────────────────────────────────────────────────────────┤
│  Kernel  (registry + Actions + modulePermissions)            │
│  executor-only: Install/UpgradeModule, Activate/Deactivate…  │
├──────────┬──────────┬──────────┬──────────┬──────────────────┤
│ MINTR    │ TRSRY    │ ROLES    │ RANGE    │ INSTR / VOTES /… │
│ mint OHM │ assets   │ roles    │ RBS band │ gov / other      │
├──────────┴──────────┴──────────┴──────────┴──────────────────┤
│  Protocol tokens / periphery                                 │
│  OlympusERC20 (OHM) · Cooler (P2P loans) · gOHM integrations │
└──────────────────────────────────────────────────────────────┘
```

## Core ideas

| Concept | Detail |
|---------|--------|
| **Kernel** | Sole mutator of the module/policy graph via `executeAction` |
| **Module** | Stateful building block with 5-letter `KEYCODE()` (A–Z only), versioned, `permissioned` gate |
| **Policy** | External interface; declares `configureDependencies()` + `requestPermissions()` |
| **Permissions** | `(Keycode, bytes4 selector)` granted to a policy when activated |
| **Executor** | Address that may call Kernel actions (multisig / governance) |
| **Roles** | Policy-defined `bytes32` roles stored in ROLES module; not the same as Kernel permissions |

## Kernel Actions

```solidity
enum Actions {
    InstallModule,   // first install of a keycode
    UpgradeModule,   // replace module impl; reconfigure dependents
    ActivatePolicy,  // wire deps + grant requested permissions
    DeactivatePolicy,// revoke permissions + remove from active set
    ChangeExecutor,
    MigrateKernel
}
```

Call path: `kernel.executeAction(Actions.InstallModule, address(module))` (executor only).

## Module catalog (in-tree Crane port)

| Keycode | Role |
|---------|------|
| `MINTR` | Mint/burn OHM; per-policy mint approvals |
| `TRSRY` | Hold ERC20s; withdraw + debt approvals |
| `ROLES` | Grant/revoke policy-defined roles |
| `RANGE` | Range-bound stability (RBS) state |
| `INSTR` | Instruction batches / proposals |
| `VOTES` | Voting power module |
| `CHREG` | Clearinghouse registry |
| `BLREG` | Boosted liquidity registry |
| `RGSTY` | Contract registry |
| `DLGTE` | Governance delegation |
| `PRICE` | Price feeds / submodules (partial in port) |

## Crane placement

| Tree | Path |
|------|------|
| Domain port (forward) | `contracts/protocols/tokens/stable/olympus/v3/` |
| Pin / scope | `…/olympus/v3/VENDOR.md` |
| Tests | `test/foundry/spec/protocols/tokens/stable/olympus/v3/` |
| Service / Aware / TestBase | `…/v3/services/`, `…/v3/aware/`, `…/v3/test/bases/` |
| Profile | `FOUNDRY_PROFILE=olympus_v3_port` |
| Upstream | OlympusDAO/olympus-v3 (AGPL-3.0-only; see VENDOR.md pin) |
| Research dual tree | `olympus/v2/` + `olympus_port`; skills archive `docs/archive/skills/olympus-v2/` |

## Navigation

| Need | Go to |
|------|--------|
| User/policy call flows | `skill:olympus-operations` |
| Crane build/test/integration | `skill:crane-olympus` |
| Kernel + Policy authoring detail | `references/kernel-and-policies.md` |
| Module surface map | `references/modules.md` |

## Constraints

- Policies **must not** call module functions without Kernel permissions; modules use `permissioned`.
- Direct module calls from EOAs/strategies fail with `Module_PolicyNotPermitted` unless routed through an active policy (or Kernel).
- Keycodes are exactly 5 uppercase ASCII letters (`toKeycode("MINTR")`).
- Phase-2 / out-of-tree: CCIP/LZ bridges, deposit facility, many PRICE.v2 feeds — see `VENDOR.md`.

## See also

- `skill:olympus-operations`, `skill:crane-olympus`
- `skill:crane-porting`, `skill:crane-testing`

Files in this skill

  • SKILL.md5.4 KB
  • references/kernel-and-policies.md3.8 KB
  • references/modules.md2.6 KB

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…