From a61623981a4245e0ffd4f45cb0ad9d9d4bae294c Mon Sep 17 00:00:00 2001 From: Mikers Date: Wed, 11 Dec 2024 12:20:54 -1000 Subject: [PATCH 1/3] Add Support for EIP-1153 (Transient Storage) in the FEVM (FIP-0097) (#1084) - Introduces support for EIP-1153: Transient Storage in the FEVM - Details lifecycle validation and implementation using `TLOAD` and `TSTORE` - Ensures compatibility with Ethereum contracts and tooling - Includes specifications, rationale, and considerations for adoption --- FIPS/fip-0097.md | 104 +++++++++++++++++++++++++++++++++++++++++++++++ README.md | 1 + 2 files changed, 105 insertions(+) create mode 100644 FIPS/fip-0097.md diff --git a/FIPS/fip-0097.md b/FIPS/fip-0097.md new file mode 100644 index 00000000..74912412 --- /dev/null +++ b/FIPS/fip-0097.md @@ -0,0 +1,104 @@ +--- +fip: "0097" +title: Add Support for EIP-1153 (Transient Storage) in the FEVM +author: Michael Seiler (@snissn), Steven Allen (@stebalien) +discussions-to: https://github.com/filecoin-project/FIPs/discussions/855 +status: Draft +type: Technical +category: Core +created: 2024-11-19 +--- + +# FIP-0097: Add Support for EIP-1153 (Transient Storage) in the FEVM + +## Simple Summary +This proposal introduces support for **[EIP-1153: Transient Storage](https://eips.ethereum.org/EIPS/eip-1153)** in the Filecoin Ethereum Virtual Machine (FEVM). Transient storage provides data storage during transaction execution, scoped strictly to the transaction and the contract utilizing it. To maintain compatibility with Ethereum contracts utilizing this feature, the FEVM will implement transient storage with lifecycle validation and isolation. + +## Abstract +EIP-1153 defines transient storage as temporary data accessible only during the originating transaction, cleared automatically at the end of the transaction. This FIP adapts transient storage to the FEVM using `TLOAD` and `TSTORE` opcodes, ensuring compatibility with Ethereum contracts and libraries that rely on this feature. Transient storage is scoped to the specific contract and transaction, ensuring that each contract’s transient storage is isolated. Nested contract calls cannot access the transient storage of other contracts, but reentrant calls to the same contract within a transaction will access the same transient storage space. Lifecycle validation mechanisms enforce this behavior, achieving functional equivalence with Ethereum’s implementation while maintaining seamless integration with Filecoin’s architecture. + +## Change Motivation +Transient storage offers developers temporary, transaction-scoped storage for managing intermediate states. One key benefit of this feature is its ability to improve the implementation of reentrancy locks, enhancing security by mitigating risks associated with multiple calls to a function within sub-transactions. This feature was introduced on Ethereum mainnet in March 2024 as part of the Cancun (Dencun) upgrade, making adopting this FIP important to align the FEVM with Ethereum’s evolving tooling and Solidity’s modern features. By implementing transient storage, the FEVM ensures a seamless developer experience while supporting advanced contract use cases and secure computing. + +While the FEVM implementation utilizes permanent storage for practical reasons, its lifecycle validation ensures it functionally replicates Ethereum’s transient storage. This enables compatibility with contracts and libraries that rely on `TLOAD` and `TSTORE` while supporting transaction-scoped data handling. + +## Specification + +### Opcode Descriptions + +#### `TLOAD` +- **Opcode Hex:** `0x5C` +- **Stack Input:** + - `key`: Location of the transient storage value to load +- **Stack Output:** + - `value`: Stored value or zero if no value exists +- **Description:** Retrieves the value associated with `key` in the transient storage for the current transaction. + +#### `TSTORE` +- **Opcode Hex:** `0x5D` +- **Stack Input:** + - `key`: Location to store the value + - `value`: Value to store +- **Output:** None +- **Description:** Stores `value` at the specified `key` in the transient storage for the current transaction. + +### Lifecycle Management +Transient storage is valid only within the context of a single transaction. A lifecycle mechanism tracks transaction metadata (`origin` and `nonce`) to enforce lifecycle validation. + +### Implementation Details +The FEVM implements transient storage using a lifecycle validation mechanism to ensure data remains accessible only during the originating transaction. This validation enforces the same behavior as Ethereum’s transient storage. Internally, transient storage relies on permanent storage to manage lifecycle data and state while ensuring functional adherence to Ethereum’s behavior. + +--- + +## Design Rationale + +The design adheres to the intent of EIP-1153 while adapting to Filecoin's architecture. The use of lifecycle validation ensures transient storage behaves as expected within the scope of a single transaction. This approach balances compatibility with Ethereum contracts and simplifies implementation within the existing FEVM architecture. + +Alternative designs, such as purely in-memory storage, were considered but deemed impractical due to technical implementation difficulties. + +## Backwards Compatibility +The addition of transient storage is fully backward-compatible. Existing contracts remain unaffected unless they utilize `TLOAD` and `TSTORE`. Contracts compiled with older Solidity versions will continue to execute without changes. + +At the time of writing, support for `TLOAD` and `TSTORE` in current versions of Solidity is only available using inline-assembly. Thus, it is an explicitly opt-in feature, rather than a feature that contract authors may unknowngly be enabling when bumping compiler version and EVM target. + +## Test Cases + +### Essential Tests +1. **Basic Functionality:** + - Verify `TLOAD` retrieves the correct value. + - Verify `TSTORE` writes data to the transient storage correctly. + - Verify `TLOAD` from an unitialized location returns the zero value. + +2. **Lifecycle Validation:** + - Verify that transient storage is automatically cleared and becomes inaccessible after the transaction ends. + - Verify that transient storage is properly cleared at the end of each transaction and any out-of-lifecycle data does not interfere with subsequent transaction operations. + - Verify that nested contracts have independent transient storage spaces can read and write independently. + - Verify that memory remains accessible and stable after contract reentry. + +--- + +## Security Considerations +Transient storage introduces minimal additional risk compared to existing state storage. Lifecycle validation ensures storage is inaccessible outside the originating transaction. Security measures include: +- Preventing out-of-bounds memory access. +- Ensuring transient storage clears properly after a transaction ends. +- Ensuring nested contracts do not have access to each other's memory spaces. + +--- + +## Incentive Considerations +By adding support for transient storage, this FIP improves the FEVM's compatibility with Ethereum and provides developers with useful functionality for transaction-scoped data handling. This feature enables capabilities outlined in EIP-1153, such as reentrancy locks, temporary approvals, on-chain address computation, and enhanced proxy call metadata handling. These improvements align with Filecoin's goal of enabling scalable and reliable decentralized applications. However, transient storage does not introduce or impact economic incentives within the network. + +--- + +## Product Considerations +Adding transient storage ensures compatibility with modern Ethereum tooling, attracting developers to Filecoin’s ecosystem. This feature supports the development of advanced smart contracts and storage-related services. This addition further solidifies Filecoin’s position as a robust EVM-compatible chain, enhancing its attractiveness to Ethereum developers and expanding its ecosystem of decentralized applications. + +--- + +## Implementation +The reference implementation, including `TLOAD` and `TSTORE`, is available in the following pull request: [filecoin-project/builtin-actors#1588](https://github.com/filecoin-project/builtin-actors/pull/1588). The implementation includes lifecycle validation and persistent backing for ease of use. + +--- + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). diff --git a/README.md b/README.md index 6f603d79..412192d5 100644 --- a/README.md +++ b/README.md @@ -131,3 +131,4 @@ This improvement protocol helps achieve that objective for all members of the Fi | [0092](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0092.md) | Non-Interactive PoRep | FIP | luca (@lucaniz), kuba (@Kubuxu), nicola (@nicola), nemo (@cryptonemo), volker (@vmx), irene (@irenegia), Alex North (@anorth), orjan (@Phi-rjan) | Final | | [0094](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0094.md) | Add Support for EIP-5656 (MCOPY Opcode) in the FEVM | FIP | Michael Seiler (@snissn), Raúl Kripalani (@raulk), Steven Allen (@stebalien) | Final | | [0095](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0095.md) | Add FEVM precompile to fetch beacon digest from chain history | FIP | @ZenGround0, Alex North (@anorth) | Final | +| [0097](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0097.md) | Add Support for EIP-1153 (Transient Storage) in the FEVM | FIP | Michael Seiler (@snissn), Steven Allen (@stebalien) | Draft | From 502b5c69a84cdc6b70bdff115e23560b21db159e Mon Sep 17 00:00:00 2001 From: Y Date: Fri, 13 Dec 2024 05:30:14 +0800 Subject: [PATCH 2/3] FIP-0096: Draft for convert fundraising remainder address(es) to keyless account actor(s) (#1080) --- FIPS/fip-0096.md | 104 +++++++++++++++++++++++++++++++++++++++++++++++ README.md | 1 + 2 files changed, 105 insertions(+) create mode 100644 FIPS/fip-0096.md diff --git a/FIPS/fip-0096.md b/FIPS/fip-0096.md new file mode 100644 index 00000000..9155e340 --- /dev/null +++ b/FIPS/fip-0096.md @@ -0,0 +1,104 @@ +--- +fip: "0096" +title: Convert fundraising remainder address(es) to keyless account actor(s) +author: Fatman13 (@fatman13) +discussions-to: https://github.com/filecoin-project/FIPs/discussions/1033 +status: Draft +type: Technical +category: Core +created: 2024-07-10 +--- + +# Convert fundraising remainder address(es) to keyless account actor(s) + +## Simple Summary + +Similar to [#901](https://github.com/filecoin-project/FIPs/discussions/901), covert fundraising remainder address [f0122](https://filfox.io/en/address/f0122) type from a multisig to account that is keyless (like f099). + + +## Abstract + +At the moment, the actor holding the fundraising remainder is a _multisig_ actor. All signers are account actors, secured by corresponding wallet keys. This setup leaves the ownership and control over the fundraising remainder to signers of the _multisig_ actor, which undermines the decentralized governance principle over network funds, and creates potential security leaks. Although the amount in the fundraising remainder account is feable to institute any meaningful Sybil attack, breaching of spec still greatly undermines the security of a decentralized network by dimishing the network's credibility and unevenly favoring one party of the network participants, which both inflict profound long-term damage to the network. + +This FIP proposes to alter the type of the fundraising remainder actor from the aforementioned multisig to a keyless account actor, and further transfer the ownership, control and governance of the funds reserved from the signers of the multisig back to the network's participants via community governance. + + +## Change Motivation + +Like how mining reserve is made into a keyless account and ready to be [potentially burned](https://github.com/filecoin-project/FIPs/discussions/1030), fundraising remainder address(es) is also in the linger troubled by similar dilemma described in motivation section of [#901](https://github.com/filecoin-project/FIPs/discussions/901). We compiled the following 4 motivations for the proposal... + +### 1. follow the spec + +Mining reserve in the Filecoin spec is described as the following... + +> It will be up to the community to determine in the future how to distribute those tokens, through Filecoin improvement proposals (FIPs) or similar decentralized decision-making processes. +> -- excerpts from #901 + +[fundraising remainder](https://spec.filecoin.io/#section-systems.filecoin_token.token_allocation) in the Filecoin spec is described as the following... + +> Of the Filecoin genesis block allocation, 10% of FIL_BASE were allocated for fundraising, of which 7.5% were sold in the 2017 token sale, and the 2.5% remaining were allocated for ecosystem development and potential future fundraising. + +Though paragraph about fundraising remainder didn't specifically articulate "up to the community to determine" as in mining reserve, by virtue of us being a crypto / blockchain community it can be assumed **by default** it is up to the community, ie FIP process, when no governance body was mentioned to oversight the distribution. + +### 2. governance + +> It is worth noting that when the spec was written and when the network was first launched, the FIP process was not yet well-designed or matured to support network governance, and significant improvements have been made since then. +> -- excerpts from #901 + +Similar to the point #901 made, this proposal is to amend the inadequacy that network in its early days has neglected. + +### 3. security + +> This also creates a security black hole in the network where if 2 out of the 3 signer keys of f090 are compromised by malicious actors, they may cause serious economic damage to the Filecoin network. +> -- excerpts from #901 + +Although the amount remaining in the fundraising remainder address(es) would not likely to cause serious economic damage as mining reserve would, there are still security concerns over whether governance could amend its mistake made in the past. + +### 4. operation + +> In addition, having the reserve holds in a multisig also means changes toward the mining reserve..., may need to be managed by the msig signers via signed transactions which is a huge operational overhead (and again against the principle). +> -- excerpts from #901 + +fundraising remainder address(es) face identical operation challenges as mining reserve too. One thing to note is that through investigation by one of the community contributors some (most) of the funds originally allocated to this address have already been moved, and this FIP doesn't propose to do anything about them. + +## Specification + +Convert fundraising remainder actor type from a _multisig_ to _account_ type. The new account actor should be keyless, like `f099`. + +```rust +pub struct State { + pub address: Address, +} +``` + +The new fundraising remainder actor will contain a self-reference to its ID address in the `address` field. + +## Design Rationale + +The choice of making fundraising remainder actor to be a keyless account type is to ensure that no single actor/entity owns the control over fundraising remainder. The use of fundraising remainder will be proposed and governed by the FIP process, and further adopted by the network via network upgrades. + +## Backwards Compatibility + +This change is not backwards compatible. Upon the activation of this FIP in a network upgrade: +- the actor type of fundraising remainder will be migrated from _multisig_ to _account_. +- the existing signers of the fundraising remainder multisig will no longer be able to perform operations on the actor + +## Test Cases + +- Get actor cid of fundraising remainder should return actor code cid of an `account` + +## Security Considerations + +This proposal improves the network security by removing the ownership and control of whatever it is the remaining of the 2.5% of the total network token supply in `f0122` from individuals and putting it under the control of network participants via the appropriate governance processes. Again, the proposal acknowledges that the security threats from Sybil attack perspective is slim, but not following spec is considered a much bigger threat as attackers don't really need to buy out the network, just the governance. + + +## Product Considerations + +This proposal places governance of the fundraising remainder funds entirely in hands of the network participants rather than key owners, thus providing greater transparency and assurance of community consultation and deliberation in appropriate future disbursement of the funds. And thus, the proposal sends out a strong signal that this is a network where spec is respected by words and by code, and restores some of the credibility lossed for failing to comply with the spec. + +## Implementation + +TODO + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). diff --git a/README.md b/README.md index 412192d5..37e72286 100644 --- a/README.md +++ b/README.md @@ -131,4 +131,5 @@ This improvement protocol helps achieve that objective for all members of the Fi | [0092](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0092.md) | Non-Interactive PoRep | FIP | luca (@lucaniz), kuba (@Kubuxu), nicola (@nicola), nemo (@cryptonemo), volker (@vmx), irene (@irenegia), Alex North (@anorth), orjan (@Phi-rjan) | Final | | [0094](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0094.md) | Add Support for EIP-5656 (MCOPY Opcode) in the FEVM | FIP | Michael Seiler (@snissn), Raúl Kripalani (@raulk), Steven Allen (@stebalien) | Final | | [0095](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0095.md) | Add FEVM precompile to fetch beacon digest from chain history | FIP | @ZenGround0, Alex North (@anorth) | Final | +| [0096](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0096.md) | Convert fundraising remainder address(es) to keyless account actor(s) | FIP | @Fatman13 | Draft | | [0097](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0097.md) | Add Support for EIP-1153 (Transient Storage) in the FEVM | FIP | Michael Seiler (@snissn), Steven Allen (@stebalien) | Draft | From ed13e3c8271c319828b3df302312383625f801ea Mon Sep 17 00:00:00 2001 From: Jon Date: Fri, 13 Dec 2024 06:44:15 -0800 Subject: [PATCH 3/3] FIP-0098: Simplify termination fee calculation to a fixed percentage of initial pledge (#1079) * Add fip draft without spec * Update spec * Update readme * Update func ref * Respond to review comments * Update README.md Co-authored-by: Jorge M. Soares <547492+jsoares@users.noreply.github.com> * - Update suggested term fee % to 8.5% - Update copy around "steady state" terminations - Add @jimpick as an author * Update FIPS/fip-draft_term_fee.md Co-authored-by: Adrian Lanzafame * Take FIP-0098 * Update FIPS/fip-0098.md * Update readme --------- Co-authored-by: Jorge M. Soares <547492+jsoares@users.noreply.github.com> Co-authored-by: Adrian Lanzafame Co-authored-by: Rod Vagg --- FIPS/fip-0098.md | 143 +++++++++++++++++++++++++++++++++++++++++++++++ README.md | 1 + 2 files changed, 144 insertions(+) create mode 100644 FIPS/fip-0098.md diff --git a/FIPS/fip-0098.md b/FIPS/fip-0098.md new file mode 100644 index 00000000..d81b8cfa --- /dev/null +++ b/FIPS/fip-0098.md @@ -0,0 +1,143 @@ +--- +fip: "0098" +title: Simplify termination fee calculation to a fixed percentage of initial pledge +author: @Schwartz10, @anorth, @jimpick +discussions-to: https://github.com/filecoin-project/FIPs/discussions/1036 +status: Draft +type: Technical +category: Core +created: 2024-09-26 +--- + + + +# FIP-0098: Simplify termination fee calculation to a fixed percentage of initial pledge + +## Simple Summary + + + +The termination fee for any given sector is calculated as a fixed percentage of the initial pledge held by that sector. The proposed penalty as a percentage of initial pledge is 8.5%. + +## Abstract + + + +Today, it is overly sophisticated and computationally expensive to compute termination fees for miner actors. As a result, DeFi applications that leverage miner actors must make major security and/or performance sacrifices in order to operate. + +This FIP addresses the issue by simplifying the calculation of the miner actor termination fee. The proposed new termination fee calculation uses a "percentage of pledge" strategy - where `termination fee = initial pledge * termination penalty %`. The proposed new termination penalty % is 8.5%. + +As a result, DeFi applications on Filecoin can operate with significantly better performance, UX, and economic security. Additionally, Filecoin economics and code implementations will be significantly simplified, as well as state bloat removed. + +## Change Motivation + + + +In the year+ since FEVM’s launch, we’ve seen a number of protocols use Miner Actors as collateral for lending or leasing applications. Economic security of applications being built on the FEVM is important for developing trust, and understanding precise collateral values for any given miner actor is critical for a DeFi protocol’s economic security. + +Today, it is: (1) computationally expensive, (2) economically sophisticated, and (3) impossible in a FEVM runtime to compute the maximum termination fee for a miner actor’s sectors. As a result, FEVM applications need to either (a) use heuristics to determine a collateral value for a miner (economically insecure), or (b) use off-chain solutions to compute collateral values (significantly bloating the surface area of attack vectors for any lending / leasing protocol). Both of these approaches make major sacrifices towards the economic security of FEVM applications that use miner actors as collateral. + +The two primary motivations to this FIP proposal are: + +1. Enabling a more efficient termination penalty calculation such that termination penalties can be computed (or returned by an FEVM precompile) in an FEVM runtime. This is important because it enables FEVM protocols that use Miner Actors as collateral to operate with better economic security because they can precisely estimate the value of Miner Actor collateral on-chain. +2. Changing the formula for calculating termination penalties to be simpler to compute. This is important because it allows both Storage Providers and FEVM actors that use Miner Actors as collateral to easily predict their economic riskiness. + +Additionally, this FIP intends to maintain the original motivations behind termination fees: + +1. Create a more resilient storage network for storage clients, such that if an SP stores a client's data, the client isn't just suddenly left out to dry and their data lost. +2. Network stability - disincentivize large power swings caused by rapid on/off-boarding of power and pledge. + + +## Specification + + + +A new constant variable called `TERM_PENALTY_PLEDGE_PERCENTAGE` should be created, which is fixed for the whole network and configurable by future governance. + +Refactor the [`pledge_penalty_for_termination`](https://github.com/filecoin-project/builtin-actors/blob/12d9af8a00d0909598c67e1a18dc1577e0833137/actors/miner/src/monies.rs#L179) method to: + +1. Take the sector's `initial_pledge` `TokenAmount` as an argument +2. Return `initial_pledge * TERM_PENALTY_PLEDGE_PERCENTAGE` + +This change would immediately apply to all sectors, including historical sectors. + +The following sector info fields are used exclusively for the termination fee calculation, and are unused by the built-in actors code: + +- expected day reward +- expected storage pledge +- replaced day reward + +For all new sectors or snapped sectors, these three values are set to zero. + +These redundant fields can be removed from state in a future migration. + +## Design Rationale + + + +There are a few different approaches one could take to accomplish the same end result: + +1. Use a "multiple of daily rewards" approach, which computes a termination fee based on a % or multiple of expected daily rewards for a period of time based on the current block rewards + - Problems: + - Less predictable - in order to estimate the collateral value of a Miner Actor, the protocol needs to be able to estimate what the future daily block reward will be for the network. If the network grows quickly and unexpectedly, this could dangerously impact a DeFi protocol as the daily block rewards may increase due to increasing baseline, thus increasing the termination penalty and decreasing the collateral value for a given Miner Actor. +2. Optimize data structures based on the current methodology to make an aggregate termination sector method feasible in constant time lookup + - Problems: + - Unsure if this is technically feasible, and if so, most likely a lot of sophistication and ugly accounting + - Would most likely add state to the Filecoin blockchain + +The %-of-pledge method is: + + 1. simple to calculate + 2. predictable + 3. fixed while the sector's pledge is constant + 4. will not decay towards zero as block rewards decline, thus more effectively protecting against churn + +## Backwards Compatibility + + + +This FIP would introduce backwards incompatibility with how previous tipsets calculate their termination fees. As a result, previous statistical data collected about Filecoin termination fees (which I don't think there's much of), would become incorrect. Off-chain tooling that estimates termination penalties must change how they work too. It's possible to maintain the historical state, but it seems like a lot of work for a little gain. + +This FIP requires a network upgrade because it intends to change built-in actor code. + +## Test Cases + + + +- When terminating a single sector, the realized termination fee should equal the expected % of pledge termination fee +- When terminating all sectors on a miner, the realized termination fee should equal the expected % of pledge termination fee + +## Security Considerations + + + +The security concern with introducing this FIP is that Storage Providers will not face a severe enough penalty to leave the network very quickly, which could cause major power volatility on the network. We don't believe this is a major concern for the following reasons: + +1. The 8.5% proposed termination penalty percentage is what the network is currently charging (on average) for steady state terminations. +2. Governance can always choose to increase the termination penalty percentage. +3. It seems appropriate to charge an exit fee for breaking a commitment to the network, but we also do not want to charge a capture fee. Storage Providers who do not wish to use Filecoin anymore shouldn't have prohibitively high expenses for leaving the network early - ultimately for the network, burning some of this SPs tokens through sector terminations is better than 18 months of selling. +4. As Filecoin matures, the average Storage Provider will likely be accepting paid deals in some form according to an SLA in addition to the SLA guaranteed by PoRep. These additional SLAs can/will enforce their own termination clauses, which should provide adequate motivation and verification to achieve a good experience for the average storage client. + +## Incentive Considerations + + + +It is important that Storage Providers are incentivized to honor their commitments to the network - this prevents major network volatility. It makes sense to maintain a disincentive for breaking commitments to the network, but this FIP doesn't change the incentive to provide useful storage to the network, it makes it somewhat easier. + +The termination fee for sectors committed a long time ago will immediately and significantly decrease, but only to match the fee:pledge ratio of new sectors. This will increase the incentive for some SPs with high-pledge sectors to terminate and re-onboard to gain more power for the same amount of pledge (but more hardware). + +In contrast to the current system, the termination penalty for a sector will be constant regardless of its age. Currently the termination penalty starts low and increases with age up to a max. This presents is a change in the incentive structure for short-term-view SPs. + +## Product Considerations + + + +From a product perspective, the network will massively simplify its UX. Potential Storage Providers can calculate their risk of mining on the back of a napkin, whereas today it takes a team of highly trained Filecoin experts. Developers can integrate safer DeFi practices. + +## Implementation + + + +## Copyright + +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). diff --git a/README.md b/README.md index 37e72286..f9077d2c 100644 --- a/README.md +++ b/README.md @@ -133,3 +133,4 @@ This improvement protocol helps achieve that objective for all members of the Fi | [0095](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0095.md) | Add FEVM precompile to fetch beacon digest from chain history | FIP | @ZenGround0, Alex North (@anorth) | Final | | [0096](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0096.md) | Convert fundraising remainder address(es) to keyless account actor(s) | FIP | @Fatman13 | Draft | | [0097](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0097.md) | Add Support for EIP-1153 (Transient Storage) in the FEVM | FIP | Michael Seiler (@snissn), Steven Allen (@stebalien) | Draft | +| [0098](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0098.md) | Simplify termination fee calculation to a fixed percentage of initial pledge | FIP | Jonathan Schwartz (@Schwartz10), Alex North (@anorth), Jim Pick (@jimpick) | Draft |