diff --git a/EIPS/eip-7833.md b/EIPS/eip-7833.md
new file mode 100644
index 00000000000000..02cea578e9d305
--- /dev/null
+++ b/EIPS/eip-7833.md
@@ -0,0 +1,79 @@
+---
+eip: 7833
+title: Scheduled function calls
+description: Giving life to smart contracts by enabling their functions to be automatically invoked by block producers.
+author: Keyvan Kambakhsh (@keyvank), Nobitex Labs <labs@nobitex.ir>
+discussions-to: https://ethereum-magicians.org/t/eip-7833-scheduled-function-calls/21975
+status: Draft
+type: Standards Track
+category: Core
+created: 2024-12-06
+---
+
+## Abstract
+
+Ethereum's smart contracts enable users to delegate control of their funds to code, but these contracts require an external trigger to execute. Timing is often critical, and issues such as network delays or malicious behavior by block producers—like MEV attacks—can prevent timely execution. To address these challenges, this Ethereum Improvement Proposal (EIP) introduces a new opcode, OFFERCALL, which allows contracts to schedule function calls. When functions self-schedule, they exhibit bot-like behavior. These scheduled calls would offer ETH to block producers as an incentive to prioritize their execution over manually submitted transactions. If the offer is not fulfilled, the bot is deactivated until manually re-ignited by the owner. The EIP proposes enforcing the execution of scheduled calls as a requirement for block validity. This could help mitigate MEV attacks, as block producers would be compelled to execute bots that neutralize market manipulation within the blockchain.
+
+## Specification
+
+Adding bot-like behavior to an EVM function is achieved by recursively scheduling a call to the same function in the next block. We propose introducing a new EVM opcode, OFFERCALL, which, as the name implies, offers ETH to be burnt to the block producer of the next block in exchange for invoking a function. These offers are aggregated and ranked by the Ethereum node, with only the top N offers being retained; all others are discarded. Scheduled calls must be executed before any user transactions, with execution order determined by their rank in the sorted list. The offered ETH is burnt to prevent block producers from exploiting the system by scheduling calls that pay the offered amounts back to themselves.
+
+Here is a solidity example of how the usage of OFFERCALL would look like:
+
+```solidity=
+contract Bot {
+    uint256 offerPerCall;
+    
+    constructor(uint256 _offer) {
+        offerPerCall = _offer;
+        
+        // Ignite the bot with an initial invocation offer
+        offercall(update, offerPerCall);
+    }
+    
+    function setOffer(uint256 _offer) external {
+        offerPerCall = _offer;
+    }
+
+    function update() external {
+        // Do scheduled work
+
+        // The callee may reschedule itself in order to
+        // introduce a bot-like behavior.
+        // The callee has to be careful about its offer
+        // otherwise it may die.
+        offercall(update, offerPerCall);
+        
+        // Once an offercall fails, the contract owner
+        // may have to set a new offer by calling `setOffer`
+        // and then invoking the `update()` function again.
+    }
+}
+```
+
+An OFFERCALL fails in two situations:
+
+- The contract does not hold at least the offered amount of ETH.
+- The offered amount is not large enough to rank within the top N offers.
+
+In the case of a self-scheduling function, once an OFFERCALL fails, the bot is deactivated. The only way to revive it is for the contract owner to manually call the function again, likely with a higher offer.
+
+## Rationale
+
+The rationale behind this Ethereum Improvement Proposal (EIP) stems from the need to enhance the reliability and fairness of smart contract execution on the Ethereum network. While Ethereum’s smart contracts allow for a high degree of programmability and automation, the execution of these contracts often depends on external triggers, such as user transactions or network conditions. This dependency introduces significant challenges, particularly in situations where timing is critical or when malicious actors, like block producers, can exploit the system for profit.
+
+## Backwards Compatibility
+
+The introduction of the new OFFERCALL opcode in this EIP requires a network upgrade, as it adds new functionality that is not currently supported by the Ethereum Virtual Machine (EVM). This change will affect how smart contracts can schedule and incentivize the execution of specific function calls, introducing a new mechanism that block producers must accommodate.
+
+## Reference Implementation
+
+N/A
+
+## Security Considerations
+
+The main concern with this EIP is whether it could lead to centralization, as wealthier users might dominate execution priorities. Burning unfulfilled offers partly addresses this by preventing endless offers.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).