From f9fede6594eaf8062228f574d68c6ace5c9d8d18 Mon Sep 17 00:00:00 2001
From: Chenxing Li <ChenxingLi@users.noreply.github.com>
Date: Thu, 11 Jan 2024 14:30:07 +0800
Subject: [PATCH] Fix Static Context Check for Internal Contracts (#132)

---
 CIPs/cip-132.md | 45 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 45 insertions(+)
 create mode 100644 CIPs/cip-132.md

diff --git a/CIPs/cip-132.md b/CIPs/cip-132.md
new file mode 100644
index 0000000..479fb5e
--- /dev/null
+++ b/CIPs/cip-132.md
@@ -0,0 +1,45 @@
+---
+CIP No.: 132
+Title: Fix Static Context Check for Internal Contracts
+Author: Chenxing Li (@ChenxingLi)
+Status: Draft
+Type: Spec Breaking
+Created: 2024-01-11
+---
+
+## Simple Summary
+This proposal aims to fix a specific bug related to static context checks.
+
+
+## Abstract
+The current implementation in Conflux's internal contracts presents a technical bug concerning the execution of internal functions. The functions without the `view` keyword are not supposed to be executed in a static context within the EVM. However, in the current implementation, the system only rejects the call if it is directly a static call (`staticcall`) but fails to account for scenarios where the outer layers of the call use `staticcall`, inadvertently creating a static context. This oversight can lead to unintended behaviors and compromises in contract execution. 
+
+This CIP proposes a fix to this bug by ensuring that these functions correctly identify and reject calls originating from any level of static context.
+
+## Motivation
+The motivation behind this CIP is to address an incorrect behaviour  in the Conflux protocol.
+
+## Specification
+Before this CIP, the internal contract's approach to verifying static context was limited to assessing the call type.
+
+After this CIP activated at a given block, the internal contract will enhance its verification process by considering both the static flag and the call type for determining the static context.
+## Rationale
+N/A
+
+## Backwards Compatibility
+This CIP is Spec Breaking.
+
+## Test Cases
+<!--Test cases for an implementation are mandatory for CIPs that are affecting consensus changes. Other CIPs can choose to include links to test cases if applicable.-->
+N/A
+
+## Implementation
+<!--The implementations must be completed before any CIP is given status "Final", but it need not be completed before the CIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details.-->
+N/A
+
+## Security Considerations
+<!--All CIPs must contain a section that discusses the security implications/considerations relevant to the proposed change. Include information that might be important for security discussions, surfaces risks and can be used throughout the life cycle of the proposal. E.g. include security-relevant design decisions, concerns, important discussions, implementation-specific guidance and pitfalls, an outline of threats and risks and how they are being addressed. CIP submissions missing the "Security Considerations" section will be rejected. a CIP cannot proceed to status "Final" without a Security Considerations discussion deemed sufficient by the reviewers.-->
+N/A
+
+## Copyright
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).