zeus-backends-and-capabilities

Guides cross-backend Lightning feature development across Zeus wallet's seven node implementations.

Updated Sep 2, 2026
One-click install
npx skills add https://github.com/aswin-dev-debug/Ai-Finance-analyzer --skill zeus-backends-and-capabilities-aswin-dev-debug
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: zeus-backends-and-capabilities
Source: https://github.com/aswin-dev-debug/Ai-Finance-analyzer/tree/main/lib/zeus-contrib/zeus/.claude/skills/zeus-backends-and-capabilities
Command: npx skills add https://github.com/aswin-dev-debug/Ai-Finance-analyzer --skill zeus-backends-and-capabilities-aswin-dev-debug

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Zeus is one wallet UI driving 7 interchangeable Lightning backends (LND, Embedded LND, LDK Node, LNC, CLNRest, LndHub, NWC), and its runtime dispatcher silently returns false for missing methods, causing '.then is not a function' crashes and features that silently no-op on some backends. This Skill documents the dispatch mechanism, the supports* capability-flag system, per-backend quirks, and the exact checklist for adding an RPC or feature safely across the whole matrix. ## Core Features & Use Cases - Dispatch and capability reference: Explains how BackendUtils.call() dispatches by implementation key, why missing methods return false synchronously, and how ~55 supports* flags gate every feature surface. - Per-backend quirk catalog: Documents verified sharp edges such as LND's success-shaped payment timeouts, LNC's hardcoded-true permissions (ZEUS-3642), CLNRest's raw SQL invoice queries, LDK Node's poll-based payment completion, and LndHub's dangerous inheritance of LND flags. - End-to-end feature recipe: Provides a 9-step checklist for adding a new RPC, including dispatcher wrappers, per-backend flags, inheritance-override audits for EmbeddedLND/LndHub, view gating, and the PR-template backend testing matrix. - Use Case: When a developer adds a new channel-management call and it crashes on CLNRest but works on LND, use this Skill to trace the flag gating, argument-shape mismatch, and missing backend implementation in order. ## Quick Start Ask the assistant to load the zeus-backends-and-capabilities skill and explain which supports* flag should gate a new feature and which backends need the method implemented.

Frequently Asked Questions about zeus-backends-and-capabilities

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I add a new RPC across all Zeus Lightning backends?

Implement the method on each backend class in backends/ (or omit it deliberately), add a dispatcher wrapper in utils/BackendUtils.ts with the exact same method name, add a supports* flag per backend, gate every call site on that flag, and fill in the PR-template backend testing matrix.

Why does my Zeus feature crash with '.then is not a function' on some backends?

BackendUtils.call() returns false synchronously when the active backend does not define the method, so calling .then on the result throws a TypeError. Always gate the call with the matching supports* flag before invoking it.

Which Lightning backends does Zeus support?

Zeus supports seven backends: LND (REST), Embedded LND (on-device via gomobile), LDK Node (on-device via uniffi), Lightning Node Connect, CLNRest (Core Lightning), LndHub, and Nostr Wallet Connect. Each has different transports, auth material, and capability flags.

Why does a feature work on LND but silently do nothing on CLNRest or NWC?

Check in order: whether the backend's supports* flag is true, whether the backend class defines the method at all (omission returns false silently), whether the argument shape matches that backend's signature, and whether a backend-specific quirk applies.

What is the inheritance hazard with EmbeddedLND and LndHub in Zeus?

Both extend the LND class, so any new method or flag added to LND is inherited silently. EmbeddedLND inherits REST calls that are meaningless on-device, and LndHub inherits true flags for features custodial accounts lack, such as supportsChannelFundMax and supportsAddressMessageSigning.

Why do version-gated capability flags read false at Zeus app startup?

nodeInfoStore initializes empty and isSupportedVersion parses a missing version as 0.0.0, so every version-gated flag returns false until getMyNodeInfo resolves during connect. Read flags lazily at render or call time rather than caching them.