Unlock callback and deltas (#773)

docs/contracts/v4/guides/06-unlock-callback.mdx

@@ -2,10 +2,98 @@
 title: Unlock Callback & Deltas
 ---
 
-(TODO: explain)
+### Refresher
 
-1. unlock()
+In order to have access to the liquidity inside the `PoolManager`,
+it needs to be _unlocked_ to begin with. After being unlocked, any
+number of operations can be executed, which at the end of must be _locked_
+again. At this point, if there are any _non-zero deltas_, meaning the
+PoolManager is owed or owes tokens back to some address, the whole
+execution reverts. Otherwise, both parties have paid or received
+the right amount of tokens and the operations have successfully
+carried out.
 
-2. operations
+# Unlocking the PoolManager
 
-3. settle/take, burn/mint, clear, & deltas
+### Implementing the unlock callback
+
+Prior to unlocking the PoolManager, the integrating contract must
+implement the `unlockCallback` function. This function will be
+called by the PoolManager after being unlocked. An easy way to
+do this is to inherit the `SafeCallback` abstract contract.
+
+```solidity
+import {SafeCallback} from "v4-periphery/src/base/SafeCallback.sol";
+
+contract IntegratingContract is SafeCallback {
+    constructor(IPoolManager _poolManager) SafeCallback(_poolManager) {}
+}
+```
+
+### Calling the unlock function
+
+After implementing the callback, the integrating contract can now
+invoke the `unlock()` function. It receives a _bytes_ parameter
+that is further passed to your callback function as an argument.
+This parameter is used to encode the sequence of operations to be
+executed in the context of the `PoolManager`.
+
+
+```solidity
+bytes memory unlockData = abi.encode(encode_operations_here);
+bytes memory unlockResultData = poolManager.unlock(unlockData);
+```
+
+Next, we must override the `_unlockCallback` function inherited from
+the `SafeCallback` contract. In your implementation, you should
+decode your operations and continue with the desired logic.
+
+```solidity
+function _unlockCallback(bytes calldata data) internal override returns (bytes memory) {
+    (...) = abi.decode(data, (...));
+}
+```
+
+# Operations
+
+There are **9** operations that can be done in the `PoolManager`
+which fall in two categories: _liquidity-accessing_ and _delta-resolving_.
+
+### Deltas
+
+Deltas are the `PoolManager`'s method to keep track of token amounts it
+needs to receive, respectively to distribute. A negative delta signals that
+the `PoolManager` is owed tokens, while a positive one expresses a
+token balance that needs to be paid to its user.
+
+### Liquidity-accessing
+
+_Liquidity-accessing_ operations will create non-zero _deltas_ and
+produce a state transition of the selected pool.
+They are the following:
+
+* _modify liquidity_ - used to increase or decrease liquidity; increasing
+liquidity will result in a negative token delta, while decreasing yields a positive one
+* _swap_ - used to trade one token for another; will result in a negative tokenA delta
+and a positive tokenB delta
+* _donate_ - used to provide direct token revenue to positions in range;
+will result in a negative delta for the pool's tokens the user wishes
+to provide
+
+### Delta-resolving
+
+_Delta-resolving_ operations are used to even out the deltas created
+by the _liquidity-accessing_ operations. 
+They are the following:
+
+* _settle_ - used following token transfers to the manager
+or burning of ERC6909 claims to resolve negative deltas
+* _take_ - transfer tokens from the manager, used to resolve
+positive deltas but also provide token loans, producing negative deltas
+* _mint_ - used to create ERC6909 claims, creating a negative delta
+that needs to be resolved by transferring the corresponding token and
+_settling_ afterwards
+* _burn_ - removes ERC6909 claims, creating a positive delta for tokens to
+be transferred back to the owner or used in settling negative balances
+* _clear_ - used to zero out positive token deltas, helpful to forfeit
+insignificant token amounts in order to avoid paying further transfer costs