Request a Piggy
Last updated
Last updated
TODO: Draw comparison to tradfi over-the-counter markets?
Requesting a piggy signals interest in an underlying with specific execution parameters. Where creating a piggy may frequently be done by liquidity providers (i.e. those who want to make the premia by collateralizing piggies), requesting a piggy is done by those looking for protection or speculation on something not widely available, or currently unavailable. This could take the for form of a particular constraint, for example, a very long dated piggy, or a unique or very specific underlying, that is not offered, as in input costs for a business. As long as there is a reputable way to access the price of the underlying, a piggy can be requested.
The process for requesting a piggy, request-for-piggy or RFP, is similar to the steps for creating a piggy, with the difference being the collateral and premium. With an RFP, collateral is not deposited into the piggy, this is done when someone fulfills the request. However, upon successful creation of a request, the user will want to put the RFP up for auction so someone else can fulfill it. When an RFP goes up for auction, a premium is sent along with the auction, this is the compensation someone will receive when they fulfill the RFP.
To request a piggy click on the New Piggy button on the menu:
This will open a model offering the choice to Create or Request a Piggy. Choose Request.
Selecting Request will navigate to a form in which each parameter can be specified.
Click on the drop down menu to choose an underlying. SmartPiggies maintains a set of curated underlyings on the platform. In this example, the Ethereum price in dollars serves as the underlying for the RFP. The underlying selection will also detail the oracle providing the price upon settlement. In this example SmartPiggies will provide the price, as denoted by SP. There are other oracle services to choose from, some on-chain, some off-chain. See the Oracles section for more details.
Next, select the type of collateral that will this RFP will require to be deposited when it is fulfilled.
Click the drop down menu and select a listed collateral. SmartPiggies also maintains a curated set of collateral ERC20 tokens available to be deposited. The collateral choices available on the platform conform to the ERC20 standard, and have been tested. If you would like to choose from a collateral token not listed, contact the team to see if it is possible to add. The SmartPiggies smart contract can also be interacted with directly to supply any parameters not available on the platform at a specific time. The contract is public and permissionless.
For this piggy, the Truffle Stable Token is chosen.
For an RFP, the requester does not deposit any collateral, so an approval is not needed. When the RFP is auctioned, so as to make it available to be fulfilled by a counterparty, an approval would be needed, as the premium is denominated in the collateral type. This is explained in more detail under the Lifecycle of a Piggy section under Auction, but briefly which ever collateral has been selected for a request, is also the token used for premium on the auction.
Following the collateral, the next set of execution parameters can be selected.
Select a Strike Price for the RFP. This will determine the direction of the RFP. If the strike price is above the spot price of the underlying, the RFP will execute as a CALL option. If the strike price is set below the spot price, the RFP will execute as a PUT option. The current example will be a PUT, as the date it is being created the spot price of ETH/USD is $2000. As the piggy will be in-the-money when the price descends below $1500, this RFP when it becomes a piggy will execute as a classic PUT option would.
The Max Loss is the total amount of collateral that will be deposited into the piggy when it is fulfilled.
Next choose the Lot Size and Expiration.
Lot Size is the multiplier for the RFP. This represents the contracts covered by the RFP, and during settlement will factor into the payout. In the current example, the RFP, when it becomes a piggy, will execute as a PUT option, with a strike at $1500. The Max Loss is $1000, this is the total amount of payout available to holder of this RFP, the requester in this case. Assuming the RFP becomes a piggy, if the price of Ethereum went to $1000, and the holder settles the piggy, the payout would be ((Strike - Spot) * Lot Size) and in our example equate to $500 ((1500-1000) * 1). If the Lot Size had been 2, the payout would have been $1000. Note that this is the Max Loss of the piggy. The holder gets the full collateral deposited into the piggy and the write receives no difference.
If the Lot Size had been 4, the Max Loss is reached much faster. When the Lot Size is 4 the collateral is depleted when the Ethereum price hits $1250 ((1500 - 1250) * 4). This means the holder could have executed the piggy at $1250 for a payout of the Max Loss, or could have still executed at $1000, but the payout would be the same. The maximum payout of the piggy is $1000.
You can see this in the Max Loss price tag:
The piggy is only valid for a certain duration of time. There is no limit to this time frame, only that it needs to be in the future. The expiration is represented as a Unix Timestamp. Click on the Contact Expiration Date field to set a date. This prompts with a calendar for easy selection.
A piggy does have second resolution, but keep in mind that the timestamp is extracted from the block, so there will be small gaps between the time a piggy may expire in seconds, and the block representing the passage of that time. See the Expiry section in Creating your first Piggy for more information.
The RFP isn't going to do any good if it doesn't get fulfilled. To get it fulfiller it needs to be placed on auction so that someone else can put in the collateral, and make this request a "real" piggy.
To auction the RFP select the start price, reserve price, and auction expiration date:
Note that for RFP auctions, the Start Price is less than the Reserve Price, because RFP auctions are conducted as a reverse dutch auction. Hence, the price begins low and increases over time, until the price reaches the reserve. At this point the RFP is ready to send to the network. However, in this example, the protection will be demonstrated.
You can protect the piggy from price movements during the auction by setting a Protection Limit. This will make the RFP un-fillable if the price gets too close or exceeds the Strike Price during an auction. Select the toggle next to the Create & Auction button to activate the fields.
This will drop down the Protection Limit parameter. The protection limit can be adjusted to protect the premium of the requester if the price of the underlying moves in such a way that would render the RFP un-usable. For example, in the above, if the price of Ethereum reaches $1761 from the $2000 spot price, the RFP can be purchased. As long as the price is above $1761 this RFP is not purchasable. This protects the premium the requestor is willing to pay for the RFP, in the event that the price moves significantly upwards. For instance, a requestor may not offer to pay as much for a PUT RFP with a strike price of $1500, if the price of Ethereum is $20,000, as the likelihood that the price moves from $20,000 to $1500 is low. The requestor, however, may be willing to pay a lot for the same PUT RFP if the price of Ethereum is currently $2000. The protection limit on an RFP becomes a trigger of when that RFP is available to be fulfilled, while protecting the requestor's interest in the RFP.
Click the Create & Auction button to launch the wallet connected to the site, and confirm the transaction to complete the request!
