L2ps implementation

.gitignore

@@ -181,6 +181,11 @@ docs/src
 src/features/bridges/EVMSmartContract/docs
 src/features/bridges/LiquidityTank_UserGuide.md
 local_tests
+docs/storage_features
+temp
+STORAGE_PROGRAMS_SPEC.md
+local_tests/
+claudedocs
 claudedocs
 docs/storage_features
 temp
@@ -196,4 +201,4 @@ REVIEWER_QUESTIONS_ANSWERED.md
 PR_REVIEW_RAW.md
 PR_REVIEW_FINAL.md
 PR_REVIEW_FINAL.md
-REVIEWER_QUESTIONS_ANSWERED.md
+REVIEWER_QUESTIONS_ANSWERED.md

.serena/memories/_index.md

@@ -0,0 +1,40 @@
+# Serena Memory Index - Quick Navigation
+
+## UD Integration (Current Work)
+- **ud_phases_tracking** - Complete phases 1-6 overview (Phase 5 done, Phase 6 pending)
+- **ud_phase5_complete** - Detailed Phase 5 implementation (most comprehensive)
+- **ud_integration_complete** - Current status, dependencies, next steps
+- **ud_technical_reference** - Networks, contracts, record keys, test data
+- **ud_architecture_patterns** - Resolution flow, verification, storage patterns
+- **ud_security_patterns** - Ownership verification, security checkpoints, attack prevention
+- **session_ud_points_implementation_2025_01_31** - UD points system implementation session
+- **session_ud_ownership_verification_2025_10_21** - UD ownership verification security fixes
+
+## Project Core
+- **project_purpose** - Demos Network node software overview
+- **tech_stack** - Languages, frameworks, tools
+- **codebase_structure** - Directory organization
+- **code_style_conventions** - Naming, formatting standards
+- **development_patterns** - Established code patterns
+
+## Development Workflow
+- **suggested_commands** - Common CLI commands
+- **task_completion_guidelines** - Workflow patterns
+
+## Memory Organization
+
+Each memory is atomic and self-contained. Reference specific memories based on domain:
+
+**For UD work**:
+1. Start with `ud_phases_tracking` for phase overview
+2. Check `ud_phase5_complete` for detailed Phase 5 implementation
+3. Use `ud_integration_complete` for current status and next steps
+4. Reference `ud_technical_reference` for configs/contracts
+5. Reference `ud_architecture_patterns` for implementation patterns
+6. Reference `ud_security_patterns` for security verification patterns
+7. Review recent sessions: `session_ud_ownership_verification_2025_10_21`
+
+**For general development**:
+- Project info: `project_purpose`, `tech_stack`, `codebase_structure`
+- Development: `development_patterns`, `code_style_conventions`
+- Commands: `suggested_commands`, `task_completion_guidelines`

.serena/memories/session_ud_ownership_verification_2025_10_21.md

