Conversation
- Add "How You Earn OCTO-D" table tracking all contribution types - Document Mission system flow with visual diagram - Add step-by-step first contribution guide - Add reputation benefits for core contributors - Clarify grants are paid in OCTO/OCTO-D tokens Addresses confusion about core contributions being tracked and rewarded.
- Create docs/research/ folder with README - Move ZKP and Cairo research reports to docs/research/ - Update Blueprint to include Research as Layer 0 (Feasibility) - Add Research Report artifact type to Blueprint - Update canonical workflow to include Research → Use Case path - Update repository topology to include research folder Research now sits before Use Cases in the workflow: Idea → Research (feasibility) → Use Case → RFC → Mission
Research Phase: - docs/research/ai-quota-marketplace-research.md Use Case: - docs/use-cases/ai-quota-marketplace.md RFCs (Draft): - rfcs/0100-ai-quota-marketplace.md - Core protocol spec - rfcs/0101-quota-router-agent.md - Agent-based routing spec This enables developers to trade AI API quotas using OCTO-W, creating immediate token utility and bootstrapping the network.
First implementation mission for AI Quota Marketplace. Acceptance criteria: - CLI tool for quota management - Local proxy server - Secure API key storage - OCTO-W balance display - Manual quota listing Links to RFC-0100 and RFC-0101.
1. quota-market-integration - Auto-purchase from market 2. token-swap-integration - OCTO-W swaps with OCTO-D/OCTO 3. multi-provider-support - Multiple API providers 4. custom-policy-engine - Custom routing policies 5. reputation-system - Trust scores and early multipliers Full MVE-to-production path now documented.
Research (ai-quota-marketplace-research.md): - Add Personas (Provider, Consumer, Router) - Add Latency Considerations section - Add Market Dynamics (fixed vs dynamic pricing) - Add Dispute Resolution mechanism - Add References section Use Case (ai-quota-marketplace.md): - Add References section RFC-0100 (ai-quota-marketplace.md): - Add Observability section (telemetry without PII) - Add Security & Privacy section - Add References section RFC-0101 (quota-router-agent.md): - Add Agent Communication Protocol (OpenAI-compatible local proxy) - Add Fallback & Retry Logic - Add Unified Provider Schema - Add References section - Update fallback chain in Open Questions Missions: - Add explicit Blockers/Dependencies to all mission files - Define clear dependencies between phases
Priority 1 - Settlement Model (RFC-0100): - Add Registry Decision (off-chain for MVE, on-chain for Phase 2) - Add Escrow Flow diagram - Add Dispute Resolution with slashing rules - Add State Machine diagrams (Listing, Purchase, Dispute) Priority 2 - Fix Prompt Privacy: - Remove "end-to-end encryption" claim - Explicitly state: Sellers see prompt content (trust assumption) - Add reference to Research for future TEE/ZK options Priority 3 - Cost Normalization: - Add Compute Units model weights (Research) - Add MODEL_WEIGHTS normalization (RFC-0101) - Add calculateCost function Priority 4 - Separate RFC vs Implementation: - Remove Phase 1/2/3 feature lists from RFCs - Reference Missions/Roadmap instead Priority 5 - Token Mint/Burn: - Add Mint/Burn rules table to Research - Define inflation control mechanism Priority 6 - State Machines: - Add formal state diagrams for Listing, Purchase, Dispute
RFC-0101 (Router Agent): - Add MODEL_LIMITS for context window validation - Add validateContext() function to fail fast before spending OCTO-W - Add AtomicBalance class with mutex for concurrency handling - Document race condition solution for concurrent requests RFC-0100 (Marketplace): - Add Dispute Evidence Challenge section - Document MVE solution: focus on automated verifications - Table of dispute types and verifiability - Note on response quality disputes requiring trust These were identified in final review as implementation considerations.
RFC-0100: - Convert Listing Lifecycle ASCII to Mermaid state diagram - Convert Purchase Lifecycle ASCII to Mermaid state diagram - Convert Dispute Lifecycle ASCII to Mermaid state diagram RFC-0101: - Convert Request Flow ASCII to Mermaid flowchart CLAUDE.md: - Add Documentation Standards section - Specify preference for Mermaid over ASCII art - Include example and conversion guidance
Research examining how Stoolap blockchain SQL database with ZK proofs could enhance the AI Quota Marketplace: - Documents Stoolap's current capabilities (Phase 1-3) - Identifies 5 integration opportunities: 1. Verifiable quote execution 2. Compressed proof marketplace 3. Confidential query operations 4. Decentralized listing registry 5. L2 rollup for scale - Proposes required changes to current Use Case and RFCs - Provides architecture diagram - Recommends phased integration approach
Fixes: 1. quota-market-integration.md: Convert ASCII to Mermaid flowchart 2. token-swap-integration.md: Convert ASCII to Mermaid flowchart New Missions (Stoolap Integration): 3. stoolap-provider-integration.md - Stoolap as provider type 4. zk-proof-verification.md - ZK proof verification system 5. onchain-registry-migration.md - Migrate to on-chain registry Updates: 6. build-first-agent.md: Add Status and clarify it's different track
- quota-router-mve.md: Change to Rust/Tokio stack - stoolap-provider-integration.md: Change to Rust - multi-provider-support.md: Convert to Rust + Mermaid diagram - reputation-system.md: Convert to Rust All quota marketplace missions now align with CipherOcto's Rust stack.
Research covering: - Starknet Wallet (Cairo-native) as recommended MVE option - EVM-compatible alternatives - Multi-sig/DAO options - Hybrid wallet approach - Integration with Stoolap using starknet-rs - Token standards on Starknet - Phased rollout recommendations
Refocused from consumer wallet apps to cryptographic foundations: - Starknet signature scheme (Stark Curve vs Ethereum secp256k1) - Account abstraction model (smart contract wallets) - Key derivation (BIP-32 adapted for Starknet) - Local key storage (AES-256-GCM, PBKDF2) - Transaction and message signing - Multi-sig/threshold signatures - Stoolap ZK proof verification integration - Phased implementation recommendations
RFC defining cryptographic primitives for CipherOcto wallet: - Key types and derivation (Starknet-style) - Transaction signing with Starknet ECDSA - AES-256-GCM + PBKDF2 for secure key storage - Account abstraction interface - Multi-sig support - Error handling patterns Implementation missions: 1. Core Wallet Cryptography 2. Secure Key Storage 3. Account Interface 4. CLI Integration
Fixes based on review: - Added OsRng entropy source for key generation - Added BIP-39 mnemonic recovery (12-word backup phrases) - Clarified "Stoolap" reference with project link - Added performance caveat for low-end hardware - Added hardware wallet path (Ledger/Trezor) details - Added rand and bip39 dependencies
Update to use GitHub URL instead of local path: - RFC-0102: https://github.com/CipherOcto/stoolap/tree/feat/blockchain-sql - wallet-technology-research.md: same URL
- Added cargo clippy with -D warnings - Added cargo fmt
Created use cases: - Compute Provider Network (OCTO-A): GPU providers monetize idle hardware - Storage Provider Network (OCTO-S): Encrypted persistent storage with ZK - Agent Marketplace (OCTO-D): Developers publish earning agents Each includes: - Token mechanics and pricing - Provider/agent types - Verification and slashing - Relationship to other components - Implementation path
Created use cases: - Bandwidth Provider Network (OCTO-B): Edge/relay/CDN nodes - Data Marketplace: Monetize datasets with privacy control - Orchestrator Role (OCTO-O): Task routing and coordination - Node Operations (OCTO-N): Validator/RPC/archive nodes - Enterprise Private AI: Compliance-native deployment All use cases include: - Token mechanics - Provider/node types - Verification and slashing - Requirements and incentives
Analysis of Giza's zkML framework: - Circle STARKs / Stwo prover for computational integrity - AIR-based proof generation - Verification options (Rust, WASM, Cairo, EigenLayer) Integration opportunities identified: 1. Privacy upgrade path - selective disclosure without revealing prompts 2. Verifiable quality/disputes - proof of correct execution 3. Starknet/Cairo alignment - natural fit (already chosen in RFC-0102) 4. Agent verifiability - "verifiable intelligence" narrative New use cases proposed: - Verifiable AI Agents (DeFi) - Privacy-Preserving Query Routing - Provable Quality of Service Implementation phases recommended.
Created use cases based on zkML integration opportunities: 1. Verifiable AI Agents for DeFi: - ZK proofs of trading decisions - On-chain verification - Strategy adherence proofs - Dispute resolution with cryptographic evidence 2. Privacy-Preserving Query Routing: - Client-side encryption - Commitment-based routing (seller sees nothing) - Selective disclosure - Compliance mapping (SOC2, HIPAA, GDPR) 3. Provable Quality of Service: - Latency proofs with timestamps - Uptime verification - Output validity proofs - On-chain SLA enforcement with automatic refunds
Technical analysis covering: - Proof systems (Hexary + STARK vs zkML) - Commitment schemes (Pedersen vs LogUp) - Architecture comparison - Feature matrix - Complementary capabilities - CipherOcto integration recommendations Key findings: - Stoolap: database integrity, confidential queries - LuminAIR: ML inference verification - Both use Stwo/M31 - natural synergy - Recommended: combine both for CipherOcto
Added benchmark data: - Stoolap: ~25-28s proving, ~15ms verification (merkle batch) - LuminAIR: benchmarks exist but results published to web UI Key insight: systems prove different things (DB vs ML) - not directly comparable
Key finding: - Stoolap: proves Cairo programs (sto2-cairo-prover) - LuminAIR: proves direct AIR (no Cairo) This is a critical technical distinction for CipherOcto's on-chain verification strategy.
Detailed analysis covering: - AIR fundamentals and concepts - All 11 primitive operators - Constraint types (consistency, transition, interaction) - LogUp for data flow integrity - Lookup tables for efficiency - Code examples from AddComponent - Cairo vs Direct AIR comparison - Implications for CipherOcto
Covers three implementations: 1. Ingonyama ICICLE-Stwo: 3x-7x speedup, drop-in backend 2. Nethermind stwo-gpu: ~193% multi-GPU efficiency 3. AntChain NitrooZK-stwo: 22x-355x speedup, Cairo AIR support Analysis includes: - Architecture and code structure - Benchmark results - Setup instructions - Recommendations for CipherOcto
Comprehensive research on related/competitive projects in the decentralized AI infrastructure space.
Updated missions: - Added RFC-0102 (Wallet Cryptography) reference - zk-proof-verification: Added GPU acceleration options, Stoolap technical details - stoolap-provider-integration: Added research references RFC-0102 now referenced in: - quota-router-mve.md - token-swap-integration.md - multi-provider-support.md - reputation-system.md - custom-policy-engine.md - quota-market-integration.md - onchain-registry-migration.md
Status changed to: In Progress Claimant: AI Agent (Claude)
Refreshed codebase stats to reflect expanded knowledge graph.
Remove Cargo.lock from version tracking as it's a build artifact.
Comprehensive documentation covering architecture, core components, vector indexing (HNSW), payload filtering, quantization, distributed deployment, and API layer.
Comprehensive documentation covering MVCC transactions, indexing, cost-based optimizer, semantic query caching, time-travel queries, parallel execution, vector search, and storage layer.
Design for merging Qdrant's vector capabilities with Stoolap's SQL/MVCC engine, preserving blockchain features while adding quantization, sparse vectors, payload filtering, and GPU support. RFC covers: - Multiple storage backends (memory, mmap, rocksdb) - HNSW with quantization options - Sparse vectors and BM25 hybrid search - Payload filtering indexes - GPU acceleration - Blockchain feature preservation
Describes the problem of multiple systems for AI agents (vector DB + SQL + blockchain), motivation for CipherOcto, and the impact of implementing a unified storage solution. Links to RFC-0103.
Critical updates: - Clarify RocksDB as optional (Pure Rust by default) - Add Determinism & Consensus section (floating-point issues) - Add MVCC & Vector Index section (visibility-aware vectors) - Add Hybrid Query Optimization section (cost-based planning) - Add Vector Update/Delete Semantics section - Add License Compliance section (Apache 2.0 attribution) Use case updates: - Clarify latency metric (query execution only) - Add note about async proof generation - Add cost reduction calculation notes
Added three critical implementation warnings: 1. Merkle root performance at commit time - use incremental hashing 2. Auto-vacuum for HNSW tombstones - don't rely on manual COMPACT 3. Software float performance penalty - isolate to verification only
- Make auto-compaction mandatory (not optional) - Add configurable per-table thresholds - Add segment-merge philosophy from Qdrant - Add testing matrix (MVCC, determinism, Merkle, tombstone) - Add performance SLAs (<5s proof, <1s Merkle update) - Add benchmark targets to use case
- Add system views for monitoring (tombstone %, proof latency) - Add benchmark baselines section - Add fast-proof synchronous mode for small result sets - Add prototype priority list for highest-risk pieces
RFC updates: - Three-layer verification architecture (fast search → deterministic → proof) - Segment architecture for MVCC+HNSW (eliminates per-node visibility) - Improved Merkle strategy: ID + content hash - Simplified backends: start with in-memory + mmap only - Hard limit 30% tombstone threshold - Limited GPU scope: distance computation only - Reordered phases: hardest parts first - Added appendices: replication, query language, agent memory model Use case updates: - Clarified "no unified solution" claim - Updated latency to 50-120ms vs 150-400ms - Added strategic positioning section
- Segment merge policy with triggers and strategy - WAL format for vector operations - Vector index replication strategy (rebuild locally) - Deterministic re-ranking constraint (max 128 candidates)
- Expanded candidate sets for deterministic rerank (4xK, max 512) - Hierarchical Merkle tree per segment - Versioned segments for blockchain snapshots - WAL missing operations (IndexBuild, Compaction, Snapshot) - Statistics subsystem for query planner - Background task scheduler - SIMD specialization (AVX512/AVX2/NEON) - Vector storage layout (SoA vs AoS) - Performance targets (index build throughput, insert QPS)
- Require Prettier formatting for all markdown files - Ensure files end with newline - Consistent heading hierarchy
- Revised phases: persistence + quantization now in MVP (1-3) - Added consensus guarantees table (existence/ranking/results) - Added brute-force consensus fallback for strict verification - Reduced tombstone threshold from 25% to 15% - Updated use case code example to show async verification - Added MVP vs Future feature distinction - Clarified "Sovereign" vs Raft consensus
- Add Rollout Phases table to Use Case - Clarify Verifiable Memory is Phase 4 - Add Index Snapshot Shipping to RFC (recovery optimization)
- Add basic statistics collection (row counts, null counts) to Phase 1 MVP - Enables basic query planning for initial release - Also commits .gitignore update to exclude Cargo.lock
- Add cross-architecture consistency testing to Testing Strategy - Add WAL snapshot bandwidth estimate (2-5x) and trigger guidance (100K vectors/5min)
- Memory alignment guidance for SoA vectors (AVX2/AVX-512/NEON) - WAL bloat prevention strategies for vectors - Blake3 Merkle implementation notes with code examples
RFC-0103: - P0: Add WAL enum entries (IndexBuild, CompactionStart/Finish, SnapshotCommit) - P0: Add MTTR estimates table (<5min for <1M vectors) - P1: Specify statistics collection strategy (sampling, triggers, k-means for clusters) - P1: Add software float performance estimate for 512 candidates - Add Appendix D placeholder - Mark WAL enum completeness as Phase 1 P0 blocker Use Case: - Align Recall@10 with RFC (15% tombstone threshold) - Add storage cost calculation breakdown - Clarify latency range (50ms simple, 120ms complex) - Reframe SDK as downstream goal - Fix ZK vs Merkle terminology, add proof types explanation
Use Case: - Consolidate "Sovereign" definition (data ownership + local-first + private memory) - Add MVP vs Full capabilities table near top of document - Add RFC version reference (March 2026) for alignment tracking RFC-0103 already had: - WAL enum completeness (IndexBuild, Compaction, Snapshot) - MTTR estimates - Statistics collection strategy - Software float performance estimate - Appendix D placeholder
- Add table documenting all review items with status - Explicitly mark all P0/P1 items as implemented/specified - Clarify phase gates for each recommendation
Create 7 mission files for Unified Vector-SQL Storage Engine: - Phase 1: Core Engine MVP (critical) - Phase 2: Persistence (high) - Phase 3: Quantization (high) - Phase 4: Deterministic Verification (medium) - Phase 5: Hybrid Query Planner (medium) - Phase 6: Sparse Vectors / BM25 (medium) - Phase 7: GPU Support (future) Each mission includes acceptance criteria, technical details, and dependencies.
- Claimed by @claude-code - Worktree: /home/mmacedoeu/_w/ai/cipherocto-vector-impl - Branch: vector-phase1 - Implementation plan: docs/plans/2026-03-06-phase1-implementation-plan.md
- Update status from "Claimed" to "Completed" - Mark all 8 acceptance criteria as done - Add benchmark results and implementation details Phase 1 fully complete.
- Update status from "Open" to "Claimed" - Add claimant @claude-code - Mark Phase 1 as complete dependency
- Update status from Claimed to Completed - Mark all acceptance criteria as done (mmap, WAL, recovery, snapshot) - Add PR link for vector-phase2-persistence branch
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
1 participant
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.
Summary
Test Plan