Wallet-side transaction & signature policy engine. dambi intercepts wallet RPC in the browser, decodes each transaction or EIP-712 signature into a typed semantic action, and evaluates that action against a Cedar policy set — warning or blocking before the user signs.

The repo is a hybrid Rust + TypeScript monorepo:

• a Rust/Cedar policy engine compiled to WASM and embedded in the extension,
• a browser extension (Chrome MV3 / Firefox MV2) that hosts that WASM and a policy-management dashboard,
• a stateful Rust backend (policy-server) for auth, wallets, and predicted state deltas,
• a registry (registryV2) of adapter manifests + token metadata that drives decoding.

dApp → window.ethereum  ──intercept──▶  extension service worker
                                          │
                                          ├─ decode calldata / typed-data  (registryV2 manifests)
                                          │       └─▶ ActionBody tree
                                          │
                                          ├─ lower ActionBody → Cedar request
                                          │       └─▶ in-SW WASM Cedar eval  → Verdict (Pass / Warn / Fail)
                                          │
                                          └─ (optional) policy-server  ── predicted StateDeltas, auth, wallets

1. The extension intercepts wallet transactions and EIP-712 / personal signatures.
2. Decoders (driven by registryV2 manifests) turn raw calldata / typed-data into a typed ActionBody tree (see Action model).
3. The Rust engine lowers that ActionBody to a Cedar request and evaluates it against the installed policies — all inside the service worker via WASM. No network round-trip is required for a verdict.
4. policy-server is the stateful backend: Google OAuth, wallet/account state, and an /evaluate endpoint that returns predicted StateDeltas from the asset-model reducer. The extension owns the final verdict; the server supplies state context.

The version suffixes are protocol names, not "old vs new" — they coexist on purpose and renaming them would churn every call site. What each one means:

If you add a new protocol revision, give it a name here and keep the old one documented until it is actually deleted.

The authoritative Rust crate list is the [workspace] members in Cargo.toml.

The policy input is the v3 hierarchical ActionBody tree, defined in crates/policy-server/asset-model/action (policy-action) and re-exported by crates/policy-engine as action::v3. An Action is { meta, body } where meta carries submission info (OnchainTx vs OffchainSig) and body is one domain variant:

// crates/policy-server/asset-model/action/src/lib.rs
pub enum ActionBody {
    Token(TokenAction),
    Amm(AmmAction),
    Lending(LendingAction),
    Airdrop(AirdropAction),
    Launchpad(LaunchpadAction),
    Perp(PerpAction),
    LiquidStaking(LiquidStakingAction),
    Permission(PermissionAction),
    Yield(YieldAction),
    Restaking(RestakingAction),
    Staking(StakingAction),
    Governance(GovernanceAction),
    HyperliquidCore(HyperliquidCoreAction),
    Marketplace(MarketplaceAction),
    Multicall { actions: Vec<ActionBody> },  // batched (e.g. Universal Router)
    Unknown { target, chain, calldata, value },  // unidentified — policy default: warn / deny
}

Each domain has a matching Cedar schema fragment under schema/policy-schema/actions/<domain>/. Multicall recurses (a Universal Router execution decodes into nested ActionBody entries), and Unknown is the fail-closed branch for calls no adapter recognizes.

cargo test --workspace        # or: scripts/test-all.sh  (adds clippy/fmt + extension)
cargo clippy --workspace --all-targets -- -D warnings
cargo fmt --all

scripts/test-all.sh runs the full sweep (cargo test + clippy + fmt, then the extension typecheck / vitest / chrome build); scripts/lint.sh is the fix-everything counterpart (cargo fmt + clippy --fix + yarn lint).

The crates/integration-tests decode harness reads a generated index at registryV2/index/ (a build artifact, not tracked). Regenerate it first:

cd registryV2 && npm ci && npm run build

scripts/wasm-build.sh

Runs wasm-pack build crates/policy-engine-wasm --target web --release and copies the artifact into browser-extension/backend/wasm/ and browser-extension/public/wasm/. The extension's yarn prepare:wasm step calls this script, so a normal extension build picks it up automatically.

A Yarn 4 workspace at browser-extension/ (the dashboard is a nested workspace). Loadable builds are produced by two pipelines into dist/<browser>/: webpack (SW / content scripts / popup / confirm) and Vite (the options-page dashboard).

cd browser-extension
yarn install
yarn build:ext         # chrome (webpack) + dashboard (vite) → dist/chrome/
# or, for live dev:
yarn dev:chrome        # webpack --watch; run `cd dashboard && yarn dev` alongside for the dashboard

Build-time config is via env vars — most importantly DAMBI_SERVER_URL (the policy-server the extension calls; default http://127.0.0.1:8788) and REGISTRY_BASE_URL. See browser-extension/README.md for the full matrix, load instructions, and the local-server workflow.

cp .env.local.example .env.local       # fill JWT_SECRET, GOOGLE_*, DATABASE_URL, …
scripts/start-policy-server.sh local   # = cargo run -p policy-server --bin policy-server
# or via the root package.json:
yarn server:local
curl http://127.0.0.1:8788/readyz

start-policy-server.sh <profile> loads .env.<profile> then runs the server; local targets the dashboard at http://127.0.0.1:5173, ext targets the in-extension OAuth flow. For a prod-like local Kubernetes loop see crates/policy-server/server/deploy/local/README.md (scripts/policy-server-local-k8s.sh).

.github/workflows/ci.yml runs on every PR and push to main; new pushes cancel the previous in-flight run for that branch. rust and wasm run in parallel; extension waits only on the wasm pkg artifact.

• rust — builds the registryV2 index (npm), then cargo fmt --check, cargo clippy -D warnings, cargo test (doctests included), and cargo doc with -D warnings.
• wasm — wasm-pack build crates/policy-engine-wasm (artifact reused by the extension job) and headless-Chrome wasm-bindgen tests.
• extension — yarn typecheck, vitest, Chrome MV3 build + zip, the dashboard build (uploaded per-PR so reviewers can sideload). Firefox MV2 build/zip runs on main only.
• secrets-scan — gitleaks over the full history.

dependency-policy.yml (cargo audit + cargo deny) runs when dependency files change and weekly.

To reproduce the suite locally, run cargo test (with the registry index built, above) and cd browser-extension && yarn test.

Cedar evaluates against calldata-derived primitives plus optional remote facts. A policy bundle may ship a .policy-rpc.json manifest that declares which backend method supplies a fact (e.g. a USD valuation), which params to send, and which response field is projected into the Cedar context. The extension asks WASM to plan those calls, sends them to policy-server, then asks WASM to materialize the responses and evaluate Cedar. The engine itself performs no direct oracle / balance / allowance lookups.

MIT.