@@ -0,0 +1,138 @@
+# Session: UD Domain Ownership Verification - October 21, 2025
+
+## Session Overview
+**Duration**: ~1 hour  
+**Branch**: `ud_identities`  
+**Commit**: `2ac51f02` - fix(ud): add ownership verification to deductUdDomainPoints and fix import path
+
+## Work Completed
+
+### 1. Code Review Analysis
+**Reviewer Concerns Analyzed**:
+1. UD domain ownership verification missing in `deductUdDomainPoints` (LEGITIMATE)
+2. Import path using explicit `node_modules/` path in udIdentityManager.ts (LEGITIMATE)
+
+### 2. Security Implementation
+**File**: `src/features/incentive/PointSystem.ts`
+
+**Changes**:
+- Added UDIdentityManager import for domain resolution
+- Implemented blockchain-verified ownership check in `deductUdDomainPoints()`
+- Verification flow:
+  1. Get user's linked wallets from GCR via `getUserIdentitiesFromGCR()`
+  2. Resolve domain on-chain via `UDIdentityManager.resolveUDDomain()`
+  3. Extract wallet addresses from linkedWallets format ("chain:address")
+  4. Verify at least one user wallet matches domain's authorized addresses
+  5. Handle case-sensitive comparison for Solana, case-insensitive for EVM
+  6. Return 400 error if ownership verification fails
+  7. Only proceed with point deduction if verified
+
+**Security Vulnerability Addressed**:
+- **Before**: Users could deduct points for domains they no longer own after transfer
+- **After**: Blockchain-verified ownership required before point deduction
+- **Impact**: Prevents points inflation from same domain generating multiple points across accounts
+
+### 3. Infrastructure Fix
+**File**: `src/libs/blockchain/gcr/gcr_routines/udIdentityManager.ts`
+
+**Changes**:
+- Line 3: Fixed import path from `node_modules/@kynesyslabs/demosdk/build/types/abstraction` to `@kynesyslabs/demosdk/build/types/abstraction`
+- Line 258: Made `resolveUDDomain()` public (was private) to enable ownership verification from PointSystem
+
+**Rationale**:
+- Explicit node_modules paths break module resolution across different environments
+- Public visibility required for PointSystem to verify domain ownership on-chain
+
+## Technical Decisions
+
+### Why UD Domains Need Ownership Verification
+**Key Insight**: UD domains are NFTs (blockchain assets) that can be transferred/sold
+
+**Vulnerability Scenario**:
+1. Alice links `alice.crypto` → earns 3 points ✅
+2. Alice transfers domain to Bob on blockchain 🔄
+3. Bob links `alice.crypto` → earns 3 points ✅
+4. Alice unlinks without ownership check → keeps 3 points ❌
+5. **Result**: Same domain generates 6 points (should be max 3)
+
+**Solution**: Match linking security pattern
+- Linking: Verifies signature from authorized wallet via `UDIdentityManager.verifyPayload()`
+- Unlinking: Now verifies current ownership via `UDIdentityManager.resolveUDDomain()`
+
+### Implementation Pattern
+**Ownership Verification Strategy**:
+```typescript
+// 1. Get user's linked wallets from GCR
+const { linkedWallets } = await this.getUserIdentitiesFromGCR(userId)
+
+// 2. Resolve domain to get current on-chain authorized addresses
+const domainResolution = await UDIdentityManager.resolveUDDomain(normalizedDomain)
+
+// 3. Extract wallet addresses (format: "chain:address" → "address")
+const userWalletAddresses = linkedWallets.map(wallet => wallet.split(':')[1])
+
+// 4. Verify ownership with chain-specific comparison
+const isOwner = domainResolution.authorizedAddresses.some(authAddr =>
+    userWalletAddresses.some(userAddr => {
+        // Solana: case-sensitive base58
+        if (authAddr.signatureType === "solana") {
+            return authAddr.address === userAddr
+        }
+        // EVM: case-insensitive hex
+        return authAddr.address.toLowerCase() === userAddr.toLowerCase()
+    })
+)
+```
+
+## Validation Results
+- **ESLint**: ✅ No errors in modified files
+- **Type Safety**: ✅ All changes type-safe
+- **Import Verification**: ✅ UDIdentityAssignPayload confirmed exported from SDK
+- **Pattern Consistency**: ✅ Matches linking flow security architecture
+
+## Files Modified
+1. `src/features/incentive/PointSystem.ts` (+56 lines)
+   - Added UDIdentityManager import
+   - Implemented ownership verification in deductUdDomainPoints()
+
+2. `src/libs/blockchain/gcr/gcr_routines/udIdentityManager.ts` (+2, -2 lines)
+   - Fixed import path (line 3)
+   - Made resolveUDDomain() public (line 258)
+
+## Key Learnings
+
+### UD Domain Resolution Flow
+**Multi-Chain Priority**:
+1. Polygon UNS → Base UNS → Sonic UNS → Ethereum UNS → Ethereum CNS
+2. Fallback to Solana for .demos and other Solana domains
+3. Returns UnifiedDomainResolution with authorizedAddresses array
+
+### Points System Security Principles
+1. **Consistency**: Award and deduct operations must have matching security
+2. **Blockchain Truth**: On-chain state is source of truth for ownership
+3. **Chain Awareness**: Different signature validation (case-sensitive Solana vs case-insensitive EVM)
+4. **Error Clarity**: Return meaningful 400 errors when verification fails
+
+### Import Path Best Practices
+- Never use explicit `node_modules/` paths in TypeScript imports
+- Use package name directly: `@kynesyslabs/demosdk/build/types/abstraction`
+- Ensures module resolution works across all environments (dev, build, production)
+
+## Project Context Updates
+
+### UD Integration Status
+- **Phase 5**: Complete (domain linking with multi-chain support)
+- **Security Enhancement**: Ownership verification now complete for both award and deduct flows
+- **Points Integrity**: Protected against domain transfer abuse
+
+### Related Memories
+- `ud_integration_complete`: Base UD domain integration
+- `ud_phase5_complete`: Multi-chain UD support completion
+- `ud_technical_reference`: UD resolution and verification patterns
+- `ud_architecture_patterns`: UD domain system architecture
+
+## Next Potential Work
+1. Consider adding similar ownership verification for Web3 wallet deduction
+2. Review other identity deduction flows for consistency
+3. Add integration tests for UD ownership verification edge cases
+4. Document ownership verification requirements in API documentation

