The primary downside is that 32 bits isn’t quite enough to store timestamp values that will reasonably never overflow. In fact, the date when the Unix timestamp overflows a uint32 is 02/07/2106. To ensure that this system continues to function properly after this date, and every multiple of 232 − 1 seconds thereafter, oracles are simply required to check prices at least once per interval (approximately 136 years). This is because the core method of accumulation (and modding of timestamp), is actually overflow-safe, meaning that trades across overflow intervals can be appropriately accounted for given that oracles are using the proper (simple) overflow arithmetic to compute deltas.
### 2.3 Flash Swaps
+
+
SFSwap adds a feature that allows a user to receive and use an asset before paying for it, as long as they make the payment within the same atomic transaction. The swap function makes a call to an optional user-specified callback contract in between transferring out the tokens requested by the user and enforcing the invariant. Once the callback is complete, the contract checks the new balances and confirms that the invariant is satisfied (after adjusting for fees on the amounts paid in). If the contract does not have sufficient funds, it reverts the entire transaction.
+
+
### 2.4 "Zero fee" Policy
+
+
TBD
+
+
## 3 Contract structure
+
+
### 3.1 Contract architecture
+
+
One design priority for SFSwap is to minimize the surface area and complexity of the core pair contract—the contract that stores liquidity providers’ assets. Any bugs in this contract could be disastrous, since millions of dollars of liquidity might be stolen or frozen.
+
+
When evaluating the security of this core contract, the most important question is whether it protects liquidity providers from having their assets stolen or locked. Any feature that is meant to support or protect traders—other than the basic functionality of allowing one asset in the pool to be swapped for another—can be handled in a “router” contract.
+
+
In fact, even part of the swap functionality can be pulled out into the router contract. As mentioned above, SFSwap stores the last recorded balance of each asset (in order to prevent a particular manipulative exploit of the oracle mechanism).
+
+
In SFSwap, the seller sends the asset to the core contract before calling the swap function. Then, the contract measures how much of the asset it has received, by comparing the last recorded balance to its current balance. This means the core contract is agnostic to the way in which the trader transfers the asset. Instead of transferFrom, it could be a meta transaction, or any other future mechanism for authorizing the transfer of ERC-20s
+
+
### 3.2 Initialization of liquidity token supply
+
+
When a new liquidity provider deposits tokens into an existing SFSwap pair, SFSwap initially mints shares equal to the geometric mean of the amounts deposited:
This formula ensures that the value of a liquidity pool share at any time is essentially independent of the ratio at which liquidity was initially deposited. For example, suppose that the price of 1 ABC is currently 100 XYZ. If the initial deposit had been 2 ABC and 200 XYZ (a ratio of 1:100), the depositor would have received $\sqrt{2 \cdot 200} = 20$ shares. Those shares should now still be worth 2 ABC and 200 XYZ, plus accumulated fees.
+
+
If the initial deposit had been 2 ABC and 800 XYZ (a ratio of 1:400), the depositor would have received $\sqrt{2 \cdot 800} = 40$ pool shares.
+
+
The above formula ensures that a liquidity pool share will never be worth less than the geometric mean of the reserves in that pool. However, it is possible for the value of a liquidity pool share to grow over time, either by accumulating trading fees or through “donations” to the liquidity pool. In theory, this could result in a situation where the value
+
of the minimum quantity of liquidity pool shares (1e-18 pool shares) is worth so much that it becomes infeasible for small liquidity providers to provide any liquidity.
+
+
To mitigate this, SFSwap burns the first 1e-15 (0.000000000000001) pool shares that are minted (1000 times the minimum quantity of pool shares), sending them to the zero address instead of to the minter. This should be a negligible cost for almost any token pair. But it dramatically increases the cost of the above attack. In order to raise the value of a liquidity pool share to $100, the attacker would need to donate $100,000 to the pool, which would be permanently locked up as liquidity
+
+
### 3.3 Deterministic pair addresses (Clones)
+
+
TBD From 3.6.
+
+
### 3.4 Maximum token balance
+
+
In order to efficiently implement the oracle mechanism, SFSwap only support reserve balances of up to $2^{112} − 1$. This number is high enough to support 18-decimal-place tokens with a totalSupply over 1 quadrillion.
+
+
If either reserve balance does go above $2^{112} − 1$, any call to the **swap** function will begin to fail (due to a check in the **_update()** function).
+
+
## 4 Disclaimer
+
+
This paper is for general information purposes only. It does not constitute investment advice or a recommendation or solicitation to buy or sell any investment and should not be used in the evaluation of the merits of making any investment decision. It should not be relied upon for accounting, legal or tax advice or investment recommendations. This paper reflects current opinions of the authors and is not made on behalf of Stochastic.Finance or its affiliates and does not necessarily reflect the opinions of Stochastic.Finance, its affiliates or individuals associated with Paradigm. The opinions reflected herein are subject to change without being updated.