[new-plugin] sanctum-validator-lst v0.1.0#179
Conversation
skylavis-sky
temporarily deployed
to
summary-generation
GitHub Actions
Inactive
Phase 4: Summary + Pre-flight for
|
| Command | Description |
|---|---|
list-lsts |
List all tracked validator LSTs with APY, TVL, and SOL value |
get-quote |
Quote a swap between two LSTs with optional slippage |
swap-lst |
Swap between two validator LSTs via Sanctum Router |
stake |
Stake SOL into a validator LST pool (primarily jitoSOL) |
get-position |
Show your validator LST holdings and SOL equivalent value |
Triggers
Activate when users want to stake SOL into validator liquid staking tokens, swap between different LSTs, or manage their validator staking positions on Solana. Use trigger phrases like "sanctum stake", "stake sol jitosol", or "swap lst sanctum".
Auto-injected Pre-flight
## Pre-flight Dependencies (auto-injected by Plugin Store CI)
> Run once per session before first use. These checks ensure required tools are installed.
### Install sanctum-validator-lst binary (auto-injected)
```bash
if ! command -v sanctum-validator-lst >/dev/null 2>&1; then
OS=$(uname -s | tr A-Z a-z)
ARCH=$(uname -m)
case "${OS}_${ARCH}" in
darwin_arm64) TARGET="aarch64-apple-darwin" ;;
darwin_x86_64) TARGET="x86_64-apple-darwin" ;;
linux_x86_64) TARGET="x86_64-unknown-linux-gnu" ;;
linux_aarch64) TARGET="aarch64-unknown-linux-gnu" ;;
esac
curl -fsSL "https://github.com/MigOKG/plugin-store/releases/download/plugins/sanctum-validator-lst@0.1.0/sanctum-validator-lst-${TARGET}" -o ~/.local/bin/sanctum-validator-lst
chmod +x ~/.local/bin/sanctum-validator-lst
fiReport install (auto-injected, runs once)
REPORT_FLAG="$HOME/.plugin-store/reported/sanctum-validator-lst"
if [ ! -f "$REPORT_FLAG" ]; then
mkdir -p "$HOME/.plugin-store/reported"
# Device fingerprint → SHA256 → 32-char device ID
DEV_RAW="$(hostname):$(uname -s):$(uname -m):$HOME"
DEV_ID=$(echo -n "$DEV_RAW" | shasum -a 256 | head -c 32)
# HMAC signature (obfuscated key, same as CLI binary)
_K=$(echo 'OE9nNWFRUFdfSVJkektrMExOV2RNeTIzV2JibXo3ZWNTbExJUDFIWnVoZw==' | base64 -d 2>/dev/null || echo 'OE9nNWFRUFdfSVJkektrMExOV2RNeTIzV2JibXo3ZWNTbExJUDFIWnVoZw==' | openssl base64 -d)
HMAC_SIG=$(echo -n "${_K}${DEV_ID}" | shasum -a 256 | head -c 8)
DIV_ID="${DEV_ID}${HMAC_SIG}"
unset _K
# Report to Vercel stats
curl -s -X POST "https://plugin-store-dun.vercel.app/install" \
-H "Content-Type: application/json" \
-d '{"name":"sanctum-validator-lst","version":"0.1.0"}' >/dev/null 2>&1 || true
# Report to OKX API (with HMAC-signed device token)
curl -s -X POST "https://www.okx.com/priapi/v1/wallet/plugins/download/report" \
-H "Content-Type: application/json" \
-d '{"pluginName":"sanctum-validator-lst","divId":"'"$DIV_ID"'"}' >/dev/null 2>&1 || true
touch "$REPORT_FLAG"
fi
</details>
---
*Generated by Plugin Store CI after maintainer approval.*
📋 Phase 3: AI Code Review Report — Score: 52/100
1. Plugin Overview
Summary: This plugin enables users to stake SOL into validator Liquid Staking Tokens (LSTs) like jitoSOL and bSOL, swap between LSTs via the Sanctum Router API, view LST positions, and get swap quotes on Solana. It interacts with Sanctum's external APIs and the Solana RPC. Target Users: Solana DeFi users who want to liquid-stake SOL with various validators or swap between different LST tokens using Sanctum's routing infrastructure. 2. Architecture AnalysisComponents:
Skill Structure: Data Flow:
Dependencies:
3. Auto-Detected Permissionsonchainos Commands Used
Wallet Operations
External APIs / URLs
Chains Operated On
Overall Permission SummaryThis plugin operates exclusively on Solana and performs both read operations (LST listings, positions, quotes) and write operations (staking SOL, swapping LSTs). The write operations involve constructing, signing, and broadcasting Solana transactions. The plugin does NOT use the onchainos CLI for any of these on-chain write operations — it self-implements transaction construction and broadcasting via direct Solana RPC calls. It also communicates with two Sanctum API endpoints for data and routing, plus a plugin store endpoint and an OKX telemetry endpoint. The direct RPC interaction for transaction signing/broadcasting is a critical compliance finding. 4. onchainos API ComplianceDoes this plugin use onchainos CLI for all on-chain write operations?No — This is a standalone binary that self-implements all on-chain write operations. On-Chain Write Operations (MUST use onchainos)
Data Queries (allowed to use external sources)
External APIs / Libraries Detected
Verdict: ❌ Non-CompliantCritical violations that must be fixed:
To become compliant, the binary should:
5. Security AssessmentStatic Rule Scan (C01-C09, H01-H09, M01-M08, L01-L02)
LLM Judge Analysis (L-PINJ, L-MALI, L-MEMA, L-IINJ, L-AEXE, L-FINA, L-FISO)
Toxic Flow Detection (TF001-TF006)TF006 — External data no boundary isolation + Financial operations (HIGH → WARN):
Prompt Injection ScanNo instruction override, identity manipulation, hidden behavior, confirmation bypass, unauthorized operations, or hidden content (base64, invisible chars) detected in SKILL.md. Result: ✅ Clean Dangerous Operations CheckYes — the plugin involves:
User confirmation steps: SKILL.md instructs "Always ask for user confirmation first" for Result: Data Exfiltration RiskThe plugin calls Result: Overall Security Rating: 🔴 High RiskPrimary risk factors:
6. Source Code Security (if source code is included)Language & Build Config
Dependency AnalysisSource code is not included in the submission — only a reference to an external repository and commit. Dependencies cannot be analyzed without the actual Key concern: The source is hosted in the plugin author's personal GitHub repo ( Code Safety Audit
Does SKILL.md accurately describe what the source code does?❓ Unknown — cannot verify without the actual source code. The SKILL.md describes 5 commands and their parameters, but the binary's actual behavior (especially around transaction signing, key access, and data transmission to telemetry endpoints) cannot be confirmed. Verdict:
|
| Dimension | Score | Notes |
|---|---|---|
| Completeness (pre-flight, commands, error handling) | 12/25 | No pre-flight checks, no onchainos integration, 5 commands described but no error handling guidance, no troubleshooting section |
| Clarity (descriptions, no ambiguity) | 16/25 | Commands are clearly described with examples. Supported LSTs are well-documented. However, the signing/broadcasting mechanism is completely opaque — SKILL.md doesn't explain how transactions are signed or where keys come from |
| Security Awareness (confirmations, slippage, limits) | 10/25 | Has user confirmation instruction and --dry-run flag for write ops. Has slippage parameter on get-quote. Data Trust Boundary is declared. But: no confirmation enforcement, no max amount limits, no security scan integration, no TEE signing |
| Skill Routing (defers correctly, no overreach) | 9/15 | Good "Do NOT use for" section that defers mSOL staking, Ethereum staking, and Infinity LP operations. However, plugin overreaches by self-implementing transaction signing/broadcasting instead of deferring to onchainos |
| Formatting (markdown, tables, code blocks) | 5/10 | Clean markdown structure, good use of tables for LST list. Code examples are provided. But lacks parameter tables with types/defaults, return field documentation, and reference docs |
Strengths
- Clear documentation of supported LSTs with symbols and descriptions
--dry-runflag available for write operations (stake, swap-lst)- Data Trust Boundary declaration is present and substantive
- Good skill routing with explicit "Do NOT use for" section
Issues Found
-
🔴 Critical: Does not use onchainos CLI for on-chain write operations. The binary self-implements transaction signing and broadcasting via direct Solana RPC. This bypasses the onchainos security model (TEE signing, confirmation gates, audit logging). MUST be refactored to use
onchainos wallet contract-calloronchainos gateway broadcast. -
🔴 Critical: Opaque key management. SKILL.md does not explain how the binary accesses private keys for signing Solana transactions. This is a major security concern — the binary could be reading keys from environment variables, files, or keyring without user awareness.
-
🔴 Critical: Source code not included in submission. The binary is built from an external author-controlled repo. Without source code review, the binary's actual behavior cannot be verified. The binary could potentially exfiltrate keys, send data to undeclared endpoints, or perform operations not described in SKILL.md.
-
🟡 Important: Author-controlled telemetry endpoint. The
plugin-store-dun.vercel.app/installendpoint is controlled by the plugin author, not OKX. Data sent to this endpoint is unknown without source review. -
🟡 Important: No pre-flight checks. SKILL.md does not include the standard onchainos pre-flight check section (install, update, verify binary integrity). The plugin appears to be entirely self-contained.
-
🟡 Important: No confirmation enforcement. Write operations (swap, stake) rely on SKILL.md text saying "Always ask for user confirmation first" — this is not architecturally enforced. onchainos uses exit code 2 confirming responses and
--forceflags. -
🟡 Important: No return field documentation. Commands don't document their output fields, making it impossible to verify what data enters the agent context.
-
🔵 Minor: Missing parameter type/default documentation. Commands show examples but don't have formal parameter tables with types, required/optional, and defaults.
-
🔵 Minor: No edge case documentation. No section covering error scenarios, network failures, or chain-specific issues.
8. Recommendations
-
[CRITICAL] Refactor to use onchainos CLI for all on-chain writes. The binary should construct unsigned transactions and delegate signing/broadcasting to
onchainos wallet contract-call --chain 501 --unsigned-tx <base58>. This ensures TEE signing, audit logging, and confirmation gates. -
[CRITICAL] Include source code in submission or provide verifiable build. Either include the full Rust source in the submission, or provide a reproducible build process that allows auditors to verify the binary matches the source at the pinned commit.
-
[CRITICAL] Remove or explain key management. Document exactly how the binary accesses signing keys. If it reads private keys directly, this must be refactored to use onchainos wallet infrastructure.
-
[HIGH] Audit the
plugin-store-dun.vercel.appendpoint. Verify what data is sent to this author-controlled endpoint. Consider removing it or replacing with an OKX-controlled telemetry endpoint. -
[HIGH] Add onchainos pre-flight checks. Include the standard pre-flight section from other official skills to ensure onchainos CLI is installed and up-to-date.
-
[HIGH] Implement architectural confirmation enforcement. Use the onchainos confirming response pattern (exit code 2 +
--forceflag) instead of relying on SKILL.md text instructions. -
[MEDIUM] Add return field documentation. Document output fields for each command so agents can properly parse and display results with field-level isolation.
-
[MEDIUM] Add field-level isolation for displayed data. Specify exactly which fields from API responses should be displayed (e.g., "show: symbol, APY, TVL, SOL value") to satisfy M08 requirements.
-
[LOW] Add parameter tables with types and defaults. Formalize parameter documentation similar to onchainos reference docs.
-
[LOW] Add error handling and edge case documentation. Include common error scenarios and troubleshooting guidance.
9. Reviewer Summary
One-line verdict: Plugin self-implements transaction signing and broadcasting via direct Solana RPC, completely bypassing the onchainos security model — a critical compliance violation that must be resolved before merge.
Merge recommendation: 🔍 Needs changes before merge
Required changes before merge:
- Refactor all on-chain write operations to use onchainos CLI (
wallet contract-callorgateway broadcast) - Include full source code in submission or provide reproducible build verification
- Document and resolve key management approach (must not directly access private keys)
- Audit and justify the author-controlled telemetry endpoint (
plugin-store-dun.vercel.app) - Add onchainos pre-flight checks and standard confirmation enforcement patterns
Generated by Claude AI via Anthropic API — review the full report before approving.
🔨 Phase 2: Build Verification — ❌ FAILED
Build failed. Check the workflow logs. Source integrity: commit SHA |
✅ Phase 1: Structure Validation — PASSED→ Proceeding to Phase 2: Build Verification |
1 participant
New Plugin Submission: sanctum-validator-lst v0.1.0
Plugin: Stake SOL into validator LSTs via Sanctum Router (Solana)
Author: skylavis-sky
Category: defi-protocol
Source