feat: add marketplace metrics, privacy features, and service registry endpoints

- Add Prometheus metrics for marketplace API throughput and error rates with new dashboard panels
- Implement confidential transaction models with encryption support and access control
- Add key management system with registration, rotation, and audit logging
- Create services and registry routers for service discovery and management
- Integrate ZK proof generation for privacy-preserving receipts
- Add metrics instru

docs/reference/zk-technology-comparison.md

@@ -0,0 +1,181 @@
+# ZK Technology Comparison for Receipt Attestation
+
+## Overview
+
+Analysis of zero-knowledge proof systems for AITBC receipt attestation, focusing on practical considerations for integration with existing infrastructure.
+
+## Technology Options
+
+### 1. zk-SNARKs (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge)
+
+**Examples**: Groth16, PLONK, Halo2
+
+**Pros**:
+- **Small proof size**: ~200 bytes for Groth16
+- **Fast verification**: Constant time, ~3ms on-chain
+- **Mature ecosystem**: circom, snarkjs, bellman, arkworks
+- **Low gas costs**: ~200k gas for verification on Ethereum
+- **Industry adoption**: Used by Aztec, Tornado Cash, Zcash
+
+**Cons**:
+- **Trusted setup**: Required for Groth16 (toxic waste problem)
+- **Longer proof generation**: 10-30 seconds depending on circuit size
+- **Complex setup**: Ceremony needs multiple participants
+- **Quantum vulnerability**: Not post-quantum secure
+
+### 2. zk-STARKs (Zero-Knowledge Scalable Transparent Argument of Knowledge)
+
+**Examples**: STARKEx, Winterfell, gnark
+
+**Pros**:
+- **No trusted setup**: Transparent setup process
+- **Post-quantum secure**: Resistant to quantum attacks
+- **Faster proving**: Often faster than SNARKs for large circuits
+- **Transparent**: No toxic waste, fully verifiable setup
+
+**Cons**:
+- **Larger proofs**: ~45KB for typical circuits
+- **Higher verification cost**: ~500k-1M gas on-chain
+- **Newer ecosystem**: Fewer tools and libraries
+- **Less adoption**: Limited production deployments
+
+## Use Case Analysis
+
+### Receipt Attestation Requirements
+
+1. **Proof Size**: Important for on-chain storage costs
+2. **Verification Speed**: Critical for settlement latency
+3. **Setup Complexity**: Affects deployment timeline
+4. **Ecosystem Maturity**: Impacts development speed
+5. **Privacy Needs**: Moderate (hiding amounts, not full anonymity)
+
+### Quantitative Comparison
+
+| Metric | Groth16 (SNARK) | PLONK (SNARK) | STARK |
+|--------|----------------|---------------|-------|
+| Proof Size | 200 bytes | 400-500 bytes | 45KB |
+| Prover Time | 10-30s | 5-15s | 2-10s |
+| Verifier Time | 3ms | 5ms | 50ms |
+| Gas Cost | 200k | 300k | 800k |
+| Trusted Setup | Yes | Universal | No |
+| Library Support | Excellent | Good | Limited |
+
+## Recommendation
+
+### Phase 1: Groth16 for MVP
+
+**Rationale**:
+1. **Proven technology**: Battle-tested in production
+2. **Small proofs**: Essential for cost-effective on-chain verification
+3. **Fast verification**: Critical for settlement performance
+4. **Tool maturity**: circom + snarkjs ecosystem
+5. **Community knowledge**: Extensive documentation and examples
+
+**Mitigations for trusted setup**:
+- Multi-party ceremony with >100 participants
+- Public documentation of process
+- Consider PLONK for Phase 2 if setup becomes bottleneck
+
+### Phase 2: Evaluate PLONK
+
+**Rationale**:
+- Universal trusted setup (one-time for all circuits)
+- Slightly larger proofs but acceptable
+- More flexible for circuit updates
+- Growing ecosystem support
+
+### Phase 3: Consider STARKs
+
+**Rationale**:
+- If quantum resistance becomes priority
+- If proof size optimizations improve
+- If gas costs become less critical
+
+## Implementation Strategy
+
+### Circuit Complexity Analysis
+
+**Basic Receipt Circuit**:
+- Hash verification: ~50 constraints
+- Signature verification: ~10,000 constraints
+- Arithmetic operations: ~100 constraints
+- Total: ~10,150 constraints
+
+**With Privacy Features**:
+- Range proofs: ~1,000 constraints
+- Merkle proofs: ~1,000 constraints
+- Additional checks: ~500 constraints
+- Total: ~12,650 constraints
+
+### Performance Estimates
+
+**Groth16**:
+- Setup time: 2-5 hours
+- Proving time: 5-15 seconds
+- Verification: 3ms
+- Proof size: 200 bytes
+
+**Infrastructure Impact**:
+- Coordinator: Additional 5-15s per receipt
+- Settlement layer: Minimal impact (fast verification)
+- Storage: Negligible increase
+
+## Security Considerations
+
+### Trusted Setup Risks
+
+1. **Toxic Waste**: If compromised, can forge proofs
+2. **Setup Integrity**: Requires honest participants
+3. **Documentation**: Must be publicly verifiable
+
+### Mitigation Strategies
+
+1. **Multi-party Ceremony**: 
+   - Minimum 100 participants
+   - Geographically distributed
+   - Public livestream
+
+2. **Circuit Audits**:
+   - Formal verification where possible
+   - Third-party security review
+   - Public disclosure of circuits
+
+3. **Gradual Rollout**:
+   - Start with low-value transactions
+   - Monitor for anomalies
+   - Emergency pause capability
+
+## Development Plan
+
+### Week 1-2: Environment Setup
+- Install circom and snarkjs
+- Create basic test circuit
+- Benchmark proof generation
+
+### Week 3-4: Basic Circuit
+- Implement receipt hash verification
+- Add signature verification
+- Test with sample receipts
+
+### Week 5-6: Integration
+- Add to coordinator API
+- Create verification contract
+- Test settlement flow
+
+### Week 7-8: Trusted Setup
+- Plan ceremony logistics
+- Prepare ceremony software
+- Execute multi-party setup
+
+### Week 9-10: Testing & Audit
+- End-to-end testing
+- Security review
+- Performance optimization
+
+## Next Steps
+
+1. **Immediate**: Set up development environment
+2. **Research**: Deep dive into circom best practices
+3. **Prototype**: Build minimal viable circuit
+4. **Evaluate**: Performance with real receipt data
+5. **Decide**: Final technology choice based on testing