Feature/economic system and rewards

[Steake]

No description provided.

[Copilot]

Pull request overview

This pull request introduces a comprehensive whitepaper audit document that validates the BitCell implementation against its v1.1 specification. The document serves as a technical compliance report for the RC1 (Release Candidate 1) milestone, specifically focusing on the economic system and rewards mechanism among other core components.

Key Changes:

• Adds detailed architecture documentation with Mermaid diagrams covering all system layers
• Provides complete feature matrix comparing whitepaper specifications to implementation status
• Documents the economic model including Bitcoin-style halving, reward distribution (60/30/10 split), and fee structure
• Identifies partial implementations and deviations with clear rationale
• Includes security analysis and prioritized recommendations for mainnet readiness

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The formula "R = r_m + s_m" should use consistent notation. Line 438 shows "R = r_m + s_m" in the diagram, but the subsequent calculations (lines 439-441) show "R+K" suggesting R is the sum. However, this is confusing because if R = r_m + s_m, the formulas should be clearer about whether K is added to R or to the denominator separately. The standard EBSL (Evidence-Based Subjective Logic) notation typically uses W = r + s (total weight) rather than R. Consider clarifying or using standard EBSL notation.

Suggested change

	OPINION --> |R = r_m + s_m| TOTAL
	TOTAL --> |belief = r_m / R+K| B
	TOTAL --> |disbelief = s_m / R+K| D
	TOTAL --> |uncertainty = K / R+K| U
	OPINION --> |W = r_m + s_m| TOTAL
	TOTAL --> |belief = r_m / (W+K)| B
	TOTAL --> |disbelief = s_m / (W+K)| D
	TOTAL --> |uncertainty = K / (W+K)| U

[Copilot]

Inconsistent notation: The decay mechanism shows "R --> |×0.99| R" and "S --> |×0.999| S" but earlier the variables were defined as "r_m" and "s_m". The diagram should use consistent variable names (either R/S or r_m/s_m throughout).

Suggested change

	R --> |×0.99| R
	S --> |×0.999| S
	r_m --> |×0.99| r_m
	s_m --> |×0.999| s_m

[Copilot]

The constraint "w*(w-1)*(w-2)=0" validates that winner ID is in {0, 1, 2}, but this should be clarified. According to the formula, valid values are w=0, w=1, or w=2. However, in most tournament contexts, there might be only 2 players (0 or 1), or there could be a draw (2). The documentation should clarify what these values represent (e.g., "0 = Player A wins, 1 = Player B wins, 2 = Draw").

Suggested change

	| Winner ID validation | Constraint: `w*(w-1)*(w-2)=0` | ✅ | |
	| Winner ID validation | Constraint: `w*(w-1)*(w-2)=0` | ✅ | 0 = Player A wins, 1 = Player B wins, 2 = Draw |

[Copilot]

Inconsistent terminology: The document uses both "zkSNARK" (line 887) and "SNARK" (line 911, 971) interchangeably. While technically SNARKs can be non-zero-knowledge, in this context they appear to refer to zkSNARKs. Consider standardizing the terminology throughout the document for clarity.

[Copilot]

Inconsistent pluralization: "Recursive SNARK Aggregation" (line 911) vs "Recursive SNARKs" (line 918). Should be consistent - either "Recursive SNARK Aggregation" or "Recursive SNARKs Aggregation" throughout this section.

Suggested change

	- Recursive SNARKs require significant R&D
	- Recursive SNARK Aggregation requires significant R&D

[Copilot]

Missing explanation: The "Privacy Premium" multiplier (line 673) is mentioned but not explained in context. The documentation should clarify what "Private Contract" means in this system and why it requires a 2x gas multiplier. Is this related to ring signatures or some other privacy feature?

[Steake]

@copilot open a new pull request to apply changes based on the comments in this thread

[Copilot]

@Steake I've opened a new pull request, #34, to work on those changes. Once the pull request is ready, I'll request review from you.