document overfunding and underfunding behavior
@@ -119,6 +119,67 @@ systems and their security properties is included in the appendix.
// TODO What is "sufficient"? Defined as a system property? Dynamic?
+==== Overpayment & Underpayment
+
+To maintain a standard lot size for all _Deposits_ we require the depositor to
+send a precise amount of BTC in the funding transaction. Because we can't
+enforce this behavior on the Bitcoin chain, the system must account for
+overpayment and underpayment. The primary impact of overpayment and
+underpayment is on the _Deposit's_ collateralization ratio. The system requires
+a minimum collateralization ratio from signers, while the signers desire a
+predictable payment for their services. If the depositor sends too much or too
+little BTC, the signer incentives are at odds with the system's interests. To
+preserve treat overpayment and underpayment as faulty depositor behavior, and
+pass on the associated costs to the depositor.
+
+Allowing underpayment on _Deposit_ would result in over-bonded signers. To
+prevent this, the system will not accept funding proofs of less than the lot
+size. This implies that the BTC is forfeit to the signers, although they cannot
+access it until after the _Deposit_ is resolved on-chain (see
+<<Multiple UTXOs>> for a full discussion).
+
+Overpayment, in contrast, would result in under-bonded signers. Because theft
+of the BTC may be worth more than the signers' bonds, the signers may have an
+incentive to collude to steal the BTC. When overfunding occurs, the system
+accepts the funding proof, but mints TBTC according to the regular lot size,
+and allows redemption of the _Deposit_ by anyone will to burn a regular amount
+of TBTC.
+
+In an efficient market, this _Deposit_ will be immediately redeemed,
+as the redeemer expects to take the overfunded amount as arbitrage. The signers
+now have a choice: behave honestly, and receive the signer fee immediately, or
+collude to steal the deposit. Should they behave honestly, the redeemer's
+arbitrage succeeds, and the signers are paid. Should they collude, the
+redeemer may prove ECDSA fraud, and take their bonds. Either way, the TBTC
+supply peg is preserved. In either case, the depositor essentially forfeits
+the overfunded value to other participants.
+
+==== Multiple UTXOs
+
+A faulty depositor may send multiple UTXOs to the signer group address. This
+may be the result of human or software error. Unfortunately, returning the
+funds to the depositor would impose require significant on-chain complexity and
+gas fees, as each UTXO would need to be proven via SPV, and a signature on it
+explicitly authorized. In addition, we would have to develop mechanisms to
+economically compel signers to sign each transaction despite the fact that the
+total value of the UTXOs is not known. As such, the system accepts only the
+first UTXO greater than the deposit lot size. All other BTC sent to the signing
+group is forfeit. Therefore it is imperative that depositors send only a single
+UTXO of an appropriate size.
+
+A particularly damaging example would be a naive human depositor. If they
+mistakenly send half the lot size in one transaction and half in another, both
+UTXOs would be forfeit. This represents a serious pitfall for depositors that
+must be carefully addressed by the user interface.
+
+The signers, while they may collude to move the BTC to other UTXOs, may not do
+so during the life of the _Deposit_ contract as the production of the required
+signature would constitute ECDSA fraud. As such, the most likely outcome is
+that the signers collectively wait to take personal possession of that BTC
+until the _Deposit_ concludes naturally. This allows the signers to make
+regular signing fees and keep the additional UTXOs without penalty.
+
+
=== Light Relays
// TODO: crosslink to appendix SPV section
