Trading & Borrowing

Overview
Trading (taking a position) involves first borrowing from an iToken. There are two ways to borrow using Fulcrum and open a position:
1.
pToken contracts are tokenized versions of leveraged long or short positions on an asset. pTokens are minted by sending ETH or another asset into the pToken contract, which in turn borrows from an iToken lending pool, does a Kyber swap, and sends the user back an equivalent amount of pToken (ERC20) at the current pToken price. For short positions, such as 2x short ETH, the pToken borrows from the iETH token, then swaps that ETH for a stable asset (DAI) on KyberSwap. For long positions, such as 2x long ETH, the pToken borrows from a stable asset, iDAI, and swaps that for ETH on KyberSwap. The tokens are perpetual, but positions are not. If a position loses too much value, or reaches the end of the loan term (28 days), it will be liquidated and a new position will be opened behind the scenes. Traders should be aware of the liquidation price of the pToken, and burn their pTokens prior to being liquidated, to avoid locking in any losses.
2.
A trader can borrow directly from an iToken and manage their loan or margin trade themselves using the bZx protocol. The protocol supports margin loans that are under-collateralized or over-collatateralized. Over-collateralized loans, with 150% collateral or more, allow the user to withdraw the loan principal to an external wallet or contract.
State-Changing Functions
mintWithToken(address,address,uint256,uint256)
1
function mintWithToken(
2
    address receiver,
3
    address depositTokenAddress,
4
    uint256 depositAmount,
5
    uint256 maxPriceAllowed)
6
    external
7
    returns (uint256);
Copied!
Called to deposit assets to the pToken, which in turn mints pTokens to the lender’s wallet at the current tokenPrice() rate. The receiver parameter specifies the address that will receive the minted pTokens. Any supported KyberToken can be specified (depositTokenAddress) to mint pTokens, however, specifying a token other the asset returned by the loanTokenAddress() function will trigger a KyberSwap into the correct asset, being subject to any trade slippage that may occur. A prior ERC20 “approve” transaction should have been sent to the depositTokenAddress contract for an amount greater than or equal to depositAmount. A limit of slippage can be set by specifying "maxPriceAllowed". This should be set to a value above the current price returned by "tokenPrice()". A value of 0 is ignored.
mintWithEther(address,uint256)
1
function mintWithEther(
2
    address receiver,
3
    uint256 maxPriceAllowed)
4
    external
5
    payable
6
    returns (uint256);
Copied!
This accepts ETH sent directly to the pToken contract for minting pTokens. Mint actions for pTokens with "loanTokenAddress()" assets other than WETH, will trigger a KyberSwap into the correct asset, as with the above. A limit of slippage can be set by specifying "maxPriceAllowed". This should be set to a value above the current price returned by "tokenPrice()". A value of 0 is ignored.
burnToToken(address,address,uint256,uint256)
1
function burnToToken(
2
    address receiver,
3
    address burnTokenAddress,
4
    uint256 burnAmount,
5
    uint256 minPriceAllowed)
6
    external
7
    returns (uint256);
Copied!
Called to redeem owned pTokens for an equivalent amount of the underlying asset based on remaining collateral, unpaid interest, and including any profits or losses on the position, at the current tokenPrice() rate. The receiver parameter specifies the address that will receive the asset proceeds. A limit of slippage can be set by specifying "minPriceAllowed". This should be set to a value below the current price returned by "tokenPrice()". A value of 0 is ignored.
burnToEther(address,uint256,uint256)
1
function burnToEther(
2
    address payable receiver,
3
    uint256 burnAmount,
4
    uint256 minPriceAllowed)
5
    external
6
    returns (uint256);
Copied!
Called to redeem owned pTokens similar to the above, but for an equivalent amount of ETH. A limit of slippage can be set by specifying "minPriceAllowed". This should be set to a value below the current price returned by "tokenPrice()". A value of 0 is ignored.
Read-Only Functions
tokenPrice()
1
function tokenPrice()
2
   public
3
   view
4
   returns (uint256 price);
Copied!
Returns the current price of the pToken. Example 1000000000000000000000 = 1,000 ETH per pToken.
liquidationPrice()
1
function liquidationPrice()
2
   public
3
   view
4
   returns (uint256 price);
Copied!
Returns price at which the underlying position should be liquidated by the bZx protocol, or 0 if no position is open.
checkpointPrice(address)
1
function checkpointPrice(
2
    address _user)
3
    public
4
    view
5
    returns (uint256 price);
Copied!
Returns the token price recorded during the last checkpoint for the user. Checkpoints occur whenever there is a token balance changing action taken by the user (minting, burning, or transferring). A user profit since last checkpoint would be calculated like so: (tokenPrice()-checkpointPrice(user)) * balanceOf(user) / 10^36
currentLeverage()
1
function currentLeverage()
2
    public
3
    view
4
    returns (uint256 leverage);
Copied!
Returns the current leverage backing the underlying loan based on remaining collateral. Example 2000000000000000000 = 2x leverage.
marketLiquidityForAsset()
1
function marketLiquidityForAsset()
2
    public
3
    view
4
    returns (uint256);
Copied!
Returns the maximum amount of "loanTokenAddress()" token that can be deposited to mint pTokens at the current time. This is based on borrow liquidity of the related iToken.
marketLiquidityForToken()
1
function marketLiquidityForToken()
2
    public
3
    view
4
    returns (uint256);
Copied!
Returns the maximum amount of pToken that can be minted at the current time. This is based on borrow liquidity of the related iToken, as well as the current pToken price (tokenPrice()).
assetBalanceOf(address)
1
function assetBalanceOf(
2
    address _owner)
3
    public
4
    view
5
    returns (uint256);
Copied!
Returns the user’s balance of the underlying asset. This is the same as multiplying the user’s token balance by the token price.