Open
Conversation
- Wrap int() conversions in deposit_marker() with try-except to prevent ValueError crash on non-numeric fee_ppm/volume_sats input - Wrap int() conversions in _execute_channel_open() for proposed_size and amount_sats with try-except returning error dict - Fix SCID format check from len(parts) >= 1 (always true) to >= 3 to properly validate blockheight x txindex x output format Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Five bulk-save methods (DELETE + INSERT loop) were running in autocommit mode where each statement committed immediately. A crash mid-loop would leave tables empty. Now atomic via self.transaction(). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
… in defense status - cl-hive.py: remove MembershipTier.ADMIN reference (enum doesn't exist) that crashed settlement gaming detection with AttributeError every cycle - cl-hive.py: fix stale comment on hive-ban; clarify direct-ban is neophyte-only, full members require proposal/vote - fee_coordination.py: read_markers/get_all_markers now return copies via dataclasses.replace() instead of mutating stored marker strength on every read (caused cumulative double-decay far faster than the intended 168-hour half-life) - rpc_commands.py: add missing expires_at field to peer_threat dict in hive-defense-status response so fee_controller can auto-expire threats Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
recommended_fee=0 and fee_ppm=0 were treated as falsy by Python's `or` operator, falling through to alternate keys. This could apply nonzero fees to hive channels that must remain at 0 ppm (safety constraint #6). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Tier thresholds were changed (STRUGGLING ≤20, VULNERABLE 21-40, STABLE 41-65, THRIVING >65) but tests still used old boundaries (30/50/70). Also fix fee_intelligence test to use health values that actually trigger the struggling/thriving code paths. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Exposes the new revenue-fee-anchor RPC via MCP so the AI advisor can set soft fee targets with decaying weight. Supports set/list/get/clear/ clear-all actions. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Proposes a protocol for authenticated, paid remote fleet management: - Archon DIDs for agent identity and scoped authorization - L402/Cashu for micropayment-gated access - Bolt 8 custom messages for encrypted command delivery - Versioned management schemas (fee-policy, rebalance, config, monitor) - Reputation system with verifiable advisor credentials - Implementation roadmap (6 phases) This enables a marketplace for node management where agents with proven routing expertise can offer services to any Lightning node, authenticated by DID, paid by Lightning, communicated over Bolt 8.
…updated and audited
Comprehensive spec for liquidity services offered through the hive marketplace: - 9 service types: leasing, pools, JIT, sidecar, swaps, submarine, turbo, balanced, insurance - 6 pricing models: sat-hours, flat fee, revenue share, yield curve, auction, dynamic - Liquidity provider profiles with reputation domain (hive:liquidity-provider) - Escrow mechanisms for each service type using Cashu NUT-10/11/14 - 5 proof mechanisms: channel existence, capacity attestation, routing, uptime, revenue - Settlement integration mapping all services to existing settlement types - Capital efficiency: portfolio management, recycling, yield optimization advisors - Risk management: force close allocation, provider/client threat models - Fleet management integration: advisor-driven liquidity with budget constraints - Non-hive access via cl-hive-client / hive-lnd - Comparison with Lightning Pool, Magma, LNBig - Privacy: minimum disclosure protocol, provider privacy, blind matching - Implementation roadmap (8 phases) Cross-references updated in all 5 companion specs: - DID-HIVE-SETTLEMENTS.md: Type 3 references full liquidity protocol - DID-HIVE-MARKETPLACE.md: Added liquidity-services specialization - DID-HIVE-CLIENT.md: Added liquidity marketplace to feature comparison - DID-L402-FLEET-MANAGEMENT.md: Liquidity marketplace task + references - DID-CASHU-TASK-ESCROW.md: Reference for escrow usage in liquidity services Audit report: AUDIT-LIQUIDITY-FINAL.md
…dity spec
Two architectural requirements incorporated throughout DID-HIVE-LIQUIDITY.md:
1. UNIFIED CLIENT ARCHITECTURE
- Liquidity services delivered through same cl-hive-client / hive-lnd
- Shared components: Schema Handler, Payment Manager, Escrow Wallet,
Policy Engine, Receipt Store, Discovery, Identity Layer
- New CLI commands extend existing client: hive-client-lease,
hive-client-jit, hive-client-swap, hive-client-insure
- Schema Translation Layer maps hive:liquidity/* to CLN/LND RPCs
- Single status command shows management + liquidity contracts
- No separate liquidity client exists or is needed
2. NOSTR AS FIRST-CLASS MARKETPLACE TRANSPORT
- 6 dedicated event kinds (38900-38905):
38900: Liquidity Provider Profile (replaceable)
38901: Liquidity Offer (replaceable, per-offer)
38902: Liquidity RFP (public/anonymous/sealed-bid)
38903: Contract Confirmation (immutable record)
38904: Lease Heartbeat (optional public attestation)
38905: Provider Reputation Summary
- Full tag schemas for relay-side filtering
- Privacy: anonymous browsing, throwaway keys, sealed-bid encryption
- DID-Nostr binding prevents impersonation
- Client discovery pipeline queries Nostr automatically
- Comparison table highlights Nostr-native as key differentiator
Cross-references updated:
- DID-HIVE-CLIENT.md: Abstract + description reference liquidity
- DID-HIVE-MARKETPLACE.md: Nostr section references liquidity kinds
…rd reference New Section 14: Ecosystem Propagation — how the protocol IS the distribution channel for the agentic sovereignty stack: - 6-stage adoption funnel: discovery → first contract → DID provisioned → reputation earned → services offered → ecosystem amplification - Stack adoption table: what gets adopted at each touchpoint, with what user awareness level (critical: highest-value components adopted invisibly) - Why centralized competitors cannot match compounding network effects (products vs ecosystems; linear vs compounding network effects) - Nostr as propagation maximizer: surface area, zero-cost distribution, cross-pollination, composability, DID-Nostr bridge - Design implications: frictionless auto-provisioning, self-contained Nostr events, invisible upgrade path, visible reputation, consumer→provider DID-NOSTR-MARKETPLACE.md flagged as planned dedicated spec: - Forward reference in Section 11A header - Added to references section - Open question #15 on priority and timeline - Current liquidity event kinds (38900-38905) are authoritative until the dedicated spec consolidates across all marketplace service types Sections renumbered: 14→Propagation, 15→Roadmap, 16→Questions, 17→References
Liquidity Nostr events now designed for compatibility with existing Nostr marketplace NIPs: NIP-99 (Classified Listings) compatibility: - Kind 38901 uses NIP-99 price tag format: ["price", "3600", "sat", "month"] - Tag mapping table: title↔alt, price↔price, location↔regions, t↔t - Dual-kind strategy: providers MAY publish as both kind 38901 (native) AND kind 30402 (NIP-99) for general marketplace client visibility - Full kind 30402 example with markdown content + hive-specific tags NIP-15 (Nostr Marketplace) compatibility: - Provider profile maps to NIP-15 stall (kind 30017) - Liquidity offer maps to NIP-15 product (kind 30018, quantity: null) - Checkout flow maps to contract negotiation (NIP-44 DMs) - Full stall + product examples for Plebeian Market / NostrMarket Compatibility strategy summary table showing what 4 client types see: - Hive-aware: full protocol (native kinds 38900-38905) - NIP-99 client: classified listings with price/description - NIP-15 client: stall + products with structured checkout - Generic Nostr: searchable notes via t tags + alt text DID-NOSTR-MARKETPLACE.md forward reference updated to require NIP-15/99 compatibility and reference Plebeian Market + LNbits NostrMarket patterns. References added: NIP-15, NIP-99, Plebeian Market, LNbits NostrMarket.
…sor + liquidity services 8th spec in the protocol suite. Consolidates and supersedes Nostr sections from DID-HIVE-MARKETPLACE.md and DID-HIVE-LIQUIDITY.md. - Advisor event kinds 38380-38385 (parallel to liquidity 38900-38905) - 4-layer spam resistance (PoW, DID bonds, rate limiting, client scoring) - NIP-40 expiration, NIP-09 deletion, lifecycle management - Full NIP-15/NIP-99/NIP-44 compatibility with dual-publishing strategy - DID-Nostr binding via Archon attestation credentials - Progressive client enhancement (Level 0-3) - Relay strategy, privacy mechanisms, sealed-bid RFPs
…hold, group vaults)
Final integration of traffic intelligence (Task 8): - Import TrafficIntelligenceManager and 4 RPC functions - Add global variable and instantiation after anticipatory_liquidity_mgr - Register 4 RPC methods: report-traffic-profile, traffic-intelligence, check-rebalance-conflict (upgraded), fleet-demand-forecast - Add TRAFFIC_INTELLIGENCE_BATCH dispatch in _dispatch_hive_message - Inject traffic_intel_mgr into protocol_handlers and background_loops - Pass traffic_intel_mgr to HiveContext construction - Wire 6-hour broadcast timer in fee_intelligence_loop Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…d variable - Remove unused `import hashlib` (I-1) - Fix quiet-hour window midnight wrap using modulo 24 (I-2) - Remove unused `timestamp` variable in handle_batch (S-1) Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
… plan 11-task TDD plan covering: - Revenue-ops: 4 new hive bridge methods, flow analysis profile graduation, rebalancer/fee-controller/capacity-planner integration - cl-hive Phase 3b: MCF scheduling with traffic intelligence - cl-hive Phase 3c: Size-aware fee enrichment No protocol changes. ~30 new tests across both repos.
…se 3b) MCF assignments now check traffic intelligence before ACK: skip on active fleet rebalancing conflict, defer up to 3 cycles during peer peak hours, then execute regardless. Adds TestMCFScheduling with 4 tests. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Add get_size_aware_adjustment() to FeeCoordinationManager that returns a 0.8-1.3x fee multiplier based on fleet traffic intelligence forward sizes. Large forwards (>500k sats) get a discount to attract whale traffic, small forwards (<10k sats) get a premium for HTLC slot cost, and high-volume peers (>10M sats/day) get a floor boost to protect capacity. Integrated as step 6b in get_fee_recommendation(). Added size_adjustment_pct field to FeeRecommendation dataclass. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Enables Phase 3c size-aware fee enrichment by injecting the TrafficIntelligenceManager into the fee coordination system. Placed after traffic_intel_mgr initialization to avoid forward reference.
… defers Code review fixes: - Pass assignment.amount_sats to check_rebalance_conflict (was 0) - Fetch pending assignments once, reuse for ACK (avoid double RPC) - Prune stale _mcf_defer_counts entries for expired assignments - Fix inverted drain direction mapping in design doc
Entrypoint now appends docker/config/cl-revenue-ops.conf (if present) to the generated lightning.conf, matching the existing cl-hive.conf pattern. Also uncomment comms/archon mounts in build compose. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Deduct pending channel_open proposals from available budget before proposing new expansions, preventing unfundable proposals from accumulating in the advisor queue. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Integrate get_pending_channel_open_total() into the planner's budget calculation so that pending channel_open proposals reduce the available budget, preventing double-spending on concurrent expansions. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…r tests Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.