Creating your first Piggy
Creating vs Requesting
Piggies can be created or requested. Creating a piggy is done by someone providing liquidity, insurance, or otherwise adding inventory, which culminates in putting collateral into a piggy. These created piggies are purchased by those looking to protect their assets or speculatively bet on the future price movements. On the opposite side, someone can request a piggy from a liquidity provider or anyone willing to put collateral into a piggy. When someone puts collateral into a piggy they receive the auction premium offered as a bounty for fulfilling the request.
Creating a piggy
Creating a non-fungible smart piggy involves knowing all the requisite parameters needed, filling in these parameters and formatting them into a data object to be included in an Ethereum transaction. This transaction is sent to the network, and if there are no errors with the transaction, a piggy is made.
Creating a piggy requires the following parameters:
Collateral Contract Address
Oracle Contract Address
Arbiter Address
Collateral Amount
Lot Size
Strike Price
Expiry
Execution Style
Direction
Request Field
The creator of a piggy is referred to as the writer or creator. The purchaser of a piggy is referred to as the holder or owner of the piggy. The creator determines the terms of the piggy, all attributes above, and supplies the collateral for the piggy. The holder purchases the piggy on the market, pays a premium to the writer, and owns the piggy. A holder can transfer the piggy to another account address, split the piggy if it becomes valuable, or re-auction the piggy and sell it to someone else. If the piggy executes as an American style, the holder can request a settlement price at any time, to begin the settlement process and claim a payout. If the piggy executes as a European style, anyone can request a settlement price after it has matured.
A holder is the party that requests a piggy. If a participant requests a piggy, the piggy is in a "virtual" state, it isn't a real piggy yet. The request is parameterized, but has no collateral inside. The holder is broadcasting interest that she is willing to pay someone else to create this piggy and pay a premium to do so. The holder of a request can then auction the request-for-piggy (RFP), associating the RFP with a premium, and whomever fulfills that request, by putting collateral inside that RFP, will gain the premium. This RFP moves from a request to a real piggy, and is now identical to a piggy created in the process detailed in the previous paragraph. An RFP initially has a holder, but no writer. Once the RFP is filled, the fulfiller becomes the writer, and the holder remains unchanged.
Collateral Contract Address
Oracle Contract Address
Every piggy has an oracle contract address associated with it. This is the contract that gets called when the holder requests a settlement price for the piggy and also if the seller protection feature has been enabled. When requesting a settlement price, the SmartPiggies contract will call the oracle contract address, and ask for a price. The oracle contract will reply with a price, and this price is used to calculate the payout of the piggy or in the case for seller protection, determine whether the sale is allowed.
Arbiter Address
This field is used for arbitration and is optional. If either counterparty feels the intention of of agreement has been violated, an arbitration process can be engaged. The arbiter address is the account of a trusted third party that can choose to agree with a proposed settlement price by either the holder or the writer of the piggy. This optional protection feature is intended to address incorrect (unintentional or otherwise) prices supplied by the oracle, or if the oracle never responds and a price is never received.
Collateral Amount
This is the amount of collateral the piggy will hold, the maximum payout available to the holder of a piggy, also the maximum loss possible for the writer.
Lot Size
This is the multiplier for the piggy (the number underlings the contract represents). If someone wants to cover 32 ETH, this field will be 32, and the payout will be multiplied by this factor.
Strike Price
This is the execution price of the underlying where by the piggy is "in-the-money" and begins to pay out. When the price of the underlying moves beyond the strike price, the piggy can be settled for a profit.
Expiry
This is the expiration date of the piggy. This is treated as a unix timestamp that is checked to determined if the piggy is mature. As blockchains progress in discrete time events represented as blocks, the timestamp is a soft expiration constraint. The piggy expires after a timestamp, because of this, it is possible for a gap to occur where by the unix time has passed but the block that would confirm this has yet to be mined. There is no negative consequence of this as the true dependency is that the oracle returns an accurate price at or arounds expiry.
Execution Style
This refers to how the piggy can be settled. Piggies are inspired by classic options contracts, and this attribute determines if the piggy behaves as an American style or European style option. The holder, and only the holder, can settle a piggy before expiration for an American style piggy. No one can settle a piggy before expiration if it is created or requested as a European style.
Direction
This refers to whether the piggy pays out as a classic PUT or CALL option.
Request Field
Is this piggy a request-for-piggy or not. If this field is true, the piggy will be an RFP, if this field is false, the piggy will be a regular, "real" piggy collateralized with tokens.
Footnotes
The EIP detailing the standard for ERC20 tokens on Ethereum does not include a decimals attribute. This, however, is required to be implemented to serve as appropriate collateral for SmartPiggies. SmartPiggies will not execute payouts correctly if there is no decimals data supported in the token contract used for collateral. All commonly known and widely used stable tokens implement this attribute on their contracts.
Last updated