diff --git a/README.rst b/README.rst
index 4afb892f3..00bed2ce9 100644
--- a/README.rst
+++ b/README.rst
@@ -138,7 +138,7 @@ Index of ZIPs
323 | Specification of getblocktemplate for Zcash | Reserved |
339 | Wallet Recovery Words | Reserved |
400 | Wallet.dat format | Draft |
-
401 | Addressing Mempool Denial-of-Service | Final |
+
401 | Addressing Mempool Denial-of-Service | Active |
402 | New Wallet Database Format | Reserved |
403 | Verification Behaviour of zcashd | Reserved |
416 | Support for Unified Addresses in zcashd | Reserved |
diff --git a/zip-0401.rst b/zip-0401.rst
index d3ff0a93d..1abad5bfa 100644
--- a/zip-0401.rst
+++ b/zip-0401.rst
@@ -3,7 +3,7 @@
ZIP: 401
Title: Addressing Mempool Denial-of-Service
Owners: Daira Hopwood
- Status: Final
+ Status: Active
Category: Network
Created: 2019-09-09
License: MIT
@@ -83,8 +83,8 @@ which is an integer defined as:
Each transaction also has an *eviction weight*, which is *cost* + *low_fee_penalty*,
where *low_fee_penalty* is 16000 if the transaction pays a fee less than the
-conventional fee, otherwise 0. The conventional fee is currently defined as
-1000 zatoshis [#zip-0313]_.
+conventional fee, otherwise 0. The conventional fee is currently defined in
+[#zip-0317]_.
Each node also MUST hold a FIFO queue RecentlyEvicted of pairs (txid, time), where
the time indicates when the transaction with the given txid was evicted. The txid
@@ -211,5 +211,5 @@ References
.. [#zip-0208] `ZIP 208: Shorter Block Target Spacing `_
.. [#zip-0239] `ZIP 239: Relay of Version 5 Transactions `_
.. [#zip-0252] `ZIP 252: Deployment of the NU5 Network Upgrade `_
-.. [#zip-0313] `ZIP 313: Reduce Conventional Transaction Fee to 1000 zatoshis `_
+.. [#zip-0317] `ZIP 317: Proportional Transfer Fee Mechanism `_
.. [#BitcoinCore-PR6722] `Bitcoin Core PR 6722: Limit mempool by throwing away the cheapest txn and setting min relay fee to it `_
diff --git a/zip-proportional-output-fee-mechanism-pofm.rst b/zip-proportional-output-fee-mechanism-pofm.rst
new file mode 100644
index 000000000..a4faa0ed2
--- /dev/null
+++ b/zip-proportional-output-fee-mechanism-pofm.rst
@@ -0,0 +1,267 @@
+::
+
+ ZIP: 317
+ Title: Proportional Transfer Fee Mechanism
+ Owners: Aditya Bharadwaj
+ Credits: Madars Virza
+ Kris Nuttycombe
+ Daira Hopwood
+ Jack Grigg
+ Francisco Gindre
+ Status: Draft
+ Category: Standards / Wallet
+ Obsoletes: ZIP 313
+ Created: 2022-08-15
+ License: MIT
+ Discussions-To:
+ Pull-Request:
+
+
+Terminology
+===========
+
+The key word "SHOULD" in this document is to be interpreted as described in
+RFC 2119. [#RFC2119]_
+
+The term "conventional transaction fee" in this document is in reference
+to the value of a transaction fee that is conventionally used by wallets,
+and that a user can reasonably expect miners on the Zcash network to accept
+for including a transaction in a block.
+
+The terms "Mainnet, "Testnet", and "zatoshi" in this document are defined
+as in [#protocol-networks]_.
+
+
+Abstract
+========
+
+The goal of this ZIP is to change the conventional fees for transactions
+and get buy-in from wallet developers, miners and Zcash users.
+
+
+Motivation
+==========
+
+In light of recent network activity, it is time to review and update the
+standard 1,000 zatoshi transaction fee set in ZIP 313 [#zip-0313]_.
+
+The conventional transaction fee presently is 0.00001 ZEC or 1,000 zatoshis, as
+specified in ZIP 313. This allowed exploration of novel use cases of the Zcash
+blockchain. The Zcash network has operated for almost 2 years at a conventional
+transaction fee of 1,000 zatoshis, without consideration for the total number
+of inputs and outputs in each transaction. Under this conventional fee, some
+usage of the chain has been characterized by high-output transactions with
+1,100 outputs paying the same conventional fee as a transaction with 2 outputs.
+
+The objective of the new fee policy, once it is enforced, is for fees paid by
+transactions to fairly reflect the processing costs that they impose on various
+participants in the network. This will tend to discourage usage patterns that
+cause either intentional or unintentional denial of service, while still
+allowing low fees for regular transaction use cases.
+
+
+Requirements
+============
+
+* The conventional fee formula should not favour or discriminate against any
+ of the Orchard, Sapling, or transparent protocols.
+* The fee for a transaction should scale linearly with the number of inputs
+ and/or outputs.
+* Users should not be penalised for sending transactions constructed
+ with padding of inputs and outputs to reduce information leakage.
+ (The default policy employed by zcashd and the mobile SDKs pads to
+ two inputs and outputs for each shielded pool used by the transaction).
+* Users should be able to spend a small number of UTXOs or notes with value
+ below the marginal fee per input.
+
+
+Specification
+=============
+
+This specification defines three parameters that are used to calculate the
+conventional fee:
+
+=================== ==============================================
+Parameter Units
+=================== ==============================================
+`marginal_fee` zatoshis per logical action (as defined below)
+`grace_window_size` logical actions
+=================== ==============================================
+
+Wallets implementing this specification SHOULD use a conventional fee
+calculated in zatoshis per the following formula::
+
+ logical_actions = max(transparent_inputs, transparent_outputs) +
+ 2*sprout_joinsplits +
+ max(sapling_inputs, sapling_outputs) +
+ orchard_actions
+
+ conventional_fee = marginal_fee * max(grace_actions, logical_actions)
+
+The parameters are set to the following values:
+* `marginal_fee = 5000`;
+* `grace_window_size = 2`.
+
+It is not a consensus requirement that fees follow this formula; however,
+wallets SHOULD create transactions that pay this fee, in order to reduce
+information leakage, unless overridden by the user.
+
+Transaction relaying
+--------------------
+
+zcashd, zebrad, and potentially other node implementations, implement
+fee-based restrictions on relaying of mempool transactions. Nodes that
+normally relay transactions are expected to do so for transactions that pay
+at least the conventional fee as specified in this ZIP, unless there are
+other reasons not to do so for robustness or denial-of-service mitigation.
+
+Mempool size limiting
+---------------------
+
+zcashd and zebrad limit the size of the mempool as described in [#zip-0401]_.
+This specifies a *low\_fee\_penalty* that is added to the "eviction weight"
+if the transaction pays a fee less than the conventional transaction fee.
+This threshold is modified to use the new conventional fee formula.
+
+Block production
+----------------
+
+Miners, mining pools, and other block producers, select transactions for
+inclusion in blocks using a variety of criteria. Where the criteria
+previously used the conventional transaction fee defined in ZIP 313 to
+decide on transaction inclusion, it is expected to instead use the formula
+specified in this ZIP.
+
+Open Issues
+-----------
+
+> TODO: Remove this section once a decision is made.
+
+Possible alternatives for the parameters:
+
+* marginal_fee = 250 in @nuttycom's proposal.
+* marginal_fee = 1000 adapted from @madars' proposal.
+* marginal_fee = 2500 in @daira's proposal.
+* marginal_fee = 1000 for Shielded, Shielding and De-shielding
+ transactions, and marginal_fee = 10000 for Transparent transactions
+ adapted from @nighthawk24's proposal.
+
+(In @madars' and @nighthawk24's original proposals, there was an additional
+`base_fee` parameter that caused the relationship between fee and number
+of inputs/outputs to be non-proportional above the `grace_window_size`. This
+is no longer expressible with the formula specified above.)
+
+Rationale for logical actions
+'''''''''''''''''''''''''''''
+
+The intention is to make the fee paid for a transaction depend on its
+impact on the network, without discriminating between different protocols
+(Orchard, Sapling, or transparent). The impact on the network depends on
+the numbers of inputs and outputs.
+
+A previous proposal used `inputs + outputs` instead of logical actions.
+This would have disadvantages Orchard transactions, as a result of an
+Orchard Action combining an input and an output. The effect of this
+combining is that Orchard requires padding of either inputs or outputs
+to ensure that the number of inputs and outputs are the same. Usage of
+Sapling and transparent protocols does not require this padding, and
+so this could have effectively discriminated against Orchard.
+
+
+Security and Privacy considerations
+===================================
+
+Non-standard transaction fees may reveal specific users or wallets or wallet
+versions, which would reduce privacy for those specific users and the rest
+of the network. However, the advantage of faster deployment argued against
+synchronizing the change in wallet behaviour at a specific block height.
+
+Long term, the issue of fees needs to be re-visited in separate future
+proposals as the blocks start getting consistently full. New ZIPs with
+scaling solutions, will need to be evaluated and applied.
+
+Denial of Service Vulnerability
+-------------------------------
+
+A transaction-rate-based denial of service attack occurs when an attacker
+generates enough transactions over a window of time to prevent legitimate
+transactions from being mined, or to hinder syncing blocks for full nodes
+or miners.
+
+There are two primary protections to this kind of attack in Zcash: the
+block size limit, and transaction fees. The block size limit ensures that
+full nodes and miners can keep up with the blockchain even if blocks are
+completely full. However, users sending legitimate transactions may not
+have their transactions confirmed in a timely manner.
+
+Variable fees could mitigate this kind of denial of service: if there are
+more transactions available than can fit into a single block, then a miner
+will typically choose the transactions that pay the highest fees. If
+legitimate wallets were to increase their fees during this condition, the
+attacker would also increase the fees of their transactions. It is
+sometimes argued that this would impose a cost to the attacker that would
+limit the time window for which they can continue the attack. However, there
+is little evidence that the actual costs involved would be a sufficient
+disincentive.
+
+This proposal does not alter how fees are paid from transactions to miners.
+
+Wallet developers and operators should monitor the Zcash network for rapid
+growth in transaction rates.
+
+
+Deployment
+==========
+
+Wallets SHOULD deploy these changes immediately. Nodes SHOULD deploy the
+change to the *low\_fee\_penalty* threshold described in `Mempool size limiting`_
+immediately.
+
+Nodes can deploy restrictions to their policies for relaying, mempool
+acceptance, and/or mining once a sufficient proportion of wallets in the
+ecosystem are observed to be paying at least the updated conventional
+transaction fee. Node developers SHOULD coordinate on deployment
+schedule.
+
+
+Endorsements
+============
+
+The following entities/groups/individuals expressed their support for the
+updated fee mechanism:
+
+*Developer Groups or Sole OSS contributors*
+
+* Zecwallet Suite (Zecwallet Lite for Desktop/iOS/Android & Zecwallet FullNode)
+* Nighthawk Wallet for Android & iOS
+
+To express and request your support to be added to this ZIP please comment
+below indicating:
+
+* (group) name/pseudonym
+* affiliation
+* contact
+
+or, conversely e-mail the same details to the Owner of the ZIP.
+
+> TODO: Endorsements may depend on specific parameter choices. The ZIP
+> Editors should ensure that the endorsements are accurate before merging
+> this ZIP.
+
+
+Acknowledgements
+================
+
+Thanks to Madars Virza for initially proposing a fee mechanism similar to that
+proposed in this ZIP [#madars-1]_, and to Kris Nuttycombe, Jack Grigg, Daira Hopwood,
+Francisco Gindre, Greg Pfeil, and Teor for suggested improvements.
+
+
+References
+==========
+
+.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_
+.. [#protocol-networks] `Zcash Protocol Specification, Version 2022.3.8. Section 3.12: Mainnet and Testnet `_
+.. [#madars-1] `Madars concrete soft-fork proposal `_
+.. [#zip-0313] `ZIP 313: Reduce Conventional Transaction Fee to 1000 zatoshis `_
+.. [#zip-0401] `ZIP 401: Addressing Mempool Denial-of-Service `_