Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
81 changes: 81 additions & 0 deletions Comprehensive Vulnerability Assessment & Feature Roadmap
Original file line number Diff line number Diff line change
@@ -0,0 +1,81 @@
# 🚀 Pi Network Project - GitHub Issues Pack

## 1. 🔒 Security: Race Condition in process() Leading to Double Charge
**Problem:** Concurrent calls to `process()` may result in the same subscription being charged multiple times if `next_charge_ts` is not updated atomically before transfer.

**Risk:** * Double charging users.
* Financial inconsistency.
* Loss of user trust.

**Proposed Solution:** Update state before external calls (Checks-Effects-Interactions):
```rust
if now < subscription.next_charge_ts {
return skip;
}

subscription.next_charge_ts += period_secs;
subscription.service_end_ts += period_secs;

// Proceed with transfer logic

```
**Impact:** Prevents duplicate charges and ensures deterministic behavior.
## 2. 🔒 Security: Missing Reentrancy Protection
**Problem:** The contract may be vulnerable to reentrancy attacks via transfer_from.
**Risk:** * Multiple unintended executions.
* Potential draining of funds.
**Proposed Solution:** Implement a reentrancy guard or strictly follow the Checks-Effects-Interactions pattern.
```rust
bool locked;
require(!locked, "ReentrancyGuard: reentrant call");
locked = true;
// logic
locked = false;

```
**Impact:** Secures the contract from reentrancy exploits.
## 3. 🔒 Security: Allowance Drain Risk
**Problem:** Pre-approved token allowance may be abused if contract logic fails.
**Proposed Solution:** * Add strict assertion: assert(allowed_amount >= price);
* Optional: Implement max_charge_per_cycle to limit exposure.
**Impact:** Limits potential damage in case of unexpected contract behavior.
## 4. 🔒 Security: Timestamp Manipulation
**Problem:** Block timestamp may be slightly manipulated by validators/miners.
**Proposed Solution:** Introduce a tolerance window for time-based checks:
```rust
if now + tolerance < next_charge_ts {
return skip;
}

```
**Impact:** Prevents subtle timing-based exploitation.
## 5. ⚙️ Optimization: Unlimited Storage Growth
**Problem:** Subscriptions grow indefinitely, increasing storage requirements and execution costs over time.
**Proposed Solution:** * Implement logic to delete expired subscriptions after a predefined period (X time).
* Or introduce an off-chain archiving system.
**Impact:** Improves long-term scalability and reduces node performance overhead.
## 6. 💡 Feature: Grace Period for Failed Payments
**Problem:** Current logic may cancel subscriptions immediately upon a single failed payment.
**Proposed Solution:** * Introduce grace_period_secs.
* Implement a retry mechanism before permanent cancellation.
**Impact:** Improves User Experience (UX) and reduces subscriber churn.
## 7. ⚠️ Security: No Rate Limiting on Subscription Creation
**Problem:** Attackers can spam the network by creating a massive number of subscriptions.
**Proposed Solution:** Implement max_subscriptions_per_address limit.
**Impact:** Prevents ecosystem abuse and resource spamming.
## 8. ⚠️ Reliability: Event-State Inconsistency
**Problem:** Events might be emitted even if subsequent state changes fail or are reverted in certain environments.
**Proposed Solution:** Ensure all events are emitted only after successful state execution and validation.
**Impact:** Ensures accurate off-chain tracking for explorers and dashboards.
## 9. 💡 Feature: Partial Payment Handling
**Problem:** The system only supports binary outcomes: full payment or total failure.
**Proposed Solution:** * Support partial charges for insufficient balances.
* Implement a simple debt tracking mechanism.
**Impact:** Creates a more flexible and user-friendly financial model.
## 10. 🔒 Security: Admin Upgrade Centralization Risk
**Problem:** The upgrade() function is controlled by a single admin address, creating a single point of failure.
**Proposed Solution:** * Transition to a Multi-sig wallet for admin actions.
* Implement a Timelock (e.g., 48-hour delay) for all upgrades.
**Impact:** Increases project decentralization and community trust.
```