diff --git a/specification/docs/future-work.md b/specification/docs/future-work.md
index 97ad207..1bc2ee9 100644
--- a/specification/docs/future-work.md
+++ b/specification/docs/future-work.md
@@ -1,4 +1,11 @@
-## DAO Core Proposals
+## DAO Core 
 
-Future work may include utilizing the process defined by the Proposal contract to govern features of the core contracts themselves. When a DAO is instantiated, a specific deployment of a Proposal contract can be designated as the official core DAO Proposal contract. DAO core contracts can utilize the designated Proposal contract to create and observe proposals. This process has not yet been demonstrated, and is currently hypothetical.
- 
\ No newline at end of file
+### Proposals
+
+The process defined by the Proposal contract could be used to govern features of the core contracts themselves (Bench, Forum, Reputation). When a DAO is instantiated, a specific deployment of a Proposal contract can be designated as the official core DAO Proposal contract. DAO core contracts can utilize the designated Proposal contract to create and observe proposals.
+ 
+## Validation Pool
+
+### Ratio of Minted REP Staked For/Against
+
+The ratio of minted REP staked for and against a VP could be taken as a parameter or governed by a Proposal to increase the flexibility of the DAO.
\ No newline at end of file
diff --git a/specification/docs/implementation-solidity.md b/specification/docs/implementation-solidity.md
index 4e7c131..9b2c26a 100644
--- a/specification/docs/implementation-solidity.md
+++ b/specification/docs/implementation-solidity.md
@@ -11,3 +11,7 @@ flowchart TD
     API <-- Matrix Client-Server Protocol\n(npm matrix-bot-sdk) --> Homeserver
 ```
 
+## Contracts
+
+### Bench
+
diff --git a/specification/docs/system-design.md b/specification/docs/system-design.md
index 52ff018..5e92c46 100644
--- a/specification/docs/system-design.md
+++ b/specification/docs/system-design.md
@@ -60,14 +60,41 @@ To achieve the Bench requirements, the contract must do the following:
 
 1. Implement a method for initiating a Validation Pool (VP)
 
+    1. This should be a payable contract call. The value transferred is the fee for this VP.
+
+    1. The VP shall mint an amount of REP equal to `valueTransferred * mintingRatio`
+
+        1. **`mintingRatio`** may be set statically, or may be taken as a parameter when initiating a VP. Taking `mintingRatio` as a parameter enables greater flexibility, but increases overhead cost per transaction. This makes `mintingRatio` a good candidate for being governed by a Proposal process, outlined in [Future Work](./future-work.md).
+
+    1. Half of the minted REP shall be staked in favor of the VP, and the other half shall be staked against the VP.
+
+        1. This ratio could be taken as a parameter or governed by a Proposal to increase the flexibility of the DAO; see [Future Work](./future-work.md).
+
+1. Implement a method for receiving REP stakes for/against the VP
+
+    1. Stake should be rejected if the VP `duration` has already elapsed.
+
+    1. Staking REP means that a DAO member makes an allowance for the given amount of REP to be withdrawn from their balance. The amount of the shall be recorded along with the boolean `inFavor`, but the REP is not to be withdraws from the sender's balance until certain conditions are met durint the evaluation of the VP outcome (explained below).
+
 1. Implement a method for evaluating the outcome of a Validation Pool
 
+    1. Outcome may not be evaluated until VP `duration` has elapsed
+
+        1. An exception can be made if `totalStakedFor + totalStakedAgainst == totalSupply`. In thise case the DAO is all-in, and there's no reason to wait before evaluating the outcome.
+
     1. The quorum is met if `(totalStakedFor + totalStakedAgainst) * quorum[denominator] >= totalSupply * quorum[numerator]`
     
     1. The vote passes if `totalStakedFor * winRatio[denominator] >= (totalStakedFor + totalStakedAgainst) * winRatio[numerator]`
 
+    1. If the vote passes and the quorum is met,
+
+        1. If `redistributeLosingStakes` is true, then `(bindingPercent / 100) * totalStakedAgainst` shall be distributed among the accounts who staked against the VP, in proportion to their stakes.
+
+        1. The REP that was staked in favor of the VP during its initiation, shall be transferred to the Target Post, and propagated via the Forum Reference mechanism to the authors of the Post and its referenced Posts.
+
     1. If provided, `callbackOnValidate` should be executed, and should be passed the results of the VP.
 
+
 **`totalSupply`** refers to the total amount of REP held by all DAO members.
 
 **`ValdiationPoolResult`** Fields
@@ -82,7 +109,7 @@ To achieve the Bench requirements, the contract must do the following:
 
 | Name | Type | 
 | --- | --- | 
-| `postId` | string |
+| `postId` | string identifying the Target Post|
 | `duration` | positive integer number of seconds |
 | `quorum` | integer numerator, integer denominator |
 | `winRatio` | integer numerator, integer denominator |