# Tech spec changes on Nerite from Liquity V2

## Delegation
`ActivePool.sol` now has `delegateTokens` funtion. Any tokens can be delegated to the `delegate` role. The role can be update by `governance`, which is the DAO of NERI holders. Anyone can call delegate function safely since it always delegates to the `delegate` role.

## Superfluid
Bold token (which is renamed USDN), is now streamable via custom streaming token using this library: (https://www.npmjs.com/package/@superfluid-finance/ethereum-contracts)

_mint, _burn, _transfer functions have been replaced with selfMint, selfBurn, and selfTransfer from the [superfluid supertoken](https://github.com/superfluid-finance/protocol-monorepo/blob/dev/packages/ethereum-contracts/contracts/superfluid/SuperToken.sol).

BoldToken is no longer an ERC20 on its own, but rather a proxy which is initalized into an ERC20. Many deployment changes as a result. Dev note: do not use deal() cheatcode with boldToken in testing, since the memory is not stored how foundry expects.

erc20 imports on BoldToken are removed in favor of using UUPS proxy ERC20 imported by superfluid. It uses the same openzeppelin ERC20 implementation. Major issues to look for: when interacting with the stability pool permissioned transfer functions, is the new selfTransferFrom function behaving as expected? Has the boldToken been initialized correctly in deployment tests so they are giving the correct result?

Also remaps OZ in many places because of circular dependencies.

## More collaterals and debt limits
`BorrowOperations` handles minting new stablecoins. Debt can be minted in `withdrawBold`, `_openTrove` (which is used in the batch manager and elsewhere too, so be careful), and `_moveTokensFromAdjustment`. Simple debt limit is just a uint256 stored in the `TroveManager` of each branch, and accessable to the `CollateralRegistry` via the index of the collateral. Getters and setters are added.

Does not handle the situation where interest accrued goes over the debt limit.

Debt limit can be raised by `governance` by a max factor of 2 at a time, by calling the `CollateralRegistry` which then calls the `TroveManager` for that collateral branch.

Debt limit can be lowered to any amount at any time.

What i'm most worried about is:
1. if interest goes up a lot over the limit will things behave weirdly?

2. what happens if the borrowerOperations address gets updated in the future via addressRegistry? the current cap status must be passed along or manually added

3. Should people not be able to adjust their interest rate when debt is at the cap? Possible DoS attack there if not, but the cap will be exceeded due to fees otherwise.

4. _moveTokensFromAdjustment does not mint the accrued interest so maybe there is definitely some way in adjustTrove to go over the limit a bit from interest. (this is the one that is keeping me up at night)

**Known Issue:** calculating if a bold mint amount is over the limit can cause an overflow. This should be fine in prod, since the debt limit and number of BoldToken being minted will never be close to MAX_INT in reality.