.serena/memories/session_ud_points_implementation_2025_01_31.md

@@ -0,0 +1,103 @@
+# UD Domain Points Implementation Session
+
+**Date**: 2025-01-31
+**Branch**: ud_identities
+**Commit**: c833679d
+
+## Task Summary
+Implemented missing UD domain points methods in PointSystem to resolve TypeScript errors identified during pre-existing issue analysis.
+
+## Implementation Details
+
+### Point Values Added
+- `LINK_UD_DOMAIN_DEMOS: 3` - For .demos TLD domains
+- `LINK_UD_DOMAIN: 1` - For other UD domains
+
+### Methods Implemented
+
+#### 1. awardUdDomainPoints(userId, domain, referralCode?)
+**Location**: src/features/incentive/PointSystem.ts:866-934
+**Functionality**:
+- TLD-based point determination (.demos = 3, others = 1)
+- Duplicate domain linking detection
+- Referral code support
+- Integration with GCR via addPointsToGCR()
+- Returns RPCResponse with points awarded and total
+
+#### 2. deductUdDomainPoints(userId, domain)
+**Location**: src/features/incentive/PointSystem.ts:942-1001
+**Functionality**:
+- TLD-based point determination
+- Domain-specific point tracking verification
+- GCR integration for point deduction
+- Returns RPCResponse with points deducted and total
+
+### Type System Updates
+
+#### 1. GCR_Main Entity (src/model/entities/GCRv2/GCR_Main.ts)
+- Added `udDomains: { [domain: string]: number }` to breakdown (line 36)
+- Added `telegram: number` to socialAccounts (line 34)
+
+#### 2. SDK Types (sdks/src/types/abstraction/index.ts)
+- Added `udDomains: { [domain: string]: number }` to UserPoints breakdown (line 283)
+
+#### 3. Local UserPoints Interface (PointSystem.ts:12-33)
+- Created local interface matching GCR entity structure
+- Includes all fields: web3Wallets, socialAccounts (with telegram), udDomains, referrals, demosFollow
+
+### Infrastructure Updates
+
+#### Extended addPointsToGCR()
+- Added "udDomains" type support (line 146)
+- Implemented udDomains breakdown handling (lines 221-228)
+
+#### Updated getUserPointsInternal()
+- Added udDomains initialization in breakdown return (line 130)
+- Added telegram to socialAccounts initialization (line 128)
+
+## Integration Points
+
+### IncentiveManager Hooks
+The implemented methods are called by existing hooks in IncentiveManager.ts:
+- `udDomainLinked()` → calls `awardUdDomainPoints()`
+- `udDomainUnlinked()` → calls `deductUdDomainPoints()`
+
+## Testing & Validation
+- ✅ TypeScript compilation: All UD-related errors resolved
+- ✅ ESLint: All files pass linting
+- ✅ Pattern consistency: Follows existing web3Wallets/socialAccounts patterns
+- ✅ Type safety: Local UserPoints interface matches GCR entity structure
+
+## Technical Decisions
+
+### Why Local UserPoints Interface?
+Created local interface instead of importing from SDK to:
+1. Avoid circular dependency issues during development
+2. Ensure type consistency with GCR entity structure
+3. Enable rapid iteration without SDK rebuilds
+4. Maintain flexibility for future type evolution
+
+Note: Added FIXME comment for future SDK import migration
+
+### Domain Identification Logic
+Uses `domain.toLowerCase().endsWith(".demos")` for TLD detection:
+- Simple and reliable
+- Case-insensitive
+- Minimal processing overhead
+
+## Files Modified
+1. src/features/incentive/PointSystem.ts (+182 lines)
+2. src/model/entities/GCRv2/GCR_Main.ts (+2 lines)
+3. sdks/src/types/abstraction/index.ts (+1 line)
+
+## Commit Information
+```
+feat(ud): implement UD domain points system with TLD-based rewards
+Commit: c833679d
+```
+
+## Session Metadata
+- Duration: ~45 minutes
+- Complexity: Moderate (extending existing system)
+- Dependencies: GCR entity, IncentiveManager, SDK types
+- Risk Level: Low (follows established patterns)