` | Get price for specific token |
| `getNTVPrice(tokenIn, tokenOut, discount)` | tokenIn: string
tokenOut: string
discount: number
| `Promise<{outRatio: number}>` | Get NTV price with discount |
| `getMaxSlippage(classicSlippage, discountNTVSlippage)` | classicSlippage: number
discountNTVSlippage: number
| `number` | Calculate maximum slippage |
| `getSplitOutputAmounts(smartTokenX, input)` | smartTokenX: string
input: string
| `Promise<{outputAmount: bigint, mgmtFeeAmount: bigint}>` | Calculate output for split operation |
| `getRedeemOutputAmounts(smartTokenX, input)` | smartTokenX: string
input: string
| `Promise<{outputAmount: bigint, mgmtFeeRefund: bigint}>` | Calculate output for redeem operation |
| `getSignedFeeData()` | - | `Promise` | Get signed fee data |
# TokenFactory
The Vault
## TokenFactory
[Git Source](https://github.com/RiskProtocol/core-protocol/blob/d59ee719f0b8aa5daeb239f6468bda6d3a1b56be/contracts/vaults/TokenFactory.sol)
**Inherits:** ReentrancyGuardUpgradeable, OwnableUpgradeable, UUPSUpgradeable, BaseContract
The main purposes of this contract is to act as a vault as well as it contains the shared logic used by riskON/OFF tokens.
*Acts as the vault for holding the underlying assets/tokens. Also contains shared logic used by riskON/OFF*
### State Variables
#### rebalanceElements
```solidity
RebalanceElements[] private rebalanceElements;
```
#### dailyFeeFactors
```solidity
uint256[] private dailyFeeFactors;
```
#### userRebalanceElements
```solidity
mapping(address => UserRebalanceElements) private userRebalanceElements;
```
#### REBALANCE\_INT\_MULTIPLIER
```solidity
uint256 private constant REBALANCE_INT_MULTIPLIER = 10 ** 18;
```
#### smartTokenArray
```solidity
SmartToken[] private smartTokenArray;
```
#### lastRebalanceCount
This mapping keeps track of the last rebalance applied to a user/address
```solidity
mapping(address => uint256) private lastRebalanceCount;
```
#### lastdailyFFcount
```solidity
mapping(address => uint256) private lastdailyFFcount;
```
#### baseToken
This is the instance of the underlying Token
```solidity
IERC20Update private baseToken;
```
#### baseTokenDecimals
The number of decimals of the underlying Asset/Token
```solidity
uint8 private baseTokenDecimals;
```
#### interval
The rebalance interval in seconds
```solidity
uint256 private interval;
```
#### lastTimeStamp
The timestamp of the last rebalance
```solidity
uint256 private lastTimeStamp;
```
#### smartTokenInitialized
This boolean keeps track if the smart tokens(RiskON/OFF) have already been initialized in the system
```solidity
bool private smartTokenInitialized;
```
#### signers
This is the signers address of RP api's that generate encoded params for rebalance
```solidity
mapping(address => bool) private signers;
```
#### FFinterval
This is used by the feefactors method to calculate the fees
```solidity
uint256 private FFinterval;
```
#### FFLastTimeStamp
```solidity
uint256 private FFLastTimeStamp;
```
#### sequenceNumberApplied
This keeps track of the 'sequenceNumber' of a rebalance which helps
```solidity
mapping(uint256 => bool) private sequenceNumberApplied;
```
#### managementFeesRate
```solidity
uint256 private managementFeesRate;
```
#### managementFeeEnabled
```solidity
bool private managementFeeEnabled;
```
#### lastRebalanceFees
```solidity
uint256 private lastRebalanceFees;
```
#### treasuryWallet
```solidity
address private treasuryWallet;
```
#### orchestrator
```solidity
address private orchestrator;
```
#### isNativeToken
```solidity
bool private isNativeToken;
```
#### premiumPercentage
```solidity
uint16 private premiumPercentage;
```
#### premiumCharged
```solidity
uint256 private premiumCharged;
```
#### scheduledRebalances
*A mapping to hold the scheduled rebalances. This helps in storing rebalances in the order they are scheduled till they are all executed*
```solidity
mapping(uint256 => Shared.ScheduledRebalance) private scheduledRebalances;
```
#### scheduledRebalancesLength
```solidity
uint256 private scheduledRebalancesLength;
```
#### nextSequenceNumber
*A counter to generate a unique sequence number for each rebalance. This ensures that rebalances are executed in the order they are scheduled.*
```solidity
uint256 private nextSequenceNumber;
```
#### period
```solidity
uint256 private period;
```
#### withdrawLimit
```solidity
uint256 private withdrawLimit;
```
#### depositLimit
```solidity
uint256 private depositLimit;
```
#### hasWithdrawLimit
```solidity
bool private hasWithdrawLimit;
```
#### hasDepositLimit
```solidity
bool private hasDepositLimit;
```
#### currentWithdrawPeriodEnd
```solidity
mapping(address => uint256) private currentWithdrawPeriodEnd;
```
#### currentWithdrawPeriodAmount
```solidity
mapping(address => uint256) private currentWithdrawPeriodAmount;
```
#### currentDepositPeriodEnd
```solidity
mapping(address => uint256) private currentDepositPeriodEnd;
```
#### currentDepositPeriodAmount
```solidity
mapping(address => uint256) private currentDepositPeriodAmount;
```
#### redemptionFee
```solidity
uint256 private redemptionFee;
```
### Functions
#### onlySmartTokens
Ensures the caller is one of the SmartTokens(RiskOn/Off).
*This modifier checks if the caller is either smartTokenArray\[0] or smartTokenArray\[1]. If not, it reverts with a custom error message.*
```solidity
modifier onlySmartTokens();
```
#### onlyOrchestrator
```solidity
modifier onlyOrchestrator();
```
#### onlyIntializedOnce
```solidity
modifier onlyIntializedOnce();
```
#### constructor
**Note:** oz-upgrades-unsafe-allow: constructor
```solidity
constructor();
```
#### initialize
Initializes(replacement for the constructor) the Vault (TokenFactory) contract with specified params
*This function sets up the initial state of the TokenFactory contract. Callable only once.*
```solidity
function initialize(
IERC20Update baseTokenAddress,
uint256 rebalanceInterval,
uint256 ffInterval,
address sanctionsContract_,
address signersAddress_,
address owner_,
uint256 withdrawLimit_,
uint256 depositLimit_,
uint256 limitPeriod_,
bool isNativeToken_
) public initializer;
```
**Parameters**
| Name | Type | Description |
| -------------------- | -------------- | ------------------------------------------------------------------------------------------- |
| `baseTokenAddress` | `IERC20Update` | The address of the underlying token/asset |
| `rebalanceInterval` | `uint256` | The interval (in seconds) at which natural rebalances are scheduled. |
| `ffInterval` | `uint256` | |
| `sanctionsContract_` | `address` | The address of the sanctions contract(chainalysis contract) to verify blacklisted addresses |
| `signersAddress_` | `address` | The address of the signer ( RP Api's) which signed the rebalance data |
| `owner_` | `address` | |
| `withdrawLimit_` | `uint256` | |
| `depositLimit_` | `uint256` | |
| `limitPeriod_` | `uint256` | |
| `isNativeToken_` | `bool` | |
#### \_authorizeUpgrade
Authorizes an upgrade to a new contract implementation.
*This function can only be called by the contract owner. It overrides the `_authorizeUpgrade` function from the `UUPSUpgradeable` contract to include the `onlyOwner` modifier, ensuring only the owner can authorize upgrades.*
```solidity
function _authorizeUpgrade(address) internal override(UUPSUpgradeable) onlyOwner;
```
#### initializeSMART
Initializes the smart tokens associated with this TokenFactory. renaming this method to avoid conflicts with upgradable initialize
*This function can only be called once, and only by the contract owner.*
```solidity
function initializeSMART(SmartToken token1, SmartToken token2) external onlyOwner onlyIntializedOnce;
```
**Parameters**
| Name | Type | Description |
| -------- | ------------ | ---------------------- |
| `token1` | `SmartToken` | The first smart token |
| `token2` | `SmartToken` | The second smart token |
#### initializeOrchestrator
```solidity
function initializeOrchestrator(address orchestrator_) external onlyOwner;
```
#### \_tryGetAssetDecimals
Attempts to fetch the decimals of underlying token
*This function uses a static call to query the decimals from the asset. If the call fails or the returned data is invalid, it defaults to 0.*
```solidity
function _tryGetAssetDecimals(IERC20 asset_) private view returns (bool, uint8);
```
**Parameters**
| Name | Type | Description |
| -------- | -------- | ----------------------------------- |
| `asset_` | `IERC20` | The address of the underlying token |
**Returns**
| Name | Type | Description |
| -------- | ------- | ------------------------------------------------------------------------------------------------------------------- |
| `` | `bool` | A return vaule containing a boolean indicating success and the decimals of the token. or false if it failed somehow |
| `` | `uint8` | |
#### decimals
Fetches the decimal value of the underlying token
*This function returns the value of decimals that was set in the 'initialize' method*
```solidity
function decimals() public view virtual returns (uint8);
```
**Returns**
| Name | Type | Description |
| -------- | ------- | ---------------------------------------------- |
| `` | `uint8` | The number of decimals of the underlying token |
#### getBaseToken
Retrieves the instance of the underlying token contract
*This function provides a way to access the instance of the underlying contract*
```solidity
function getBaseToken() public view virtual returns (IERC20Update);
```
**Returns**
| Name | Type | Description |
| -------- | -------------- | --------------------------------------- |
| `` | `IERC20Update` | The instance of the underlying contract |
#### maxAmountToWithdraw
Returns the maximum amount of assets the owner can withdraw.
*This function compares the balance of both smart tokens(RiskON/OFF) for the owner and returns the balance of the smart token with the lesser amount.*
```solidity
function maxAmountToWithdraw(address owner_) public view virtual returns (uint256);
```
**Parameters**
| Name | Type | Description |
| -------- | --------- | ------------------------ |
| `owner_` | `address` | The address of the owner |
**Returns**
| Name | Type | Description |
| -------- | --------- | -------------------------------------------------------------- |
| `` | `uint256` | The maximum amount of assets the specified owner can withdraw. |
#### maxSharesOwned
Determines the maximum amount of shares owned by the owner
*This function compares the balance of both smart tokens(RiskON/OFF) for the owner and returns the balance of the smart token with the greater amount.*
```solidity
function maxSharesOwned(address owner_) public view virtual returns (uint256);
```
**Parameters**
| Name | Type | Description |
| -------- | --------- | ------------------------ |
| `owner_` | `address` | The address of the owner |
**Returns**
| Name | Type | Description |
| -------- | --------- | ---------------------------------------------------------- |
| `` | `uint256` | The maximum amount of shares owned by the specified owner. |
#### \_deposit
Deposit/mint common workflow, deposit underlying tokens, mints new shares(RiskON/OFF) to the receiver, and also charges management fees
*Deposit/mint common workflow.*
*This function can only be called by the smart tokens and requires the caller and receiver to not be sanctioned.*
```solidity
function _deposit(address caller, address receiver, uint256 assets, uint256 shares)
external
virtual
onlyNotSanctioned(caller)
onlyNotSanctioned(receiver)
onlySmartTokens;
```
**Parameters**
| Name | Type | Description |
| ---------- | --------- | --------------------------------------------------------- |
| `caller` | `address` | The address of depositor |
| `receiver` | `address` | The address of receiver |
| `assets` | `uint256` | The amount of underlying tokens being deposited. |
| `shares` | `uint256` | The amount of shares(RiskON/OFF) to mint to the receiver. |
#### \_withdraw
Withdraw/redeem common workflow. Handles the withdrawal of underlying token. burns shares(RiskON/OFF) from the caller, and refund any management fees
*This function can only be called by the smart tokens and requires the caller and receiver to not be sanctioned.*
```solidity
function _withdraw(address caller, address receiver, address owner, uint256 assets, uint256 shares)
external
virtual
onlyNotSanctioned(caller)
onlyNotSanctioned(receiver)
onlySmartTokens;
```
**Parameters**
| Name | Type | Description |
| ---------- | --------- | --------------------------------------------------------- |
| `caller` | `address` | The address withdrawing. |
| `receiver` | `address` | The address receiving the underlying token. |
| `owner` | `address` | The owner of the shares. |
| `assets` | `uint256` | The amount of underlying Token being withdrawn. |
| `shares` | `uint256` | The amount of shares(RiskON/OFF) to burn from the caller. |
#### getUserRecords
```solidity
function getUserRecords(address sender, address recipient) external view onlySmartTokens returns (uint256[4] memory);
```
#### transferRecords
```solidity
function transferRecords(
address sender,
address recipient,
bool tokenType,
uint256 amount,
uint256 prevBalXsender,
uint256 prevBalYsender,
uint256 prevBalXrecipient,
uint256 prevBalYrecipient
) external onlySmartTokens;
```
#### updateRecord
```solidity
function updateRecord(bool tokenType, address account, uint256 amount) external onlySmartTokens;
```
#### updateRecord
```solidity
function updateRecord(bool tokenType, uint256 amount) external onlySmartTokens;
```
#### factoryMint
Mints the specified amount of Shares(RiskON/OFF) to the receiver
*It first previews the minting process to get the amount of Shares(RiskON/OFF)that will be minted, and then performs the actual minting.*
```solidity
function factoryMint(uint256 smartTokenIndex, address receiver, uint256 amount) private;
```
**Parameters**
| Name | Type | Description |
| ----------------- | --------- | ---------------------------------------------------- |
| `smartTokenIndex` | `uint256` | The index of the smart token in the smartTokenArray. |
| `receiver` | `address` | The address of the receiver |
| `amount` | `uint256` | The amount of Shares(RiskON/OFF) to mint. |
#### factoryBurn
Burns the specified amount of Shares(either of RiskON/OFF)from the owner
*It calls the `burn` function on the smart token contract*
```solidity
function factoryBurn(uint256 smartTokenIndex, address owner_, uint256 amount) private;
```
**Parameters**
| Name | Type | Description |
| ----------------- | --------- | ------------------------------------------------------ |
| `smartTokenIndex` | `uint256` | The index of the smart token in the `smartTokenArray`. |
| `owner_` | `address` | The address of the owner |
| `amount` | `uint256` | The amount of Shares(either of RiskON/OFF) to burn. |
#### factoryTreasuryTransfer
```solidity
function factoryTreasuryTransfer(uint256 amount) private;
```
#### factoryBalanceAdjust
```solidity
function factoryBalanceAdjust(address account, uint256 amountX, uint256 amountY) private;
```
#### executeRebalance
Executes a rebalance based on the provided encoded data and signature.
*This function validates the rebalance call, schedules it, and possibly triggers a rebalance if the sequence is in order. It first verifies the signature of the rebalance params with the signer's public key. Then we verify if the sequence number is aligned and not already used. Then we push the rebalance params into an array of scheduled rebalances. Finally, if there is no gaps between the previous rebalance'sequence number, we execute this rebalance This function can only be called when rebalance is not stopped with the `stopRebalance` modifier.*
```solidity
function executeRebalance(bytes memory encodedData, bytes memory signature) external stopRebalance onlyOrchestrator;
```
**Parameters**
| Name | Type | Description |
| ------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------ |
| `encodedData` | `bytes` | The encoded data containing the sequence number, the boolean value for natural rebalance and the price of underlying and smartTokenX |
| `signature` | `bytes` | The signature of the encoded data to verify its authenticity. |
#### executeScheduledRebalances
Executes scheduled rebalances pending in the queue
*This function is called when the scheduled rebalance queue had more than 5 entries only 5 will be executed and the rest will be left in the queue*
```solidity
function executeScheduledRebalances() external stopRebalance onlyOrchestrator;
```
#### chargeFees
Charges the management fees
*This function is responsible for charging the fees of the whole universe and related functionalities. We charge the fees on a daily Basis/ each FFinterval*
```solidity
function chargeFees() private;
```
#### rebalance
Handles the actual rebalancing mechanism.
*This function processes up to 5 scheduled rebalances per call. Different factors that will help calculating user balances are calculated here using the rebalance params.*
```solidity
function rebalance() private;
```
#### updateFeeFactor
```solidity
function updateFeeFactor() private;
```
#### dailyFeeFactorsUpdate
```solidity
function dailyFeeFactorsUpdate() public;
```
#### applyFF
should apply this to users before any interaction with the contracts
```solidity
function applyFF(address owner) public;
```
#### updateUserLastFFCount
```solidity
function updateUserLastFFCount(address owner_) public;
```
#### FFCheck
```solidity
function FFCheck(address user) private;
```
#### applyRebalance
Applies rebalance to an account
*This function adjusts the balance of smart tokens(RiskON/RiskOFF) according to the rollOverValue. This function can only be called when rebalance is stopped. It also calculates and applies management fees.*
```solidity
function applyRebalance(address owner_) public stopRebalance;
```
**Parameters**
| Name | Type | Description |
| -------- | --------- | ------------------------------------------------------------------ |
| `owner_` | `address` | The address of the account to which the rebalance will be applied. |
#### underlyingTransfer
```solidity
function underlyingTransfer(address receiver_, uint256 amount_) external onlySmartTokens;
```
#### underlyingReturn
```solidity
function underlyingReturn(address sender_, uint256 amount_, uint256 premium) external onlySmartTokens;
```
#### calculateRollOverValue
Calculates the rollover value(Units of RiskON/OFF) for an account
*This function calculates the net balance(Units of RiskON/OFF) of a user after rebalance and management fees are applied.*
```solidity
function calculateRollOverValue(address owner_) public view returns (uint256, uint256);
```
**Parameters**
| Name | Type | Description |
| -------- | --------- | ------------------------ |
| `owner_` | `address` | The address of the owner |
**Returns**
| Name | Type | Description |
| -------- | --------- | ------------------------------- |
| `` | `uint256` | The calculated roll over value. |
| `` | `uint256` | |
#### updateUserLastRebalanceCount
Updates the last rebalance count of a user.
*This function sets the last rebalance count for a user if their unscaled balances for both smart tokens(RiskON/RiskOFF) are zero. We may use this in cases where a receiever is new to the system*
```solidity
function updateUserLastRebalanceCount(address owner_) public;
```
**Parameters**
| Name | Type | Description |
| -------- | --------- | ----------------------- |
| `owner_` | `address` | The address of the user |
#### verifyAndDecode
Verifies the provided signature and decodes the encoded data into `ScheduledRebalance` struct.
*It recovers the address from the Ethereum signed message hash and the provided `signature`. If the recovered address doesn't match the `signersAddress`, it reverts the transaction. If the signature is valid, it decodes the `encodedData` into a `ScheduledRebalance` struct and returns it.*
```solidity
function verifyAndDecode(bytes memory signature, bytes memory encodedData)
public
view
returns (Shared.ScheduledRebalance memory);
```
**Parameters**
| Name | Type | Description |
| ------------- | ------- | ---------------------------------------------------------- |
| `signature` | `bytes` | The signature to be verified. |
| `encodedData` | `bytes` | The data to be decoded into a `ScheduledRebalance` struct. |
**Returns**
| Name | Type | Description |
| -------- | --------------------------- | --------------------------------------------------------------- |
| `` | `Shared.ScheduledRebalance` | data A `ScheduledRebalance` struct containing the decoded data. |
#### setSignersAddress
Update the address authorized to sign rebalance transactions.
*This function can only be called by the owner of the contract. It updates the `signersAddress` address with the provided `addr` address.*
```solidity
function setSignersAddress(address addr) external onlyOwner;
```
**Parameters**
| Name | Type | Description |
| ------ | --------- | --------------- |
| `addr` | `address` | The new address |
#### removeSigner
```solidity
function removeSigner(address signer) external onlyOwner;
```
#### setManagementFeeRate
Updates the rate of management fees.
*It updates the `managementFeesRate` state variable with the provided `rate` value, if the rate is within a valid range, otherwise, it reverts the transaction. The rate is in terms of percentage per day scaling factor is 10E18 Example 5% per day = 0.05*10E18\*
```solidity
function setManagementFeeRate(uint256 rate) external onlyOwner returns (bool);
```
**Parameters**
| Name | Type | Description |
| ------ | --------- | ------------------------------------------------- |
| `rate` | `uint256` | The new rate of management fees. It is DAILY RATE |
**Returns**
| Name | Type | Description |
| -------- | ------ | --------------- |
| `` | `bool` | A boolean value |
#### setManagementFeeState
Toggles the state of management fee collection.
*This function can only be called by the contract owner. It either enables or disables the management fee collection*
```solidity
function setManagementFeeState(bool state) external onlyOwner returns (bool);
```
**Parameters**
| Name | Type | Description |
| ------- | ------ | ------------------------------------------- |
| `state` | `bool` | The new state of management fee collection. |
**Returns**
| Name | Type | Description |
| -------- | ------ | --------------- |
| `` | `bool` | A boolean value |
#### setTreasuryWallet
```solidity
function setTreasuryWallet(address wallet) external onlyOwner returns (bool);
```
#### calculateManagementFee
Calculates the management fee for a given amount over a particular time span.
*It computes the management fee either using the default management fee rate or a provided fee rate. This function can be used both for deposit and withdrawal scenarios.*
```solidity
function calculateManagementFee(uint256 amount, uint256 mgmtFee) public view returns (uint256);
```
**Parameters**
| Name | Type | Description |
| --------- | --------- | -------------------------------------------------------------- |
| `amount` | `uint256` | The amount of RiskON/OFF to calculate the fee against. |
| `mgmtFee` | `uint256` | The management fee rate to use if `isDefault` is set to false. |
**Returns**
| Name | Type | Description |
| -------- | --------- | -------------------------------------- |
| `` | `uint256` | userFees The calculated management fee |
#### rebalanceCheck
Checks if a user is an existing user and applies user rebalance when needed.
*This function is triggered to ensure a user's balances are updated with any rebalances that have occurred since their last interaction with the contract.*
```solidity
function rebalanceCheck(address user) private;
```
**Parameters**
| Name | Type | Description |
| ------ | --------- | ----------------------- |
| `user` | `address` | The address of the user |
#### removeRebalance
Removes a rebalance entry from the `scheduledRebalances` mapping at the given sequence number.
*It deletes the entry at the given sequence number and decrements the `scheduledRebalancesLength` variable. It is also guarded by 'nonReentrant' modifier.*
```solidity
function removeRebalance(uint256 sequenceNumber) private nonReentrant;
```
**Parameters**
| Name | Type | Description |
| ---------------- | --------- | ------------------------------------------------------------------ |
| `sequenceNumber` | `uint256` | The sequenceNumber of the `scheduledRebalances` mapping to remove. |
#### isValidSigner
Verifies if a signer is valid
*Verifies if a signer is valid*
```solidity
function isValidSigner(address addr) public view returns (bool);
```
**Parameters**
| Name | Type | Description |
| ------ | --------- | ------------------------- |
| `addr` | `address` | The address of the signer |
**Returns**
| Name | Type | Description |
| -------- | ------ | ----------------------- |
| `` | `bool` | true if signer is valid |
#### withdrawLimitMod
ratelimits
```solidity
function withdrawLimitMod(uint256 amount) external onlySmartTokens returns (bool);
```
#### depositLimitMod
```solidity
function depositLimitMod(uint256 amount) external onlySmartTokens returns (bool);
```
#### updatePeriod
```solidity
function updatePeriod(
address user,
mapping(address => uint256) storage currentPeriodEnd,
mapping(address => uint256) storage currentPeriodAmount
) internal;
```
#### updateWithdrawLimit
```solidity
function updateWithdrawLimit(uint256 newLimit) external onlyOwner;
```
#### updateDepositLimit
```solidity
function updateDepositLimit(uint256 newLimit) external onlyOwner;
```
#### updateLimitPeriod
```solidity
function updateLimitPeriod(uint256 newPeriod) external onlyOwner;
```
#### toggleWithdrawLimit
```solidity
function toggleWithdrawLimit() external onlyOwner;
```
#### toggleDepositLimit
```solidity
function toggleDepositLimit() external onlyOwner;
```
#### setPremiumPercentage
```solidity
function setPremiumPercentage(uint16 percentage) external onlyOwner;
```
#### drainFlashloanPremiums
```solidity
function drainFlashloanPremiums(address receiver) external onlyOwner;
```
#### setRedemptionFee
```solidity
function setRedemptionFee(uint256 fee) external onlyOwner;
```
#### updateLastRebalanceTimeStamp
```solidity
function updateLastRebalanceTimeStamp(uint256 newTimeStamp) external onlyOwner;
```
#### getScheduledRebalances
Retrieves the `scheduledRebalance` struct at the given sequence number.
*This function is a getter for a single `scheduledRebalance` struct.*
```solidity
function getScheduledRebalances(uint256 sequenceNumber) public view returns (Shared.ScheduledRebalance memory);
```
**Parameters**
| Name | Type | Description |
| ---------------- | --------- | --------------------------------------------------------------------- |
| `sequenceNumber` | `uint256` | The sequence number of the `scheduledRebalances` mapping to retrieve. |
**Returns**
| Name | Type | Description |
| -------- | --------------------------- | ------------------------------------------------------------- |
| `` | `Shared.ScheduledRebalance` | The `scheduledRebalance` struct at the given sequence number. |
#### getNextSequenceNumber
Retrieves the nextSequenceNumber
*This function is a getter for the `nextSequenceNumber` variable.*
```solidity
function getNextSequenceNumber() public view returns (uint256);
```
**Returns**
| Name | Type | Description |
| -------- | --------- | ----------------------- |
| `` | `uint256` | The anextSequenceNumber |
#### getLastTimeStamp
Retrieves the lastTimeStamp
*This function is a getter for the `lastTimeStamp` variable.*
```solidity
function getLastTimeStamp() external view onlyOwner returns (uint256);
```
**Returns**
| Name | Type | Description |
| -------- | --------- | ----------------- |
| `` | `uint256` | The lastTimeStamp |
#### getManagementFeeRate
```solidity
function getManagementFeeRate() public view returns (uint256);
```
#### getManagementFeeState
Retrieves the managementFeeEnabled
*This function is a getter for the `managementFeeEnabled` variable.*
```solidity
function getManagementFeeState() public view returns (bool);
```
**Returns**
| Name | Type | Description |
| -------- | ------ | ------------------------ |
| `` | `bool` | The managementFeeEnabled |
#### getRebalanceNumber
```solidity
function getRebalanceNumber() public view returns (uint256);
```
#### getUserLastRebalanceCount
```solidity
function getUserLastRebalanceCount(address userAddress) public view returns (uint256);
```
#### getSmartTokenAddress
Retrieves the interval
*This function is a getter for the `interval` variable.*
```solidity
function getSmartTokenAddress(uint8 index) public view returns (SmartToken);
```
**Parameters**
| Name | Type | Description |
| ------- | ------- | ----------------------------------------------------- |
| `index` | `uint8` | The index of the SmartToken in the `smartTokenArray`. |
**Returns**
| Name | Type | Description |
| -------- | ------------ | ------------ |
| `` | `SmartToken` | The interval |
#### getTreasuryAddress
```solidity
function getTreasuryAddress() public view returns (address);
```
#### getInterval
Retrieves the interval
*This function is a getter for the `interval` variable.*
```solidity
function getInterval() public view returns (uint256);
```
**Returns**
| Name | Type | Description |
| -------- | --------- | ------------ |
| `` | `uint256` | The interval |
#### insufficientUnderlying
Validates if the amount of underlying locked in the token factory is
*This function is used the smartoken modifer*
```solidity
function insufficientUnderlying() external view returns (bool);
```
**Returns**
| Name | Type | Description |
| -------- | ------ | -------------------------- |
| `` | `bool` | true if underlying is less |
#### withdrawLimitStatus
```solidity
function withdrawLimitStatus() public view returns (bool);
```
#### depositLimitStatus
```solidity
function depositLimitStatus() public view returns (bool);
```
#### getWithdrawLimit
```solidity
function getWithdrawLimit() public view returns (uint256);
```
#### getDepositLimit
```solidity
function getDepositLimit() public view returns (uint256);
```
#### getLimitPeriod
```solidity
function getLimitPeriod() public view returns (uint256);
```
#### getUserLimitPerPeriod
```solidity
function getUserLimitPerPeriod(address user, bool isWithdraw)
public
view
returns (uint256 periodEnd, uint256 currentAmount);
```
#### getLastFFTimeStamp
Getters for the new fees mechanisms
```solidity
function getLastFFTimeStamp() external view returns (uint256);
```
#### getDailyFeeFactorNumber
```solidity
function getDailyFeeFactorNumber() public view returns (uint256);
```
#### getUserLastFFCount
```solidity
function getUserLastFFCount(address userAddress) public view returns (uint256);
```
#### getIsNativeToken
```solidity
function getIsNativeToken() public view returns (bool);
```
#### getFlashloanPremium
```solidity
function getFlashloanPremium() public view returns (uint16);
```
#### getAccumulatedFlashLoanPremium
```solidity
function getAccumulatedFlashLoanPremium() public view returns (uint256);
```
#### getRedemptionFee
```solidity
function getRedemptionFee() external view returns (uint256);
```
### Events
#### RebalanceApplied
```solidity
event RebalanceApplied(address userAddress, uint256 rebalanceCount);
```
#### Rebalance
```solidity
event Rebalance(uint256 rebalanceCount);
```
#### Deposit
```solidity
event Deposit(address caller, address receiver, uint256 assets, uint256 shares);
```
#### Withdraw
```solidity
event Withdraw(address caller, address receiver, address owner, uint256 assets, uint256 shares);
```
#### PremiumDrained
```solidity
event PremiumDrained(address receiver, uint256 amount);
```
#### WithdrawLimitToggled
```solidity
event WithdrawLimitToggled(bool enabled);
```
#### DepositLimitToggled
```solidity
event DepositLimitToggled(bool enabled);
```
### Errors
#### TokenFactory\_\_MethodNotAllowed
```solidity
error TokenFactory__MethodNotAllowed();
```
#### TokenFactory\_\_InvalidDivision
```solidity
error TokenFactory__InvalidDivision();
```
#### TokenFactory\_\_InvalidRebalanceParams
```solidity
error TokenFactory__InvalidRebalanceParams();
```
#### TokenFactory\_\_InvalidSequenceNumber
```solidity
error TokenFactory__InvalidSequenceNumber();
```
#### TokenFactory\_\_InvalidNaturalRebalance
```solidity
error TokenFactory__InvalidNaturalRebalance();
```
#### TokenFactory\_\_AlreadyInitialized
```solidity
error TokenFactory__AlreadyInitialized();
```
#### TokenFactory\_\_InvalidSignature
```solidity
error TokenFactory__InvalidSignature();
```
#### TokenFactory\_\_InvalidSignatureLength
```solidity
error TokenFactory__InvalidSignatureLength();
```
#### TokenFactory\_\_InvalidManagementFees
```solidity
error TokenFactory__InvalidManagementFees();
```
#### TokenFactory\_\_SmartTokenArrayOutOfBounds
```solidity
error TokenFactory__SmartTokenArrayOutOfBounds();
```
#### TokenFactory\_\_NoPremiumsToDrain
```solidity
error TokenFactory__NoPremiumsToDrain();
```
### Structs
#### RebalanceElements
```solidity
struct RebalanceElements {
uint256 BalanceFactorXY;
uint256 BalanceFactorUx;
uint256 BalanceFactorUy;
}
```
#### UserRebalanceElements
```solidity
struct UserRebalanceElements {
uint256 netX;
uint256 netY;
uint256 Ux;
uint256 Uy;
}
```
# SmartTokens
The rON/rOFF
## SmartToken
[Git Source](https://github.com/RiskProtocol/core-protocol/blob/d59ee719f0b8aa5daeb239f6468bda6d3a1b56be/contracts/vaults/SmartToken.sol)
**Inherits:** Initializable, UUPSUpgradeable, OwnableUpgradeable, ERC20Upgradeable, ERC20PermitUpgradeable, BaseContract, IERC4626Upgradeable, ReentrancyGuardUpgradeable, FlashloanSpecifics
*This is a rebalancing token, part of Risk Protocol's system The same contract is used by both RiskON and RiskOFF Whenever a user deposit a unit of underlying in the Vault(TokenFactory), the user is expected to recieve a unit of both RiskON and RiskOFF. At every rebalance operation, the user RiskOn/OFF balances will be aligned with respect to the rebalance math.*
### State Variables
#### tokenFactory
The tokenFactory instance
```solidity
TokenFactory private tokenFactory;
```
#### underlyingToken
The underlyingToken instance
```solidity
IERC20Update private underlyingToken;
```
#### isX
```solidity
bool private isX;
```
#### isNativeToken
```solidity
bool private isNativeToken;
```
#### weth
```solidity
IWETH private weth;
```
#### premiumDenominator
```solidity
uint16 private constant premiumDenominator = 10000;
```
### Functions
#### onlyTokenFactory
*Ensures that the function is only callable by the TokenFactory contract. Calls the helper function `_onlyTokenFactory` to check the caller.*
```solidity
modifier onlyTokenFactory();
```
#### onlyAssetOwner
*Ensures that the function is only callable by the token owner/holder. Calls the helper function `_onlyAssetOwner` to check the caller against the provided token owner/holder address.*
```solidity
modifier onlyAssetOwner(address assetOwner);
```
**Parameters**
| Name | Type | Description |
| ------------ | --------- | -------------------------------------- |
| `assetOwner` | `address` | The address of the token owner/holder. |
#### validateDepositAmount
*Validates the deposit amount to ensure it is not 0 or more than the receiver can get. Calls the helper function `_validateDepositAmount` to check the deposit amount and receiver.*
```solidity
modifier validateDepositAmount(uint256 assets, address receiver);
```
**Parameters**
| Name | Type | Description |
| ---------- | --------- | ---------------------------------- |
| `assets` | `uint256` | The amount of token to deposit. |
| `receiver` | `address` | The address receiving the deposit. |
#### insufficientUnderlying
*Validates if the underlying locked is always >= than the total supply of riskON/OFF reverts if not*
```solidity
modifier insufficientUnderlying();
```
#### depositLimitHit
*Validates if the user has hit the periodic deposit limit prevents the user from depositing more if hit*
```solidity
modifier depositLimitHit(uint256 amount);
```
**Parameters**
| Name | Type | Description |
| -------- | --------- | ------------------------------- |
| `amount` | `uint256` | The amount of token to deposit. |
#### withdrawLimitHit
*Validates if the user has hit the periodic withdraw limit prevents the user from withdrawing more if hit*
```solidity
modifier withdrawLimitHit(uint256 amount);
```
**Parameters**
| Name | Type | Description |
| -------- | --------- | -------------------------------- |
| `amount` | `uint256` | The amount of token to withdraw. |
#### dailyFFUpdate
```solidity
modifier dailyFFUpdate();
```
#### expiryDateCheck
```solidity
modifier expiryDateCheck(uint256 expiryDate);
```
#### constructor
**Note:** oz-upgrades-unsafe-allow: constructor
```solidity
constructor();
```
#### initialize
Initializes(replacement for the constructor) the SmartToken contract with specified parameters.
*This function sets up the initial state of the SmartToken contract. Callable only once. It initializes inherited contracts and sets the initial values for `tokenFactory` and `underlyingToken`.*
```solidity
function initialize(
string memory tokenName,
string memory tokenSymbol,
address factoryAddress,
address sanctionsContract_,
bool isX_,
address owner_
) public initializer;
```
**Parameters**
| Name | Type | Description |
| -------------------- | --------- | ------------------------------------------ |
| `tokenName` | `string` | The name of the token. |
| `tokenSymbol` | `string` | The symbol of the token. |
| `factoryAddress` | `address` | The address of the TokenFactory contract. |
| `sanctionsContract_` | `address` | The address of the SanctionsList contract. |
| `isX_` | `bool` | |
| `owner_` | `address` | |
#### receive
```solidity
receive() external payable;
```
#### drain
method to drain contracts of any ethers
*This function can only be called by the contract owner.*
```solidity
function drain(address receiver) external onlyOwner;
```
**Parameters**
| Name | Type | Description |
| ---------- | --------- | -------------------------------------------------------- |
| `receiver` | `address` | The address of the account that will receive the ethers. |
#### \_authorizeUpgrade
Authorizes an upgrade to a new contract implementation.
*This function can only be called by the contract owner. It overrides the `_authorizeUpgrade` function from the `UUPSUpgradeable` contract to include the `onlyOwner` modifier, ensuring only the owner can authorize upgrades.*
```solidity
function _authorizeUpgrade(address) internal override onlyOwner;
```
#### mintAsset
Mints the specified amount of tokens to the receiver.
*This function can only be called by the TokenFactory contract.*
```solidity
function mintAsset(address receiver, uint256 amount) external onlyTokenFactory;
```
**Parameters**
| Name | Type | Description |
| ---------- | --------- | --------------------------------------------------------------- |
| `receiver` | `address` | The address of the account that will receive the minted tokens. |
| `amount` | `uint256` | The amount of tokens to mint. |
#### burn
Burns the specified amount of tokens from the account.
*This function can only be called by the TokenFactory contract.*
```solidity
function burn(address account, uint256 amount) external onlyTokenFactory;
```
**Parameters**
| Name | Type | Description |
| --------- | --------- | ------------------------------------------------------------ |
| `account` | `address` | The address of the account from which tokens will be burned. |
| `amount` | `uint256` | The amount of tokens to burn. |
#### transfer
Transfers the specified amount of tokens to the specified recipient.
*Overrides the `transfer` function from `ERC20Upgradeable` and `IERC20Upgradeable` contracts. If the sender or receiver has a pending rebalance, it is handled before the transfer. This function can only be called when transfers are not stopped, and neither the sender nor the recipient are on the sanctions list.*
```solidity
function transfer(address recipient, uint256 amount)
public
override(ERC20Upgradeable, IERC20Upgradeable)
stopTransfer
insufficientUnderlying
onlyNotSanctioned(recipient)
onlyNotSanctioned(_msgSender())
dailyFFUpdate
returns (bool);
```
**Parameters**
| Name | Type | Description |
| ----------- | --------- | ------------------------------------------------ |
| `recipient` | `address` | The address to which tokens will be transferred. |
| `amount` | `uint256` | The amount of tokens to transfer. |
**Returns**
| Name | Type | Description |
| -------- | ------ | ---------------------------------- |
| `` | `bool` | Always return true unless reverted |
#### smartTreasuryTransfer
```solidity
function smartTreasuryTransfer(address treasuryAddress, uint256 amount) external onlyTokenFactory;
```
#### smartBalanceAdjust
```solidity
function smartBalanceAdjust(address account, uint256 amount) external onlyTokenFactory;
```
#### balanceOf
Returns the balance of the specified account
*Overrides the `balanceOf` function from the inherited `ERC20Upgradeable` and `IERC20Upgradeable` contracts. If the account has a pending rebalance, the function calculates the calculated balance post rebalance using the 'calculateRollOverValue' method. Otherwise, it returns the erc20 balance using `unScaledbalanceOf` method.*
```solidity
function balanceOf(address account) public view override(ERC20Upgradeable, IERC20Upgradeable) returns (uint256);
```
**Parameters**
| Name | Type | Description |
| --------- | --------- | ----------------------------------------------------------- |
| `account` | `address` | The address of the account whose balance will be retrieved. |
**Returns**
| Name | Type | Description |
| -------- | --------- | ------------------------------------- |
| `` | `uint256` | The balance of the specified account. |
#### unScaledbalanceOf
Returns the unscaled(unaffected by pending rebalances) balance of the specified account.
*This function returns the ERC20 balance(unaffected by pending rebalances) of the account.*
```solidity
function unScaledbalanceOf(address account) public view returns (uint256);
```
**Parameters**
| Name | Type | Description |
| --------- | --------- | --------------------------- |
| `account` | `address` | The address of the account. |
**Returns**
| Name | Type | Description |
| -------- | --------- | -------------------------------------------------------------------------------- |
| `` | `uint256` | The unscaled(unaffected by pending rebalances) balance of the specified account. |
#### hasPendingRebalance
Checks if the specified account has a pending rebalance.
*Compares the account's last rebalance count with the current scalingfactor length to determine if a rebalance is pending.*
```solidity
function hasPendingRebalance(address account) public view returns (bool);
```
**Parameters**
| Name | Type | Description |
| --------- | --------- | -------------------------- |
| `account` | `address` | The address of the account |
**Returns**
| Name | Type | Description |
| -------- | ------ | --------------------------------------------------------------------------------- |
| `` | `bool` | A boolean value indicating whether the specified account has a pending rebalance. |
#### getTokenFactory
Retrieves the address of the Vault (TokenFactory) contract.
*This function casts the `tokenFactory` variable to an address and returns it.*
```solidity
function getTokenFactory() public view returns (address);
```
**Returns**
| Name | Type | Description |
| -------- | --------- | ------------------------------------------------- |
| `` | `address` | The address of the Vault (TokenFactory) contract. |
#### transferFrom
Transfers the specified amount of tokens from the sender to the recipient.
*Overrides the `transferFrom` function from the inherited `ERC20Upgradeable` and `IERC20Upgradeable` contracts. If the sender or recipient has a pending rebalance, it is handled before the transfer. This function can only be called when transfers are not stopped, and neither the sender nor the recipient are on the sanctions list.*
```solidity
function transferFrom(address sender, address recipient, uint256 amount)
public
override(ERC20Upgradeable, IERC20Upgradeable)
stopTransfer
insufficientUnderlying
dailyFFUpdate
onlyNotSanctioned(recipient)
onlyNotSanctioned(sender)
returns (bool);
```
**Parameters**
| Name | Type | Description |
| ----------- | --------- | -------------------------------------------------- |
| `sender` | `address` | The address from which tokens will be transferred. |
| `recipient` | `address` | The address to which tokens will be transferred. |
| `amount` | `uint256` | The amount of tokens to transfer. |
**Returns**
| Name | Type | Description |
| -------- | ------ | ----------------------------------------------------------- |
| `` | `bool` | A boolean value indicating whether the operation succeeded. |
#### handlePendingRebalance
Handles pending rebalances for the sender and receiver addresses.
*This function checks if the sender or receiver has a pending rebalance and applies the rebalance if needed.*
```solidity
function handlePendingRebalance(address sender, address receiver) public;
```
**Parameters**
| Name | Type | Description |
| ---------- | --------- | ------------------------------------------------------------- |
| `sender` | `address` | The address of the sender involved in a transfer operation. |
| `receiver` | `address` | The address of the receiver involved in a transfer operation. |
#### asset
Retrieves the address of the underlying token.
*It overrides the `asset` function from the `IERC4626Upgradeable` interface.*
```solidity
function asset() public view virtual override returns (address);
```
**Returns**
| Name | Type | Description |
| -------- | --------- | ------------------------------------ |
| `` | `address` | The address of the underlying token. |
#### totalAssets
Retrieves the total amount of assets held by the TokenFactory.
*It overrides the `totalAssets` function from the `IERC4626Upgradeable` interface.*
```solidity
function totalAssets() public view virtual override returns (uint256);
```
**Returns**
| Name | Type | Description |
| -------- | --------- | ----------------------------------------------------------- |
| `` | `uint256` | The total amount of assets held by the Vault(TokenFactory). |
#### convertToShares
Converts a specified amount of underlying assets to shares(RiskOn/Off).
*It overrides the `convertToShares` function from the `IERC4626Upgradeable` interface.*
```solidity
function convertToShares(uint256 assets) public view virtual override returns (uint256 shares);
```
**Parameters**
| Name | Type | Description |
| -------- | --------- | ------------------------------------------ |
| `assets` | `uint256` | The amount of assets to convert to shares. |
**Returns**
| Name | Type | Description |
| -------- | --------- | ---------------------------------------------------------- |
| `shares` | `uint256` | The amount of shares(RiskOn/Off) for the amount of assets. |
#### convertToAssets
Converts a specified amount of shares(RiskOn/Off) to underlying assets.
*It overrides the `convertToAssets` function from the `IERC4626Upgradeable` interface.*
```solidity
function convertToAssets(uint256 shares) public view virtual override returns (uint256 assets);
```
**Parameters**
| Name | Type | Description |
| -------- | --------- | ------------------------------------------ |
| `shares` | `uint256` | The amount of shares to convert to assets. |
**Returns**
| Name | Type | Description |
| -------- | --------- | ---------------------------------------------------------- |
| `assets` | `uint256` | The amount of assets for the amount of shares(RiskOn/Off). |
#### maxDeposit
Calculates the maximum amount of assets that can be deposited by a specific account.
*It overrides the `maxDeposit` function from the `IERC4626Upgradeable` interface.*
```solidity
function maxDeposit(address account) public view virtual override returns (uint256);
```
**Parameters**
| Name | Type | Description |
| --------- | --------- | ----------------------------------------------------------------------------- |
| `account` | `address` | The address of the account for which to calculate the maximum deposit amount. |
**Returns**
| Name | Type | Description |
| -------- | --------- | ------------------------------------------------------------------ |
| `` | `uint256` | The maximum amount of assets that can be deposited by the account. |
#### previewDeposit
Provides a preview of the number of shares(RiskOn/Off) that would be received for a amount of assets.
*It overrides the `previewDeposit` function from the `IERC4626Upgradeable` interface.*
```solidity
function previewDeposit(uint256 assets) public view virtual override returns (uint256);
```
**Parameters**
| Name | Type | Description |
| -------- | --------- | -------------------------------------------- |
| `assets` | `uint256` | The amount of assets to preview the deposit. |
**Returns**
| Name | Type | Description |
| -------- | --------- | -------------------------------------------------------------------- |
| `` | `uint256` | The amount of shares(RiskOn/Off) for the specified amount of assets. |
#### deposit
Deposits an amount of underlying assets, crediting the shares(RiskON/OFF) to the receiver.
*It overrides the `deposit` function from the `IERC4626Upgradeable` interface. The `stopDeposit` circuit breaker can be used to freeze deposits and `validateDepositAmount` modifier to validate the deposit amount*
```solidity
function deposit(uint256 assets, address receiver)
public
virtual
override
stopDeposit
insufficientUnderlying
dailyFFUpdate
depositLimitHit(assets)
validateDepositAmount(assets, receiver)
returns (uint256);
```
**Parameters**
| Name | Type | Description |
| ---------- | --------- | -------------------------------- |
| `assets` | `uint256` | The amount of assets to deposit. |
| `receiver` | `address` | The receiver address. |
**Returns**
| Name | Type | Description |
| -------- | --------- | ------------------------------------------------------- |
| `` | `uint256` | The amount of shares(RiskOn/Off) the receiver will get. |
#### depositWithPermit
Deposits an amount of underlying assets, crediting the shares(RiskON/OFF) to the receiver with an EIP-2612 permit for approval.
*It overrides the `deposit` function from the `IERC4626Upgradeable` interface. The `stopDeposit` circuit breaker can be used to freeze deposits and `validateDepositAmount` modifier to validate the deposit amount then calls `permit` on the `underlyingToken` to set the allowance,*
```solidity
function depositWithPermit(uint256 assets, address receiver, uint256 deadline, uint8 v, bytes32 r, bytes32 s)
public
stopDeposit
insufficientUnderlying
dailyFFUpdate
depositLimitHit(assets)
validateDepositAmount(assets, receiver)
returns (uint256);
```
**Parameters**
| Name | Type | Description |
| ---------- | --------- | ----------------------------------------------------------------------- |
| `assets` | `uint256` | The amount of underlying assets to deposit. |
| `receiver` | `address` | The address of the receiver |
| `deadline` | `uint256` | The deadline for the permit signature to be valid, as a UNIX timestamp. |
| `v` | `uint8` | The recovery byte of the signature. |
| `r` | `bytes32` | part of the ECDSA signature pair. |
| `s` | `bytes32` | part of the ECDSA signature pair. |
**Returns**
| Name | Type | Description |
| -------- | --------- | ------------------------------------------------------ |
| `` | `uint256` | The amount of shares(RiskOn/Off) the receiber will get |
#### depositWithExpiry
Deposits an amount of underlying assets, crediting the shares(RiskON/OFF) to the receiver.
*It overrides the `deposit` function from the `IERC4626Upgradeable` interface. The `stopDeposit` circuit breaker can be used to freeze deposits and `validateDepositAmount` modifier to validate the deposit amount*
```solidity
function depositWithExpiry(uint256 assets, address receiver, uint256 expiryDate)
public
virtual
expiryDateCheck(expiryDate)
stopDeposit
insufficientUnderlying
dailyFFUpdate
depositLimitHit(assets)
validateDepositAmount(assets, receiver)
returns (uint256);
```
**Parameters**
| Name | Type | Description |
| ------------ | --------- | -------------------------------- |
| `assets` | `uint256` | The amount of assets to deposit. |
| `receiver` | `address` | The receiver address. |
| `expiryDate` | `uint256` | The expiry date for the deposit. |
**Returns**
| Name | Type | Description |
| -------- | --------- | ------------------------------------------------------- |
| `` | `uint256` | The amount of shares(RiskOn/Off) the receiver will get. |
#### depositWithNative
Deposits an amount of underlying (NATIVE) assets, crediting the shares(RiskON/OFF) to the receiver.
*It uses msg.value as the deposit amount. The `stopDeposit` circuit breaker can be used to freeze deposits and `validateDepositAmount` modifier to validate the deposit amount*
```solidity
function depositWithNative(address receiver)
public
payable
virtual
nonReentrant
stopDeposit
insufficientUnderlying
dailyFFUpdate
depositLimitHit(msg.value)
validateDepositAmount(msg.value, receiver)
returns (uint256);
```
**Parameters**
| Name | Type | Description |
| ---------- | --------- | --------------------- |
| `receiver` | `address` | The receiver address. |
**Returns**
| Name | Type | Description |
| -------- | --------- | ------------------------------------------------------- |
| `` | `uint256` | The amount of shares(RiskOn/Off) the receiver will get. |
#### maxMint
Calculates the maximum amount of shares(RiskOn/Off) that can be minted for a user.
*It overrides the `maxMint` function from the `IERC4626Upgradeable` interface.*
```solidity
function maxMint(address account) public view virtual override returns (uint256);
```
**Parameters**
| Name | Type | Description |
| --------- | --------- | ----------------------------------------------------------------------------------- |
| `account` | `address` | The address of user for which to calculate the maximum mintable shares(RiskOn/Off). |
**Returns**
| Name | Type | Description |
| -------- | --------- | ------------------------------------------------------------------------- |
| `` | `uint256` | The maximum amount of shares(RiskOn/Off) that can be minted for the user. |
#### previewMint
Provides a preview of the amount of underlying assets required to mint a number of shares(RiskOn/Off).
*It overrides the `previewMint` function from the `IERC4626Upgradeable` interface.*
```solidity
function previewMint(uint256 shares) public view virtual override returns (uint256);
```
**Parameters**
| Name | Type | Description |
| -------- | --------- | ----------------------------------------- |
| `shares` | `uint256` | The number of shares(RiskOn/Off) to mint. |
**Returns**
| Name | Type | Description |
| -------- | --------- | -------------------------------------------------------------------------------------------- |
| `` | `uint256` | The amount of underlying assets required to mint the specified number of shares(RiskOn/Off). |
#### mint
mints an amount of shares, crediting the shares(RiskON/OFF) to the receiver.
*It overrides the `deposit` function from the `IERC4626Upgradeable` interface. The `stopDeposit` circuit breaker can be used to freeze minting. As opposed to deposit, minting is allowed even if the vault is in a state where the price of a share is zero. In this case, the shares will be minted without requiring any assets to be deposited.*
```solidity
function mint(uint256 shares, address receiver)
public
virtual
override
stopDeposit
insufficientUnderlying
dailyFFUpdate
depositLimitHit(shares)
returns (uint256);
```
**Parameters**
| Name | Type | Description |
| ---------- | --------- | ----------------------------------------- |
| `shares` | `uint256` | The amount of shares(RiskON/OFF) to mint. |
| `receiver` | `address` | The receiver address. |
**Returns**
| Name | Type | Description |
| -------- | --------- | -------------------------------------------------------------------------------------------- |
| `` | `uint256` | The amount of assets that were deposited to mint the specified number of shares(RiskON/OFF). |
#### maxWithdraw
Calculates the maximum amount of underlying assets that can be withdrawn by a specified owner.
*It overrides the `maxWithdraw` function from the `IERC4626Upgradeable` interface.*
```solidity
function maxWithdraw(address owner_) public view virtual override returns (uint256);
```
**Parameters**
| Name | Type | Description |
| -------- | --------- | ------------------------------------------------------------------------------------------- |
| `owner_` | `address` | The address of the owner for which to calculate the maximum underlying withdrawable assets. |
**Returns**
| Name | Type | Description |
| -------- | --------- | -------------------------------------------------------------------------- |
| `` | `uint256` | The maximum amount of assets that can be withdrawn by the specified owner. |
#### previewWithdraw
Provide a preview of number of shares(RiskOn/Off) required to withdraw an amount of underlying assets.
*It overrides the `previewWithdraw` function from the `IERC4626Upgradeable` interface.*
```solidity
function previewWithdraw(uint256 assets) public view virtual override returns (uint256);
```
**Parameters**
| Name | Type | Description |
| -------- | --------- | --------------------------------- |
| `assets` | `uint256` | The amount of assets to withdraw. |
**Returns**
| Name | Type | Description |
| -------- | --------- | ------------------------------------------------------------------------------------- |
| `` | `uint256` | The number of shares(RiskOn/Off) required to withdraw the specified amount of assets. |
#### withdraw
Allows an owner to withdraw a specified amount of underlying assets, transferring them to a receiver.
*This function overrides the `withdraw` function from the `IERC4626Upgradeable` interface, and is guarded by the `stopWithdraw`, `onlyAssetOwner`, and `nonReentrant` modifiers.*
```solidity
function withdraw(uint256 assets, address receiver, address owner_)
public
virtual
override
stopWithdraw
insufficientUnderlying
dailyFFUpdate
withdrawLimitHit(assets)
onlyAssetOwner(owner_)
nonReentrant
returns (uint256);
```
**Parameters**
| Name | Type | Description |
| ---------- | --------- | ------------------------------------------------------ |
| `assets` | `uint256` | The amount of underlying assets to withdraw. |
| `receiver` | `address` | The address to which the assets should be transferred. |
| `owner_` | `address` | The address of the owner making the withdrawal. |
**Returns**
| Name | Type | Description |
| -------- | --------- | ----------------------------------------------------------------------- |
| `` | `uint256` | The number of shares(RiskON/OFF) corresponding to the withdrawn assets. |
#### withdrawWithExpiry
Allows an owner to withdraw a specified amount of underlying assets, transferring them to a receiver.
*This function overrides the `withdraw` function from the `IERC4626Upgradeable` interface, and is guarded by the `stopWithdraw`, `onlyAssetOwner`, and `nonReentrant` modifiers.*
```solidity
function withdrawWithExpiry(uint256 assets, address receiver, address owner_, uint256 expiryDate)
public
virtual
expiryDateCheck(expiryDate)
stopWithdraw
insufficientUnderlying
dailyFFUpdate
withdrawLimitHit(assets)
onlyAssetOwner(owner_)
nonReentrant
returns (uint256);
```
**Parameters**
| Name | Type | Description |
| ------------ | --------- | ------------------------------------------------------ |
| `assets` | `uint256` | The amount of underlying assets to withdraw. |
| `receiver` | `address` | The address to which the assets should be transferred. |
| `owner_` | `address` | The address of the owner making the withdrawal. |
| `expiryDate` | `uint256` | The expiry date for the withdrawal. |
**Returns**
| Name | Type | Description |
| -------- | --------- | ----------------------------------------------------------------------- |
| `` | `uint256` | The number of shares(RiskON/OFF) corresponding to the withdrawn assets. |
#### flashLoan
Allows user to take flashloans from the tokenFactory (Vault/POOL)
*This function is guarded by the `nonReentrant` and `stopFlashLoan` modifiers. It makes use of AAVE's flashloan interface to provide backwards compatibility for ease of use*
```solidity
function flashLoan(address receiver, uint256 amount, bytes memory params)
external
nonReentrant
stopFlashLoan
onlyNotSanctioned(receiver)
onlyNotSanctioned(_msgSender());
```
**Parameters**
| Name | Type | Description |
| ---------- | --------- | --------------------------------------------------------------------------------- |
| `receiver` | `address` | The address of the receiver. |
| `amount` | `uint256` | The amount of underlying assets to flashloan. |
| `params` | `bytes` | The parameters for the flashloan. Used by the receiver contract(Aave's interface) |
#### maxRedeem
Computes the maximum amount of underlying assets that can be redeemed by owner.
*It overrides the `maxRedeem` function from the `IERC4626Upgradeable` interface.*
```solidity
function maxRedeem(address owner_) public view virtual override returns (uint256);
```
**Parameters**
| Name | Type | Description |
| -------- | --------- | ------------------------- |
| `owner_` | `address` | The address of the owner. |
**Returns**
| Name | Type | Description |
| -------- | --------- | ------------------------------------------------------------------ |
| `` | `uint256` | The maximum amount of underlying assets that the owner can redeem. |
#### previewRedeem
Provides a preview of the amount of underlying assets that would be received when redeeming a number of shares(RiskON/OFF).
*It overrides the `previewRedeem` function from the `IERC4626Upgradeable` interface.*
```solidity
function previewRedeem(uint256 shares) public view virtual override returns (uint256);
```
**Parameters**
| Name | Type | Description |
| -------- | --------- | --------------------------------------------------------------------------------------- |
| `shares` | `uint256` | The number of shares(RiskON/OFF) to compute the equivalent underlying asset amount for. |
**Returns**
| Name | Type | Description |
| -------- | --------- | ----------------------------------------------------------------------- |
| `` | `uint256` | The equivalent asset amount for the given number of shares(RiskON/OFF). |
#### redeem
Allows a user to redeem some amount of underlying assets based on an input amount of shares(RiskON/OFF).
*See IERC4626-redeem.*
*It overrides the `redeem` function from the `IERC4626Upgradeable` interface. and is guarded by the `stopWithdraw`, `onlyAssetOwner`, and `nonReentrant` modifiers.*
```solidity
function redeem(uint256 shares, address receiver, address owner_)
public
virtual
override
stopWithdraw
insufficientUnderlying
dailyFFUpdate
withdrawLimitHit(shares)
onlyAssetOwner(owner_)
nonReentrant
returns (uint256);
```
**Parameters**
| Name | Type | Description |
| ---------- | --------- | ----------------------------------------------------------------- |
| `shares` | `uint256` | The number of shares(RiskON/OFF) to redeem for underlying assets. |
| `receiver` | `address` | The address of receiver. |
| `owner_` | `address` | The address of the owner. |
**Returns**
| Name | Type | Description |
| -------- | --------- | ----------------------------------------- |
| `` | `uint256` | The amount of underlying assets redeemed. |
#### \_onlyTokenFactory
Helpers for modifiers to reduce size
Checks if the caller is the Vault (tokenFactory)
*This function is utilized by the `onlyTokenFactory` modifier to ensure that only the token factory can call certain functions.*
```solidity
function _onlyTokenFactory() private view;
```
#### \_onlyAssetOwner
Checks if the caller is the asset owner.
*This function is utilized by the `onlyAssetOwner` modifier to ensure that only the asset owner can call certain functions.*
```solidity
function _onlyAssetOwner(address assetOwner) private view;
```
**Parameters**
| Name | Type | Description |
| ------------ | --------- | ------------------------------- |
| `assetOwner` | `address` | The address of the asset owner. |
#### \_validateDepositAmount
Validates the deposit amount.
*This function is utilized by the `validateDepositAmount` modifier to ensure that the deposit amount is neither zero nor exceeds the maximum allowed deposit for the receiver.*
```solidity
function _validateDepositAmount(uint256 assets, address receiver) private view;
```
**Parameters**
| Name | Type | Description |
| ---------- | --------- | ------------------------------------------------ |
| `assets` | `uint256` | The amount of underlying assets being deposited. |
| `receiver` | `address` | The address of the receiver |
#### hasPendingFF
```solidity
function hasPendingFF(address account) public view returns (bool);
```
#### handlePendingFF
```solidity
function handlePendingFF(address sender, address receiver) public;
```
#### \_handleDeposit
```solidity
function _handleDeposit(uint256 assets, address receiver) private returns (uint256);
```
**Parameters**
| Name | Type | Description |
| ---------- | --------- | ------------------------------------------------------------------------------------------------------- |
| `assets` | `uint256` | The amount of underlying assets to deposit.\@note WE can use SHARES as well since it's a 1:1 conversion |
| `receiver` | `address` | The address to which the assets should be transferred. |
#### \_handleWithdraw
```solidity
function _handleWithdraw(uint256 assets, address receiver, address owner_) private returns (uint256);
```
**Parameters**
| Name | Type | Description |
| ---------- | --------- | -------------------------------------------------------------------------------------------------------- |
| `assets` | `uint256` | The amount of underlying assets to withdraw. @note WE can use SHARES as well since it's a 1:1 conversion |
| `receiver` | `address` | The address to which the assets should be transferred. |
| `owner_` | `address` | The address of the owner making the withdrawal. |
#### getFlashLoanPool
Retrieves the address of the flashloan POOL (TokenFactory) contract.
*This function casts the `tokenFactory` variable to an address and returns it.*
```solidity
function getFlashLoanPool() public view returns (address);
```
**Returns**
| Name | Type | Description |
| -------- | --------- | ---------------------------------------------------------- |
| `` | `address` | The address of the flashloan POOL (TokenFactory) contract. |
### Errors
#### SmartToken\_\_NotTokenFactory
```solidity
error SmartToken__NotTokenFactory();
```
#### SmartToken\_\_MethodNotAllowed
```solidity
error SmartToken__MethodNotAllowed();
```
#### SmartToken\_\_DepositMoreThanMax
```solidity
error SmartToken__DepositMoreThanMax();
```
#### SmartToken\_\_MintMoreThanMax
```solidity
error SmartToken__MintMoreThanMax();
```
#### SmartToken\_\_WithdrawMoreThanMax
```solidity
error SmartToken__WithdrawMoreThanMax();
```
#### SmartToken\_\_RedeemMoreThanMax
```solidity
error SmartToken__RedeemMoreThanMax();
```
#### SmartToken\_\_OnlyAssetOwner
```solidity
error SmartToken__OnlyAssetOwner();
```
#### SmartToken\_\_ZeroDeposit
```solidity
error SmartToken__ZeroDeposit();
```
#### SmartToken\_\_InsufficientUnderlying
```solidity
error SmartToken__InsufficientUnderlying();
```
#### SmartToken\_\_DepositLimitHit
```solidity
error SmartToken__DepositLimitHit();
```
#### SmartToken\_\_WithdrawLimitHit
```solidity
error SmartToken__WithdrawLimitHit();
```
#### SmartToken\_\_ExpiryDateReached
```solidity
error SmartToken__ExpiryDateReached();
```
#### SmartToken\_\_WithdrawNativeFailed
```solidity
error SmartToken__WithdrawNativeFailed();
```
# Wrapped SmartTokens
Wrapped rON/rOFF
## wrappedSmartToken
[Git Source](https://github.com/RiskProtocol/core-protocol/blob/d59ee719f0b8aa5daeb239f6468bda6d3a1b56be/contracts/vaults/wrapped/WrappedSmartToken.sol)
**Inherits:** UnbuttonToken, UUPSUpgradeable, OwnableUpgradeable, FlashloanSpecifics, BaseContract
### State Variables
#### sellingToken
```solidity
address private sellingToken;
```
#### isWrappedX
```solidity
bool private isWrappedX;
```
#### timeout
```solidity
uint256 private timeout;
```
#### SCALING\_FACTOR
```solidity
uint256 private constant SCALING_FACTOR = 10 ** 18;
```
#### orchestrator
```solidity
address private orchestrator;
```
#### premiumPercentage
```solidity
uint16 private premiumPercentage;
```
#### premiumDenominator
```solidity
uint16 private constant premiumDenominator = 10000;
```
#### signers
This is the signers address of RP api's that generate encoded params for rebalance
```solidity
mapping(address => bool) private signers;
```
#### currentDiscountRates
```solidity
DiscountRates private currentDiscountRates;
```
#### \_activeLoan
```solidity
LoanType private _activeLoan;
```
### Functions
#### onlyOrchestrator
```solidity
modifier onlyOrchestrator();
```
#### CustomNonReentrant
```solidity
modifier CustomNonReentrant(LoanType loanType);
```
#### constructor
**Note:** oz-upgrades-unsafe-allow: constructor
```solidity
constructor();
```
#### riskInitialize
```solidity
function riskInitialize(
address underlying_,
address sellingToken_,
string memory name_,
string memory symbol_,
uint256 initialRate,
bool isWrappedX_,
address owner_,
address signer,
uint256 timeout_,
address sanctionsContract_,
address orchestrator_
) public initializer;
```
#### initialize
```solidity
function initialize(address underlying_, string memory name_, string memory symbol_, uint256 initialRate)
public
pure
override;
```
#### \_authorizeUpgrade
```solidity
function _authorizeUpgrade(address newImplementation) internal override onlyOwner;
```
#### flashLoanAlt
Allows user to take flashloans from the wrapper
*This function is guarded by the `nonReentrant` modifiers. we offer unwanted tokens (sellingToken) in exchange of underlying tokens*
```solidity
function flashLoanAlt(
address receiver,
uint256 amount,
bytes memory encodedData,
bytes memory signature,
bytes memory params
)
external
CustomNonReentrant(LoanType.FLASHLOANALT)
stopFlashLoan
onlyNotSanctioned(receiver)
onlyNotSanctioned(_msgSender());
```
**Parameters**
| Name | Type | Description |
| ------------- | --------- | --------------------------------------------------------------------------------- |
| `receiver` | `address` | The address of the receiver. |
| `amount` | `uint256` | The amount of underlying assets to flashloan. |
| `encodedData` | `bytes` | |
| `signature` | `bytes` | |
| `params` | `bytes` | The parameters for the flashloan. Used by the receiver contract(Aave's interface) |
#### flashLoan
Allows user to take flashloans from the wrapper (Vault/POOL)
*This function is guarded by the `nonReentrant` and `stopFlashLoan` modifiers. It makes use of AAVE's flashloan interface to provide backwards compatibility for ease of use*
```solidity
function flashLoan(address receiver, uint256 amount, bytes memory params)
external
CustomNonReentrant(LoanType.FLASHLOAN)
stopFlashLoan
onlyNotSanctioned(receiver)
onlyNotSanctioned(_msgSender());
```
**Parameters**
| Name | Type | Description |
| ---------- | --------- | --------------------------------------------------------------------------------- |
| `receiver` | `address` | The address of the receiver. |
| `amount` | `uint256` | The amount of underlying assets to flashloan. |
| `params` | `bytes` | The parameters for the flashloan. Used by the receiver contract(Aave's interface) |
#### setTimeout
```solidity
function setTimeout(uint256 timeout_) external onlyOwner;
```
#### discountRateSetter
```solidity
function discountRateSetter(uint256 startTime, uint256 endTime, uint256 discountMin, uint256 discountMax)
private
returns (bool);
```
#### setDiscountRateOrchestrator
```solidity
function setDiscountRateOrchestrator(uint256 startTime, uint256 endTime, uint256 discountMin, uint256 discountMax)
external
onlyOrchestrator
returns (bool);
```
#### setDiscountRate
```solidity
function setDiscountRate(uint256 startTime, uint256 endTime, uint256 discountMin, uint256 discountMax)
external
onlyOwner
returns (bool);
```
#### setSigners
```solidity
function setSigners(address signer, bool status) external onlyOwner;
```
#### setPremiumPercentage
```solidity
function setPremiumPercentage(uint16 percentage) external onlyOwner;
```
#### setOrchestator
```solidity
function setOrchestator(address orchestrator_) external onlyOwner;
```
#### getFlashloanPremium
```solidity
function getFlashloanPremium() public view returns (uint16);
```
#### getIsWrappedX
```solidity
function getIsWrappedX() external view returns (bool);
```
#### getTimeout
```solidity
function getTimeout() external view returns (uint256);
```
#### getDiscountRate
```solidity
function getDiscountRate() external view returns (DiscountRates memory);
```
#### getSigners
```solidity
function getSigners(address signer) external view returns (bool);
```
#### calculateUserShare
```solidity
function calculateUserShare() private view returns (uint256);
```
#### refundUnwantedTokens
```solidity
function refundUnwantedTokens(address user) private;
```
#### getConversionRate
```solidity
function getConversionRate(PriceFeed memory priceFeed, uint256 t1, uint256 t2, uint256 x1, uint256 x2)
private
view
returns (uint256, uint256);
```
#### getOrchestrator
```solidity
function getOrchestrator() external view returns (address);
```
#### verifyAndDecode
Verifies the provided signature and decodes the encoded data into `ScheduledRebalance` struct.
*It recovers the address from the Ethereum signed message hash and the provided `signature`. If the recovered address doesn't match the `signersAddress`, it reverts the transaction. If the signature is valid, it decodes the `encodedData` into a `ScheduledRebalance` struct and returns it.*
```solidity
function verifyAndDecode(bytes memory signature, bytes memory encodedData) private view returns (PriceFeed memory);
```
**Parameters**
| Name | Type | Description |
| ------------- | ------- | ---------------------------------------------------------- |
| `signature` | `bytes` | The signature to be verified. |
| `encodedData` | `bytes` | The data to be decoded into a `ScheduledRebalance` struct. |
**Returns**
| Name | Type | Description |
| -------- | ----------- | --------------------------------------------------------------- |
| `` | `PriceFeed` | data A `ScheduledRebalance` struct containing the decoded data. |
#### burn
Burns wrapper tokens from {msg.sender} and transfers the underlying tokens back.
```solidity
function burn(uint256 amount) public override returns (uint256);
```
**Parameters**
| Name | Type | Description |
| -------- | --------- | ------------------------------------- |
| `amount` | `uint256` | The amount of wrapper tokens to burn. |
**Returns**
| Name | Type | Description |
| -------- | --------- | ------------------------------------------ |
| `` | `uint256` | The amount of underlying tokens withdrawn. |
#### burnTo
Burns wrapper tokens from {msg.sender} and transfers the underlying tokens to the specified beneficiary.
```solidity
function burnTo(address to, uint256 amount) public override returns (uint256);
```
**Parameters**
| Name | Type | Description |
| -------- | --------- | ------------------------------------- |
| `to` | `address` | The beneficiary account. |
| `amount` | `uint256` | The amount of wrapper tokens to burn. |
**Returns**
| Name | Type | Description |
| -------- | --------- | ------------------------------------------ |
| `` | `uint256` | The amount of underlying tokens withdrawn. |
#### burnAll
Burns all wrapper tokens from {msg.sender} and transfers the underlying tokens back.
```solidity
function burnAll() public override returns (uint256);
```
**Returns**
| Name | Type | Description |
| -------- | --------- | ------------------------------------------ |
| `` | `uint256` | The amount of underlying tokens withdrawn. |
#### burnAllTo
Burns all wrapper tokens from {msg.sender} and transfers the underlying tokens back.
```solidity
function burnAllTo(address to) public override returns (uint256);
```
**Parameters**
| Name | Type | Description |
| ---- | --------- | ------------------------ |
| `to` | `address` | The beneficiary account. |
**Returns**
| Name | Type | Description |
| -------- | --------- | ------------------------------------------ |
| `` | `uint256` | The amount of underlying tokens withdrawn. |
#### withdraw
Burns wrapper tokens from {msg.sender} and transfers the underlying tokens back.
```solidity
function withdraw(uint256 uAmount) public override returns (uint256);
```
**Parameters**
| Name | Type | Description |
| --------- | --------- | -------------------------------------------- |
| `uAmount` | `uint256` | The amount of underlying tokens to withdraw. |
**Returns**
| Name | Type | Description |
| -------- | --------- | ----------------------------------- |
| `` | `uint256` | The amount of wrapper tokens burnt. |
#### withdrawTo
Burns wrapper tokens from {msg.sender} and transfers the underlying tokens back to the specified beneficiary.
```solidity
function withdrawTo(address to, uint256 uAmount) public override returns (uint256);
```
**Parameters**
| Name | Type | Description |
| --------- | --------- | -------------------------------------------- |
| `to` | `address` | The beneficiary account. |
| `uAmount` | `uint256` | The amount of underlying tokens to withdraw. |
**Returns**
| Name | Type | Description |
| -------- | --------- | ----------------------------------- |
| `` | `uint256` | The amount of wrapper tokens burnt. |
#### withdrawAll
Burns all wrapper tokens from {msg.sender} and transfers the underlying tokens back.
```solidity
function withdrawAll() public override returns (uint256);
```
**Returns**
| Name | Type | Description |
| -------- | --------- | ----------------------------------- |
| `` | `uint256` | The amount of wrapper tokens burnt. |
#### withdrawAllTo
Burns all wrapper tokens from {msg.sender} and transfers the underlying tokens back.
```solidity
function withdrawAllTo(address to) public override returns (uint256);
```
**Parameters**
| Name | Type | Description |
| ---- | --------- | ------------------------ |
| `to` | `address` | The beneficiary account. |
**Returns**
| Name | Type | Description |
| -------- | --------- | ----------------------------------- |
| `` | `uint256` | The amount of wrapper tokens burnt. |
### Errors
#### WrappedSmartToken\_\_Not\_Implemented
```solidity
error WrappedSmartToken__Not_Implemented();
```
#### WrappedSmartToken\_\_PriceFeedOutdated
```solidity
error WrappedSmartToken__PriceFeedOutdated();
```
#### WrappedSmartToken\_\_InvalidSigner
```solidity
error WrappedSmartToken__InvalidSigner();
```
#### WrappedSmartToken\_\_InvalidDiscount
```solidity
error WrappedSmartToken__InvalidDiscount();
```
#### WrappedSmartToken\_\_InvalidOrchestrator
```solidity
error WrappedSmartToken__InvalidOrchestrator();
```
#### WrappedSmartToken\_\_ReEntrantCall
```solidity
error WrappedSmartToken__ReEntrantCall();
```
### Structs
#### PriceFeed
```solidity
struct PriceFeed {
uint256 smartTokenXValue;
uint256 smartTokenYValue;
uint256 timestamp;
}
```
#### DiscountRates
```solidity
struct DiscountRates {
uint256 startTime;
uint256 endTime;
uint256 discountMin;
uint256 discountMax;
}
```
### Enums
#### LoanType
```solidity
enum LoanType {
NONE,
FLASHLOAN,
FLASHLOANALT
}
```
# SDK
## SDK
The Risk Protocol SDK is a TypeScript library for interacting with Risk Protocol's core smart contracts and services. Built on ethers.js v6, it provides a complete interface for token management, vault operations, rebalancing, and price estimation.
### Installation
```bash
npm install risk-contracts
# or
yarn add risk-contracts
## Note that it's not published yet, the above is a placeholder
```
### Quick Start
#### Server-Side (Node.js)
```typescript
import { RiskContracts, RiskSdkConfig } from 'risk-contracts';
const config: RiskSdkConfig = {
serverProvider: {
rpcUrl: "https://eth-sepolia.g.alchemy.com/v2/YOUR_API_KEY",
privateKey: "YOUR_PRIVATE_KEY"
},
network: {
name: "sepolia",
chainId: 11155111
},
tokenFactory: {
address: "0x8888cF3da8E6Fb30bEEcD9dC1dd220060c2969DC"
},
smartToken: {
one: "0x...", // RiskON token address
two: "0x..." // RiskOFF token address
},
orchestrator: {
address: "0x..."
},
apiUrl: "https://api.riskprotocol.com"
};
const sdk = new RiskContracts(config);
```
#### Client-Side (Browser with Wallet)
```typescript
import { RiskContracts, RiskSdkConfig } from 'risk-contracts';
import { ethers } from 'ethers';
// Connect to user's wallet
const provider = new ethers.BrowserProvider(window.ethereum);
const signer = await provider.getSigner();
const config: RiskSdkConfig = {
clientProvider: {
provider: provider,
signer: signer
},
network: {
name: "sepolia",
chainId: 11155111
},
tokenFactory: {
address: "0x..."
},
smartToken: {
one: "0x...",
two: "0x..."
},
orchestrator: {
address: "0x..."
},
apiUrl: "https://api.riskprotocol.com"
};
const sdk = new RiskContracts(config);
```
### Configuration
The SDK requires a configuration object that specifies network settings, contract addresses, and provider details.
```typescript
interface RiskSdkConfig {
// Provider (choose one)
serverProvider?: {
rpcUrl: string;
privateKey: string;
};
clientProvider?: {
provider: ethers.BrowserProvider;
signer: ethers.JsonRpcSigner;
};
// Network configuration
network: {
name: string;
chainId: number;
};
// Contract addresses
tokenFactory: {
address: string;
};
smartToken: {
one: string; // RiskON address
two: string; // RiskOFF address
};
orchestrator: {
address: string;
};
// Optional: API URL for NTV price estimates
apiUrl?: string;
}
```
**Important:** Provide either `serverProvider` or `clientProvider`, not both.
### Core Concepts
#### SDK Structure
The SDK exposes five main modules:
* **tokenFactory** - Core token operations, management fees, and rebalancing
* **smartToken** - ERC-4626 vault operations (deposits, withdrawals, transfers)
* **orchestrator** - Scheduled operations and Balancer pool management
* **balancerHelper** - Balancer pool calculations and swap estimations
* **priceEstimates** - Price discovery and slippage calculations
#### Working with Amounts
All token amounts in the SDK use **wei units** (BigInt). Use ethers.js utilities for conversion:
```typescript
import { ethers } from 'ethers';
// Convert to wei
const amount = ethers.parseEther("1.5"); // 1500000000000000000n
// Convert from wei
const readable = ethers.formatEther(amount); // "1.5"
// For tokens with different decimals
const usdcAmount = ethers.parseUnits("100", 6); // 6 decimals
```
#### Smart Tokens
Risk Protocol uses two smart tokens: **RiskON** (index 0) and **RiskOFF** (index 1). Most SmartToken methods accept an optional `contract` parameter:
```typescript
// RiskON
await sdk.smartToken.balanceOf(address, 0);
// RiskOFF
await sdk.smartToken.balanceOf(address, 1);
```
### Common Workflows
#### 1. Deposit Tokens
```typescript
import { ethers } from 'ethers';
const depositAmount = ethers.parseEther("100");
const userAddress = "0x...";
// 1. Preview the deposit
const sharesReceived = await sdk.smartToken.transaction.previewDeposit(
depositAmount.toString(),
0 // RiskON
);
console.log(`Will receive ${ethers.formatEther(sharesReceived)} shares`);
// 2. Approve token spending (get smart token address first)
const baseToken = await sdk.tokenFactory.getBaseToken();
const riskOnAddress = await sdk.tokenFactory.getSmartTokenAddress(0);
const erc20 = new ethers.Contract(
baseToken,
['function approve(address,uint256) returns (bool)'],
signer
);
const approveTx = await erc20.approve(
riskOnAddress,
depositAmount
);
await approveTx.wait();
// 3. Execute deposit
const depositTx = await sdk.smartToken.transaction.deposit(
depositAmount.toString(),
userAddress,
0
);
await depositTx.wait();
console.log('Deposit successful!');
```
#### 2. Withdraw Tokens
```typescript
import { ethers } from 'ethers';
const withdrawAmount = ethers.parseEther("50");
const userAddress = "0x...";
// 1. Preview withdrawal
const assetsReceived = await sdk.smartToken.transaction.previewWithdraw(
withdrawAmount.toString(),
0
);
console.log(`Will receive ${ethers.formatEther(assetsReceived)} assets`);
// 2. Execute withdrawal
const withdrawTx = await sdk.smartToken.transaction.withdraw(
withdrawAmount.toString(),
userAddress,
userAddress,
0
);
await withdrawTx.wait();
console.log('Withdrawal successful!');
```
#### 3. Check Balances and Fees
```typescript
import { ethers } from 'ethers';
const userAddress = "0x...";
// Get share balance (RiskON)
const shares = await sdk.smartToken.balanceOf(userAddress, 0);
console.log(`Shares: ${ethers.formatEther(shares)}`);
// Get management fee rate
const feeRate = await sdk.tokenFactory.managementFees.getRate();
const feeRateBps = Number(feeRate) / 1e14; // Convert to basis points
console.log(`Management fee: ${feeRateBps} bps`);
// Check if fees are active
const isActive = await sdk.tokenFactory.managementFees.isFeeActive();
console.log(`Fees active: ${isActive}`);
```
#### 4. Estimate Swap Outputs
```typescript
import { ethers } from 'ethers';
const poolAddress = "0x...";
const riskOnAddress = await sdk.tokenFactory.getSmartTokenAddress(0);
const riskOffAddress = await sdk.tokenFactory.getSmartTokenAddress(1);
const amountIn = ethers.parseEther("10");
// Estimate swap output (RiskON → RiskOFF)
const expectedOut = await sdk.balancerHelper.getExpectedAmountOut(
poolAddress,
riskOnAddress, // RiskON
riskOffAddress, // RiskOFF
amountIn
);
console.log(`Swapping 10 RiskON`);
console.log(`Expected output: ${ethers.formatEther(expectedOut)} RiskOFF`);
```
####
### Error Handling
Always wrap SDK calls in try-catch blocks:
```typescript
try {
const tx = await sdk.smartToken.transaction.deposit(
amount.toString(),
recipient,
0
);
await tx.wait();
} catch (error) {
if (error.code === 'INSUFFICIENT_FUNDS') {
console.error('Insufficient funds for gas');
} else if (error.code === 'CALL_EXCEPTION') {
console.error('Transaction reverted:', error.reason);
} else {
console.error('Transaction failed:', error.message);
}
}
```
### Best Practices
#### 1. Always Preview Before Executing
```typescript
// Always preview first to show users what they'll receive
const preview = await sdk.smartToken.transaction.previewDeposit(amount, 0);
console.log(`You will receive ${ethers.formatEther(preview)} shares`);
```
#### 2. Check Maximum Limits
```typescript
const maxDeposit = await sdk.smartToken.transaction.maxDeposit(address, 0);
if (BigInt(amount) > maxDeposit) {
throw new Error(`Amount exceeds maximum: ${ethers.formatEther(maxDeposit)}`);
}
```
### TypeScript Support
The SDK is fully typed. Import types as needed:
```typescript
import { RiskContracts, RiskSdkConfig } from 'risk-contracts';
import type { ethers } from 'ethers';
// All methods return properly typed values
const balance: bigint = await sdk.smartToken.balanceOf(address, 0);
```
### Next Steps
* See the API Reference for complete method documentation
# FAQs
## The Product
1. **What is The Risk Protocol (TRP)?**
The Risk Protocol is a risk marketplace that allows you to turn risk itself into a programmable, tradeable token–you can price, tokenize, hedge, and trade different kinds of risks in crypto. The core idea is simple yet powerful: “if risk is abundant in crypto, why not make it tradable?” By turning risk into a tradable asset, TRP enables users to adjust their risk exposure according to their risk appetite, filling a critical infrastructure gap.
2. **What can I actually do with TRP today?**
Initially at launch, you can deposit BTC or ETH and split it into two fully-collateralized SMART Tokens: a low-volatility “RiskOFF” token and a leveraged “RiskON” token. Hold whichever token matches your market view, swap between them as conditions change, or provide liquidity to earn fees. In practice, this allows you to move smoothly between defense (RiskOFF) and alpha-seeking (RiskON), without needing to build complex derivatives trades yourself. The underlying derivatives are abstracted away, allowing you to focus on the payoff that is of interest to you instead of the mechanics of how to implement it.
3. **What are SMART Tokens, RiskON, and RiskOFF?**
Using our proprietary SMART mechanism, we can split an underlying asset into two SMART Tokens with defined risk/return payoffs. These SMART Tokens represent fully collateralized claims on the underlying asset with payoff structures implemented using synthetic derivatives. RiskOFF is designed to reduce drawdowns, sacrificing upside beyond a cap; RiskON is designed to capture more upside. Together, RiskON + RiskOFF always add back up to the value of the underlying asset, as the value is simply redistributed to RiskON and RiskOFF according to the payoff formula. We have designed several types of SMART Tokens; the RiskON/RiskOFF pair is one type, and it is the one we initially launched.
4. **What do you mean by “risk tokenization” and “trading risk”?**
Instead of trading only the underlying coin, we separate its risk into distinct buckets and turn each bucket into an ERC-20/ERC-4626-compatible token. You can then trade these buckets directly: sell downside, buy upside, or sit in a cushioned profile, all by moving between SMART Tokens rather than building your own derivative structures.
5. **How do you create a secondary market for these SMART Tokens?**
For SMART Tokens to be genuinely useful, you need to be able to get in and out of positions at fair prices, which means deep, continuous secondary markets. TRP ships with its own internal DEX, where RiskON, RiskOFF, and the underlying assets trade against each other in dedicated pools, so you do not have to rely on external venues for basic liquidity. We will bootstrap and deepen these pools by aligning incentives for LPs: they earn trading fees from SMART Token flow, and, on top of that, we will direct protocol incentives to the key pairs to make it attractive to park capital there. LPs also benefit from dynamic fees–we scale fees up or down based on underlying volatility. Over time, as usage grows, this internal DEX becomes the natural liquidity hub for the SMART Token ecosystem, with aggregators and other venues routing into it. We might supplement the DEX with market-maker-driven liquidity in the future as well.
6. **Can I create customized SMART Tokens beyond RiskON/RiskOFF?**
At launch, SMART Tokens will be curated by us to concentrate liquidity and to ensure parameters are fully collateralized and easy to understand. Over time, we plan to launch different types of SMART Tokens and, eventually, more customizable paths that allow advanced users to create bespoke payoff designs that still pass our risk and collateral checks.
## How does it work?
7. **How does the basic mechanism work under the hood?**
When you deposit an asset (say, 1 BTC) into TRP, the protocol mints a pair of SMART Tokens: 1 RiskON BTC and 1 RiskOFF BTC, each starting with half the deposit's economic value. Under the hood, the contracts set up a synthetic, fully collateralized costless options collar between these two tokens: RiskOFF is given a downside floor and an upside cap (implemented as a long down and out put plus a short call), and RiskON takes the exact opposite side of that deal, absorbing losses beyond the floor and receiving upside beyond the cap. The two tokens are therefore direct counterparts to each other in an internal “risk swap”, not to any external market-maker. A proprietary risk engine continuously values these embedded payoffs and publishes a Net Token Value for each token. At any time, 1 RiskON + 1 RiskOFF can be redeemed back into 1 unit of the underlying, which keeps their combined value anchored to the underlying asset. At the end of each epoch (or earlier in extreme market crashes), the system rebalances and resets a fresh 50/50 pair for the next period, so the protocol itself never takes directional market risk—only redistributes it between RiskON and RiskOFF holders. For further details on rebalancing, please visit “Rebalances” in protocol documentation.
8. **What are Split, Swap, Redeem, and Liquidity in the dApp?**
“Split” mints RiskON and RiskOFF from your underlying; “Swap” lets you trade between the underlying and any SMART Token or between SMART Tokens themselves via AMM pools; “Redeem” lets you burn a matched set of RiskON and RiskOFF to get back the underlying asset; and “Liquidity” allows you to deposit (or withdraw) into our liquidity pools (for example, RiskON/RiskOFF/BTC or RiskON/RiskOFF/ETH) so that traders have deep markets and you earn fees and incentives.
9. **What are Epochs?**
Epochs are fixed, predefined time intervals during which a protocol applies a consistent set of rules, calculations, and state updates before recalculating for the next interval.
In the context of The Risk Protocol, an epoch is the period over which the risk profile of SMART Tokens is defined and enforced. For example, the cap and floor of RiskON and RiskOFF apply to returns over that specific epoch.
At the end of each epoch:
* The settlement prices of RiskON and RiskOFF are calculated
* The payoff logic embedded in the smart contracts is applied to determine how much of the underlying collateral each holder of RiskON and RiskOFF is entitled to
* New caps and floors for RiskON and RiskOFF are set for the next epoch
* New starting prices for RiskON and RiskOFF are established
* All holders of RiskON and RiskOFF from the expiring epoch are seamlessly rolled into the corresponding tokens for the new epoch (no need for active management)
10. **How does rebalancing work?**
Simultaneously with the end of an Epoch, a new Epoch begins. New RiskON/RiskOFF tokens are created such that the embedded options again form a zero-cost collar at the new Epoch start price. Each trader's USD value of expiring tokens is used to determine their holdings in the new tokens. The token balances are adjusted ("rebased") such that the trader's combined USD NTV in the new tokens equals their expiring USD NTV.
Specific details on the rebalancing mechanism, along with illustrative examples, can be found in the [Rebalance](/protocol-design-and-specifications/smart-tokens/rebalance) section.
11. **Where do the SMART Tokens' returns or yield come from?**
There is no magic external yield. Returns come from how upside and downside in the underlying asset are shared between RiskON and RiskOFF. All SMART Tokens are fully collateralized; we are redistributing risk and return from the underlying asset, not creating yield out of thin air.
12. **Can you walk through one numerical example of an up-only market?**
Let's assume a SMART Token design in which RiskOFF is capped at an 8% upside for the epoch (and, in return, gets downside protection beyond a −5% loss), and any upside beyond that accrues to the benefit of RiskON. Start with 1 BTC at $100,000 and mint 2 SMART Tokens worth $50,000 each: one RiskOFF BTC and one RiskON BTC. If BTC finishes the epoch 30% higher at $130,000, the combined value of RiskON and RiskOFF must still sum to $130,000. We know that RiskOFF is capped at 8% ($54,000). The remainder, $76,000, is the value of RiskON which ends the epoch up 52%. Holding one SMART Token each is equivalent to simply holding BTC and it replicates the 30% move of spot BTC. Tilting more of your position into RiskON gives you a steeper payoff than BTC in a strong up-only environment, while tilting more into RiskOFF lets you stay in BTC but with a smoother, partially capped profile even when the market rips higher.
13. **Can you walk through one numerical example of a sharp drawdown?**
Continuing with the hypothetical example above, let's assume that RiskOFF is designed to be cushioned against a drop below −5% (with losses beyond that borne by RiskON). Again, start with 1 BTC at $100,000, split into $50,000 of RiskOFF BTC and $50,000 of RiskON BTC. Now assume BTC finishes the epoch 30% lower at $70,000. The pair still has to add up to $70,000. RiskOFF is designed to end the epoch down by at most 5%, so it ends the period at $47,500. RiskOFF's share of the downside beyond −5% is borne by RiskON. Since the two tokens are designed to add up to the underlying, RiskON's value at the end of the period is $22,500 ($70,000 − $47,500) or down 55%. Holding one of each SMART Token again replicates the −30% move of spot BTC. A portfolio mostly in RiskOFF experiences a drawdown closer to −5% rather than −30%, while a portfolio that leans into RiskON takes a leveraged hit. In both directions, TRP simply redistributes a fully collateralized BTC stack between a defensive and a leveraged bucket according to the payoff rules.
14. **If I dynamically shifted between RiskON and RiskOFF, would I have outperformed holding just BTC or ETH?**
The answer depends on a) how frequently you shifted between RiskON/RiskOFF (e.g. every week, month or quarter) and b) your success in picking the right token for a particular period. With perfect hindsight and timing, dynamically switching between RiskON and RiskOFF would have massively outperformed passive BTC/ETH in our backtests. For BTC, a scenario where you picked the right token every epoch (30 days, i.e., rotating across RiskON/RiskOFF roughly monthly) would have turned:
* A 28% loss in BTC into a 15% gain for the dynamic strategy over the last 1 year (1.6X spot wealth)
* A 132% increase in BTC into a 1,921% increase for the dynamic strategy over the last 3 years (8.7X spot wealth)
* A 13% increase in BTC into a 17,222% increase for the dynamic strategy over the last 5 years (153X spot wealth)
For ETH, the same exercise turns:
* A 20% increase in ETH into a 309% increase for the dynamic strategy over the last 1 year (3.4X spot wealth)
* A 14% increase in ETH into a 2,121% increase for the dynamic strategy over the last 3 years (19.5X spot wealth)
* A 19% loss in ETH into a 38,440% gain for the dynamic strategy over the last 5 years (479X spot wealth)
Now, of course no one will trade perfectly in reality, but the sheer magnitude of the outperformance possible by rotating into the right token for a particular period indicates the alpha potential of such a dynamic strategy, even for lower levels of token selection accuracy.
15. **Can a token go to zero or even negative?**
A SMART Token’s payoff cannot go negative. Each RiskON/RiskOFF token is a fully collateralized claim on the underlying, so its on-chain payoff has a floor at zero—you can lose your stake, but you never owe more than what you put in. In extreme crashes, the RiskON token is intentionally the shock absorber. It can be written down to near-zero (for example, for a token design with a -5% strike on the put, in a \~52.5% intra-epoch crash, RiskON may be taken to pennies so that RiskOFF’s put protection is made whole), but it still does not go negative.
## Utility and Benefits
16. **Why should I care about SMART Tokens as a BTC/ETH holder?**
Because SMART Tokens let you turn a blunt spot position into two precise tools instead of one all-or-nothing bet. With RiskOFF BTC/ETH, you can park most of your stack in a cushioned profile that is designed to soften big drawdowns while still keeping meaningful upside, so your core holdings ride the cycle without getting smashed by every 30–40% dip. With RiskON BTC/ETH, you can concentrate risk and upside into a smaller slice of your capital, effectively “leveraging your conviction” without managing margin, liquidations, or options rolls. Together, they let you stay in BTC/ETH the whole time, but decide how much of your exposure lives in a defensive bucket and how much lives in a high-octane, upside-heavy bucket as market conditions and your views change. RiskON & RiskOFF are designed to be used tactically as your risk mode shifts between RiskON and RiskOFF. In fact, dynamically shifting between RiskON & RiskOFF can dramatically boost your returns vs just holding the underlying BTC or ETH.
17. **How do SMART Tokens help me reduce drawdowns?**
Imagine BTC starts an epoch at $100,000 and you deposit 1 BTC to mint 2 SMART Tokens, each worth $50,000: RiskOFF and RiskON. You then sell your RiskON so that you are holding only RiskOFF. Suppose now BTC falls 40% to $60,000. In an illustrative design where RiskOFF is cushioned beyond a 5% loss, RiskOFF will end the epoch at $47,500 (−5%), while RiskON takes the remaining pain and ends around $12,500 (−75%); together, they still add to $60,000. If you had held spot BTC, you would be down 40%; by holding RiskOFF, you have obtained downside protection by shifting most of the downside to RiskON instead.
18. **How do SMART Tokens help me take a high-conviction bullish view?**
Using the same starting point—1 BTC at $100,000 split into $50,000 RiskOFF and $50,000 RiskON—suppose BTC rallies 50% to $150,000. In an illustrative design where upside above +8% is redirected to RiskON, RiskOFF will end at $54,000 (+8%) while RiskON will end at $96,000 (+92%). Again, the two add to $150,000, but most of the upside has been transferred to RiskON. If you are bullish, you can swap your RiskOFF or BTC for RiskON in order to tilt your portfolio towards that leveraged upside.
19. **What’s the utility of TRP from the perspective of a lending platform?**
Lenders want collateral that is stable, predictable, and unlikely to blow up during market stress.\
TRP’s RiskOFF tokens give them exactly that:
* Lower volatility than BTC/ETH
* Fully collateralized, on-chain, transparent payoff structure
* No hidden leverage or oracle dependencies
* Reduced risk of cascading liquidations
The net benefit is that lending platforms can safely raise LTVs or reduce liquidation thresholds, which leads to higher utilization, more borrowers, and more fees. Fewer liquidation failures = safer lending markets = higher TVL without more risk.
This makes RiskOFF a fundamentally superior version of collateral for lending protocols.
20. **How would a DAO or treasury use TRP in practice?**
Take a DAO with 100 BTC in its treasury. Instead of holding raw BTC, it could allocate the entire stack into RiskOFF BTC, parking its core reserves in a cushioned profile that softens large drawdowns while still keeping some upside. The complementary RiskON leg is effectively sold to market participants seeking leveraged upside, so the DAO ends up holding only RiskOFF BTC in its treasury. This way, if macro turns ugly, the treasury is equipped to ride out the BTC volatility, without needing to negotiate bespoke structured notes or maintain an active derivatives book.
21. **How is this better than just moving into stablecoins or trading perps/options?**
Moving everything into stablecoins kills your upside and forces you to time re-entry. Perps provide leverage, but users’ funds are subject to margin calls and automatic liquidations. Perps also give you linear exposure—gains and losses increase in a straight line as prices move—so you can scale risk up or down, but you cannot change how the position behaves in different market conditions.
Options allow more flexible, non-linear payoffs but require active management, rolling, margin, and expertise, and are subject to counterparty risk. TRP bakes these sophisticated, non-linear risk profiles directly into simple, fully collateralized, non-custodial, tradeable payoffs: instead of managing a derivatives book, you select the SMART Token that matches your risk view and hold it.
## Who is it for?
22. **Who is the target user for RiskON/RiskOFF?**
RiskON/RiskOFF is built for a broad range of users: crypto-native traders and alpha hunters who want clean, on-chain ways to flip between risk-on and risk-off for maximal gains; longer-term BTC/ETH holders who wish to stay in their preferred asset but hate big drawdowns; lending platforms looking for lower-risk, more efficient collateral; DAOs and on-chain treasuries that need systematic, rule-based risk buckets instead of all-or-nothing exposure; and institutions—such as funds, market makers, and family offices—seeking fully collateralized, transparent payoffs they can plug into portfolios, products, or treasury stacks without building the derivatives machinery themselves.
23. **Do I need expertise in derivatives to use TRP?**
No. TRP abstracts away the options and structured-product complexity under the hood, and showcases only simplified SMART Tokens on the surface. You never have to pick strikes, expiries, margin, or worry about Greeks—you just choose between clearly illustrated payoff profiles, then split, swap, provide liquidity, or redeem. If you can think in terms of “more cushioned BTC/ETH” versus “more aggressive BTC/ETH”, you already have the right mental model; the derivatives machinery and risk engine simply ensure those profiles stay fully collateralized and behave as advertised.
24. **Is TRP suitable only for short-term traders or also for long-term holders?**
It works for both. Traders can actively rotate between RiskON and RiskOFF within and across epochs. At the same time, long-term holders can maintain a preferred profile (for example, RiskOFF BTC or ETH) across multiple epochs to smooth the ride without leaving their BTC or ETH holdings. It should be noted that while RiskOFF is a suitable long-term investment, RiskON is better held for shorter periods while switching between risk regimes.
## Differentiators
25. **Is this the same as Pendle or yield tokenization protocols?**
No–Pendle tokenizes yield. The Risk Protocol tokenizes risk. Pendle and similar protocols split a yield-bearing position into a principal token and a yield token, so you are mainly trading interest-rate exposure and maximizing APY. The underlying asset must produce a yield for Pendle to work.
TRP, on the other hand, splits market risk itself—primarily price volatility—into two tradable buckets or “risk flavors”:
* *RiskOFF*: dampened volatility, drawdown protection, low-risk exposure
* *RiskON*: leveraged volatility exposure, convex upside during high-vol markets
TRP does not need the underlying token to be yield-producing.
26. **How are TRP’s SMART Tokens different from other derivative instruments?**
TRP offers a new primitive, not another derivative instrument: With a derivative, you bet on an asset. With TRP, you hold a transformed version of the asset itself. A primitive behaves like a simple asset you own, not a contract you must maintain and monitor. It can be:
* Sent
* Traded
* Used as collateral
* Composed into other protocols
* LP’d or staked in DeFi
Most options and perp platforms (Deribits, GMX, Hyperliquid, Synthetix, etc.), on the other hand, expose positions that are:
* Account-based, not tokenized
* Dependent on margin and liquidation engines
* Non-transferable
* Not ERC-20 assets
27. **How are TRP’s SMART Tokens different from perps?**
*Unique Risk Profile*: Perps give you linear leverage with funding-rate risk and liquidations. TRP’s SMART Tokens, on the other hand, provide non-linear exposure and the ability to “bend” the underlying risk/return profile. There are no liquidations, no funding-rate payments, and no margin management. You’re holding a fully collateralized payoff that automatically adjusts to market volatility. Instead of managing leverage, you select a risk flavor (RiskON or RiskOFF) and hold it like any other token.
*Portability*: Because perp positions live inside the protocol’s accounting system, they cannot be moved, cannot be used as collateral elsewhere, and cannot be LP’d or staked like a simple token. Perps aren’t composable across DeFi, and in most cases, they carry all the risks inherent in off-chain, centralized liquidity venues.
*Costs: Perpetuals also incur ongoing funding rate costs, and these rates can significantly eat into your returns—we are talking high single-digit to low double-digit annualized percentages in many cases.* Our SMART Tokens are structured as what's called a "costless collar" under the hood. What that means is that neither one of them pays any premium to the other - the cost is zero. Essentially, RiskOFF is given downside protection (a synthetic put) and gives up upside beyond a cap (a synthetic short call), while RiskON takes the opposite side of that trade. There's no continuous funding bleed—it's a one-time split where RiskON and RiskOFF are direct counterparties to each other in an internal risk swap, not paying rolling interest to maintain their positions.
*Trading Vol*: One can’t really use perps to trade volatility. Perps are linear payoffs and directional—you have to choose direction. You can get high leverage, but you have to bet direction, and you get liquidated if you guess wrong. Our tokens, on the other hand, allow you to trade volatility irrespective of direction—if you are long vol, as long as crypto swings up or down, your position makes a profit. In fact, long vol/short vol is a specific type of SMART Token that we will be offering post-launch.
*Designed for both traders and non-traders*: Finally, TRP products don’t require a derivatives background. They behave like simple tokens you can hold in a wallet, LP into, use as collateral, or integrate into other DeFi protocols’ structured strategies—without ever touching an options chain or perp exchange.
28. **How are TRP’s SMART Tokens different from options?**
Options are powerful but complex—implied vols, Greeks, expiries, strikes, premium decay, etc. TRP abstracts away all of that. No constructing various option legs, no rolling positions. You simply choose the level of risk you want, and the protocol handles the mechanics behind the scenes. As a result, SMART Tokens democratize access and expand the market of derivative users in crypto.
29. **How are SMART Tokens different from leveraged tokens?**
Leveraged tokens are good for daily bets but suffer from volatility decay if held for longer periods. Whereas leveraged tokens suffer from volatility, our Smart Tokens are actually built around volatility. Plus, we can create smart tokens over any duration–1 week, 1 month, 1 quarter, etc.
30. **What do you mean when you say crypto lacks risk infrastructure, and what space does TRP occupy?**
Traditional markets have a rich ecosystem of risk products: volatility futures & options, volatility ETNs and ETFs, volatility indices, defined-outcome ETFs, tail-risk hedging, risk-parity strategies, structured products, hedging overlays, etc. Crypto mostly offers spot and perps, with only pockets of structured risk solutions. TRP is building a native on-chain risk layer: programmable ways to isolate, measure, transfer, and warehouse risk that can plug into wallets, treasuries, protocols, and exchanges as a core primitive.
## Safety & Risks
31. **Who is building TRP?**
We are a small team that blends deep crypto-native experience with decades of institutional finance expertise. Our team members bring highly specialized backgrounds in DeFi and CeFi protocol design, GTM strategy, quantitative trading, risk management, derivatives structuring and valuation, and volatility modeling and research.
Unlike the $18T+ risk market in traditional finance, the team understands there is a significant market gap in decentralized finance and is therefore committed to developing an on-chain risk market in crypto. Learn more under “Our Story” here:
We are supported by senior advisers across risk, trading, engineering, and protocol design & architecture, and we intend to progressively hand more control to the community as governance and the product set mature.
32. **How do the smart contracts, upgrades, and multisig work? Are my funds safe?**
The Risk Protocol is implemented entirely through on-chain smart contracts that enforce predefined, transparent rules. These contracts control how collateral is locked, how SMART Tokens are minted and redeemed, how rebalancing occurs, and how liquidity pools function.
At launch, some core contracts will remain upgradeable for a limited period. This is intentional: TRP is introducing new primitives for on-chain risk transfer, and upgradeability allows us to fix bugs, address edge cases, or refine parameters if something does not behave as intended under real market conditions.
Upgrades and other sensitive protocol actions are governed by a multisig composed of core TRP contributors and independent third parties with aligned incentives. This structure prevents unilateral control by any single actor, including the TRP team itself.
Once the system has been sufficiently battle-tested and we are confident in its long-term behavior, the protocol is designed to transition toward immutable contracts and increasingly on-chain governance, reducing trust assumptions over time.
At all times, user funds remain governed by smart-contract rules rather than human discretion.
33. **Who actually holds my BTC/ETH when I deposit collateral?**
No one takes custody of your funds.
When you deposit BTC or ETH into The Risk Protocol, your assets are locked into on-chain smart contracts. These contracts enforce the rules for minting, trading, rebalancing, and redeeming SMART Tokens. Neither TRP nor any third party can arbitrarily move, freeze, or access your assets.
Your wallet receives SMART Tokens that represent your fully collateralized, on-chain claim on the underlying collateral. Redemption is available anytime and always governed by transparent protocol logic.
34. **What are the main smart contracts involved, and who controls them?**
*Vault*: The Vault is responsible for locking and unlocking collateral. When you deposit, e.g., BTC or ETH, ownership of the underlying asset is transferred to the Vault contract in accordance with fixed rules. No funds are held in discretionary custody. When the required SMART Tokens are redeemed, the Vault releases the corresponding collateral back to the user.
*RiskON*: The RiskON contract is an ERC-20/ERC-4626 compatible token contract that tracks ownership of RiskON SMART Tokens. It is open-source and rule-based, and it does not grant special privileges to TRP or any other party.
*RiskOFF*: The RiskOFF contract mirrors RiskON in structure and permissions. It is also ERC-20/ERC-4626-compatible, open-source, and governed entirely by its code.
TRP authors the code but does not have discretionary control over these contracts. All interactions—including those by TRP—are subject to the same rules as any other user.
35. **Is my collateral rehypothecated, lent out, or used elsewhere?**
No. Your collateral is not rehypothecated or lent out. To increase utility for users and facilitate arbitrage, the protocol may allow atomic flashloans of SMART Tokens that must be repaid in the same transaction; otherwise, the transaction fails. These flashloans do not introduce counterparty risk and do not affect users’ ability to redeem their assets at any time. See the “[Trading Bots](/protocol-design-and-specifications/trading-bots)” section in the protocol documentation for more details.
36. **What risks still exist even if you don’t have custody of funds?**
Removing custody eliminates a major class of risk, but some risks remain in theory, including:
* *Smart contract risk*: Bugs or vulnerabilities could lead to unintended behavior or exploitation by hackers, even after rigorous audits.
* *Market risk*: RiskON and RiskOFF deliberately redistribute market risk. Choosing the wrong exposure for a given market regime can result in losses.
* *Liquidity risk*: Under extreme conditions, secondary-market liquidity may be thinner, increasing slippage.
These risks are transparent, on-chain, and opt-in.
## New to DeFi? Start here
37. **Who am I actually trusting when I use this protocol?**
You are not trusting a company, broker, or intermediary. You are interacting directly with on-chain, fully open-sourced smart contracts that operate according to predefined, transparent rules.
Once deployed, these contracts execute automatically and cannot make discretionary decisions. The protocol does not take custody of funds, approve transactions, or intervene in user positions.
38. **Do I still own my assets after I use the platform?**
Yes. You retain full economic ownership of your assets at all times.
When you deposit collateral, it is locked into a smart contract and represented by on-chain tokens that belong to your wallet. The protocol cannot access, move, or reuse your assets outside of the rules you explicitly agree to.
39. **Can the platform freeze, block, or reverse my transactions?**
No. The Risk Protocol is permissionless. It cannot freeze accounts, block users, or reverse transactions. Once a transaction is confirmed on-chain, it is final and enforced by the blockchain itself.
40. **If something goes wrong, who is responsible?**
Unlike centralized platforms, decentralized finance (“DeFi”) protocols do not provide guarantees, refunds, or discretionary intervention. This is the norm and best practice in DeFi.
Users are responsible for understanding how the protocol works and the risks they choose to take. These risks—such as smart-contract risk or market risk—are transparent, predefined, and opt-in, rather than hidden or discretionary.
41. **Why would someone choose this over a centralized platform?**
DeFi offers transparency, predictability, and user control. There is no custody of user assets, no hidden leverage, no off-balance-sheet activity, and no discretionary decision-making. All rules are visible on-chain and apply equally to all users.
For many users, this trade-off—more control and transparency in exchange for greater personal responsibility—is the core value of DeFi.
# Points Program
Real Usage. Real Rewards.
The Points Program is how The Risk Protocol rewards the people who make it work and grow—traders, liquidity providers, referrers, and community contributors who choose to build the protocol alongside us.
Most crypto points programs reward mercenary farming and vanity metrics. RISK Points reward genuine contribution. They accrue across four categories: real protocol usage, referrals that bring in actual users, skill in our monthly Trading Competition, and discretionary recognition for education, feedback, and community building.
The three pages below cover the program in detail:
**Points Principles**—the design philosophy and how points are earned across all four categories.
{% content-ref url="/pages/xkBMJYPsGp6T0S7BoN8E" %}
[Points Principles](/resources/points-program/points-principles)
{% endcontent-ref %}
**Referral Rewards**—rebates for bringing in users who actually trade. People you refer get rewarded too.
{% content-ref url="/pages/00m6gh0Yf5a6N9gxr2JT" %}
[Referral Rewards](/resources/points-program/referral-rewards)
{% endcontent-ref %}
**Trading Competition**—monthly rounds, scoring methodology, and the path to the Risk Championship.
{% content-ref url="/pages/KbhnwaM5H7Z3DCrCE3tI" %}
[Trading Competition](/resources/points-program/trading-competition)
{% endcontent-ref %}
# Points Principles
While many crypto points programs devolve into short-term, extractive farming games, we are returning to first principles to align users with the protocol's long-term health. The program is guided by a transparent set of core principles.
#### Guiding Design Principles
* Reward real, productive protocol usage that strengthens long-term health.
* Reward sustained participation rather than one-off actions.
* Incentivize genuine contribution and disincentivize short-term speculation or system gaming.
* Protect real users by safeguarding against sybil attacks and whale domination.
* Favor early contributors, as early participation holds greater value.
* Treat points as earned reflections of contribution, not entitlements.
#### How Points Are Earned
Points accrue across four primary categories:
**Actual Protocol Usage**
Points are driven by net productive capital, calculated as (Splits - Redeems) + Swaps + (Liquidity Provided - Liquidity Withdrawn). Long-term, net committed capital matters more than short-term flows. Greater weight is placed on net splitting activity and net liquidity provision.
**Referrals**
Rewards are based on real economic contribution, measured by the revenue generated by referred users. Vanity metrics and superficial activity are not rewarded.
**Trading Competition**
This serves as an educational mechanism to help users understand the utility of SMART Tokens in a hands-on environment. It is designed to be interactive, accelerate protocol adoption, and put RiskFi on the DeFi map.
**Discretionary**
Contributions that strengthen the ecosystem in other ways, including user education and feedback, constructive participation, and community building.
***
*The Risk Protocol reserves the right to modify the points program as needed to ensure it remains aligned with these principles and continues to protect genuine contributors.*
# Referral Rewards
Grow the Community. Share in the Value.
The Risk Protocol's Referral Rewards program rewards you for referring users who actually trade and generate protocol revenue. No empty sign-ups. No fake wallets. If your referral produces real revenue for the protocol, both of you earn.
#### How It Works
Generate your referral link during testnet or mainnet. Share it with anyone. When someone joins through your link and makes their first trade, the referral relationship locks in. From that point, every trade your referral makes on mainnet generates rewards for both of you—for a full 12 months.
As a **Referee** (the person who joins), you receive a rebate equivalent to 15% of the protocol fees you generate. Your referrer doesn't eat into your rewards—this 15% is exclusively yours.
As a **Referrer**, you earn a rebate equivalent to 25% of the protocol fees your referral generates, calculated on the net fee after the referee's 15% rebate. Make 30 or more qualified referrals within any rolling 30-day period, and you unlock **Affiliate** status—which boosts your rate to 40%. Once earned, Affiliate status is yours permanently.
These rebates for Referrer and Referee are ultimately converted into RISK points. Individual caps might apply, if needed, to ensure that rewards are distributed fairly and widely across the community.
#### What Counts as a Valid Referral
Your referral must make their first mainnet trade within 30 days and reach a cumulative volume of at least $100 during that period. For referrals that are made during the testnet phase, the 30-day period is measured from the mainnet launch. Until both conditions are met, no rewards accrue to either party. This ensures the program rewards genuine onboarding rather than link spam. If either condition is not met within the 30-day window, the referral relationship is permanently invalidated.
#### Your Referral Dashboard
Track everything in real time: how many referrals you've made, which ones have qualified, the volume they're generating, your accumulated rebates, and your current tier status.
# Trading Competition
Prove Your Edge. Climb the Leaderboard.
The Risk Protocol's Trading Competition is a series of monthly rounds designed to identify and reward the most skilled SMART Token traders. This isn't about who has the deepest pockets—it's about who trades the smartest.
Each round runs for one month. At the end of every round, the top 100 traders become eligible for RISK Points based on their ranking. Points from every round you compete in accumulate toward the **Risk Championship**—a season-long standings of the protocol's most consistent performers.
#### How You're Ranked
Your ranking is determined by two factors: your investment performance and how well you managed your risk. Over each round, we measure your returns ("P\&L Percentage") and your maximum drawdown ("Max Drawdown" or "MDD")—the deepest dip your portfolio took from its peak. For each measure, you are scored against every other eligible participant in the round to determine your percentile rank (the "P\&L Score" and the "Risk Awareness Score", respectively). These scores combine to form a single Final Score. In determining the Final Score, P\&L Score carries a 60% weight, and Risk Awareness carries a 40% weight. The highest Final Score wins. A trader who earned 30% returns but suffered a 25% drawdown might be ranked lower than a trader who earned 20% returns with only a 5% drawdown.
#### [Two Leaderboards](https://app.riskprotocol.io/dashboard), Two Ways to Win
The **Trading Competition Leaderboard** shows a running tally of the top 100 traders, including their returns, drawdowns, and Final Score. Only the top 100 earn RISK Points for that round—but your position within the top 100 determines how much you earn. Rank 1 earns the most. Rank 100 earns the least.
The **Risk Championship Leaderboard** tracks cumulative performance across all competition rounds. Only the top 10 are displayed. Making the Championship requires sustained excellence—one great month won't be enough. The traders who show up round after round, managing risk while generating returns, are the ones who rise to the top. The traders who are on the Risk Championship leaderboard at the end of the points program earn additional RISK Points on top of their monthly haul.
#### Eligibility
To be eligible for any round, you must achieve a minimum net trading volume of $10,000 on testnet and $1,000 on mainnet and be trading on at least 3 separate days during that round. This ensures the leaderboard reflects genuine traders, not bots or one-trade wonders.
The competition is based exclusively on SMART Token performance. As new SMART Tokens launch beyond RiskON/RiskOFF, they'll be added to the eligible asset list.
# General Risk Disclosures
*Coming soon....*
# Privacy Policy
*Coming soon....*
# Terms of Service
*Coming soon....*