Feat/stellar explorer navigation

.kiro/specs/batch-notification-creation/.config.kiro

@@ -0,0 +1 @@
+{"specId": "batch-notification-creation", "workflowType": "requirements-first", "specType": "feature"}

.kiro/specs/batch-notification-creation/design.md

@@ -0,0 +1,90 @@
+# Design Document
+
+## Overview
+
+This design implements batch notification creation to improve efficiency and reduce gas costs for organizations creating multiple notifications.
+
+## Architecture
+
+### Function Signature
+
+```rust
+pub fn create_notification_batch(
+  env: &Env,
+  organization: Address,
+  notifications: Vec<NotificationParams>,
+  max_batch_size: u32,
+) -> Result<Vec<NotificationId>, Error>
+```
+
+### Data Structures
+
+```rust
+pub struct NotificationParams {
+    pub recipient: Address,
+    pub title: String,
+    pub content: String,
+    pub expiration: u64,
+}
+
+pub struct BatchResult {
+    pub created_ids: Vec<NotificationId>,
+    pub total_gas_used: u64,
+}
+```
+
+### Processing Flow
+
+1. **Validation Phase**
+   - Check authorization (only organization can create)
+   - Validate batch size (not exceeding max)
+   - Validate each notification parameters
+   - Validate recipient addresses
+
+2. **Creation Phase**
+   - Create notifications in loop
+   - Store each in persistent storage
+   - Collect IDs for return
+
+3. **Event Emission Phase**
+   - Emit event for each created notification
+   - Include batch metadata in events
+   - Maintain event order
+
+### Gas Optimization Strategies
+
+1. **Single State Write**: Batch all writes together
+2. **Minimal Copying**: Reuse parameters where possible
+3. **Efficient Storage**: Use vec operations instead of individual stores
+4. **Early Validation**: Fail fast before any state changes
+
+### Limitations
+
+- Maximum 100 notifications per batch (configurable)
+- All or nothing: batch fails if any notification fails
+- All recipients in a batch created in single transaction
+- Cannot mix different notification types in one batch
+
+## Error Handling
+
+```rust
+pub enum Error {
+    BatchSizeExceeded,      // > max_batch_size
+    EmptyBatch,            // 0 recipients
+    InvalidRecipient(usize), // Invalid recipient at index
+    InsufficientFunds,     // Not enough balance for batch
+    Unauthorized,          // Not organization owner
+}
+```
+
+## Gas Comparison
+
+**Individual Creations**: Creating 10 notifications individually
+- Per notification: ~5000 gas
+- Total: 50,000 gas
+
+**Batch Creation**: Creating 10 notifications in batch
+- Overhead: ~2000 gas
+- Per notification: ~3500 gas
+- Total: 37,000 gas
+- Savings: ~26%

.kiro/specs/batch-notification-creation/requirements.md

@@ -0,0 +1,75 @@
+# Requirements Document
+
+## Introduction
+
+This feature introduces a batch notification creation mechanism that allows organizations to create multiple notifications in a single transaction, improving efficiency and reducing gas costs.
+
+## Glossary
+
+- **Batch Operation**: Creating multiple notifications in a single transaction
+- **Recipient Array**: List of addresses or identifiers for notification recipients
+- **Gas Consumption**: Cost in network fees for executing blockchain operations
+- **Transaction**: Single atomic operation on the blockchain
+- **Notification Creation**: Process of registering a new notification in the system
+
+## Requirements
+
+### Requirement 1: Batch Creation Function
+
+**User Story:** As an organization administrator, I want to create multiple notifications in a single transaction, so that I can reduce operational overhead.
+
+#### Acceptance Criteria
+
+1. THE system SHALL support a createNotificationBatch() function
+2. THE function SHALL accept an array of notification parameters
+3. THE function SHALL process all notifications atomically
+4. IF any notification fails validation, THE entire batch SHALL be rejected
+5. IF the batch succeeds, ALL notifications SHALL be created
+
+### Requirement 2: Recipient Array Validation
+
+**User Story:** As a system administrator, I want invalid recipients to be rejected appropriately, so that malformed batches don't partially succeed.
+
+#### Acceptance Criteria
+
+1. THE system SHALL validate each recipient in the batch
+2. THE system SHALL reject recipients with invalid format
+3. THE system SHALL reject empty recipient arrays
+4. THE system SHALL reject null or undefined recipients
+5. THE system SHALL support configurable maximum batch size (e.g., 100 recipients per batch)
+6. IF validation fails for any recipient, THE entire batch SHALL be rejected
+
+### Requirement 3: Event Emission
+
+**User Story:** As an off-chain listener, I want events for each created notification, so that I can track all creations.
+
+#### Acceptance Criteria
+
+1. THE system SHALL emit a creation event for each notification in the batch
+2. THE events SHALL be emitted in the same transaction
+3. EACH event SHALL include the notification ID and recipient
+4. THE event order SHALL match the input batch order
+
+### Requirement 4: Gas Efficiency
+
+**User Story:** As a cost-conscious organization, I want batch creation to reduce gas costs, so that my operational expenses are lower.
+
+#### Acceptance Criteria
+
+1. BATCH creation SHALL consume less gas per notification than individual creations
+2. GAS savings SHALL be at least 20% for typical batches
+3. THE system SHALL NOT include unnecessary data in batch operations
+4. LARGER batches SHALL have proportionally greater gas savings
+
+### Requirement 5: Testing and Documentation
+
+**User Story:** As a developer, I want comprehensive tests and documentation, so that I can confidently use batch creation.
+
+#### Acceptance Criteria
+
+1. UNIT tests SHALL cover single and multiple notifications
+2. UNIT tests SHALL cover edge cases (empty batch, max size, invalid recipients)
+3. INTEGRATION tests SHALL verify batch creation end-to-end
+4. BENCHMARK tests SHALL measure gas consumption
+5. DOCUMENTATION SHALL explain limitations and best practices
+6. DOCUMENTATION SHALL include examples for 10, 50, and 100 notification batches