diff --git a/KIPs/kip-160.md b/KIPs/kip-160.md
new file mode 100644
index 00000000..1f65d8bc
--- /dev/null
+++ b/KIPs/kip-160.md
@@ -0,0 +1,72 @@
+---
+kip: 160
+title: An Update of Treasury Fund Rebalancing
+requires: 103
+---
+
+## Simple Summary
+An update of treasury fund rebalancing.
+
+## Abstract
+The treasury fund rebalancing is updated, resulting in updates to the treasury rebalance contract v2 and the related core logic.
+
+## Motivation
+According to kip103, the treasury rebalancing refers to the act of burning existing fund balances and minting new funds. This event happens at a reserved time, such as a hard fork block number. Through the TreasuryRebalance contract, the disclosure of the treasury fund activities can be conducted transparently and verifiably. However, there are a few shortcomings of KIP103; (1) it only permits the decrease in the total balance of the funds, (2) its rebalance blocknumber is immutable.
+
+To address those above, this proposal made some improvements. First of all, this proposal expands to the general cases so that we don't have to consider whether the final result is burn or mint. The other improvement is about making rebalanceBlocknumber in the RebalanceContract editable. The rebalanceBlocknumber should be matched with the related hardfork block number. However, it is not updatable even hard fork block number can be updated.
+
+## Specification
+Before proceeding, this proposal will first organize and clarify the terminology. The previous/new fund addresses is called here as `Zeroed`, `Allocated` unlike in Kip103. `Retired`, `Newbie` was ambiguous enough to degrade the readability as they didn't clearly indicate that the previous fund balance is zeroed and the new fund balance is allocated.
+
+### To consider both total burn/total mint cases
+In kip103, the rebalancing only considers the total burn case where the total balance decreases. To make it generalized, this proposal removes the condition that the total balance of `Zeroeds` should be more than the total minting amount of `Allocateds`. As a result, the checking code is removed from the contract and core code.
+
+In the `TreasuryRebalanceV2` contract, the finalizeApproval has been revised like below. Originally, this require statement, `require(getTreasuryAmount() < sumOfZeroedBalance())`, was there. However, it is removed to support all the cases.
+
+```solidity
+   /**
+    * @dev finalizeApproval sets the status to Approved,
+    *      After this stage, approvals will be restricted.
+    */
+   function finalizeApproval()
+        public
+        onlyOwner
+        onlyAtStatus(Status.Registered)
+    {
+        checkZeroedsApproved();
+        status = Status.Approved;
+        emit StatusChanged(status);
+    }
+```
+
+The next validation has been removed from the core logic also. It ensured the total balance of `Zeroeds` is bigger than the total balance of `Allocateds`, but it is removed to support all the cases.
+* totalZeroedAmount >= totalAllocatedAmount
+
+### To make RebalanceBlocknumber defined in TreasuryRebalance contract editable
+In the treasury rebalance contract, there's a `RebalanceBlocknumber` storage and it should be matched with the related hard fork block number. However, even though the hard fork block number is updatable, the RebalanceBlocknumber field cannot be edited. To ensure the same behavior with the hard fork block number, the field become editable in this proposal.
+
+The next method is added to the TreasuryRebalanceV2 contract.
+```solidity
+    /**
+     * @dev updates rebalance block number
+     * @param _rebalanceBlockNumber is the updated target block number of the execution the rebalance in Core
+     */
+    function updateRebalanceBlocknumber(
+        uint256 _rebalanceBlockNumber
+    ) public onlyOwner {
+        require(
+            block.number < rebalanceBlockNumber && 
+            rebalanceBlockNumber < _rebalanceBlockNumber
+        );
+        rebalanceBlockNumber = _rebalanceBlockNumber;
+    }
+```
+
+## Rationale
+While processing the treasury rebalance core logic, the nonce of a contract was unintentionally increased. It is fixed not to increase the nonce of the zero address.
+
+## Test cases
+TBD
+
+## Reference
+TBD
\ No newline at end of file