{"version":3,"file":"kiosk.mjs","names":[],"sources":["../../../../../src/contracts/kiosk/deps/sui/kiosk.ts"],"sourcesContent":["/**************************************************************\n * THIS FILE IS GENERATED AND SHOULD NOT BE MANUALLY MODIFIED *\n **************************************************************/\n\n/**\n * Kiosk is a primitive for building safe, decentralized and trustless trading\n * experiences. It allows storing and trading any types of assets as long as the\n * creator of these assets implements a `TransferPolicy` for them.\n *\n * ### Principles and philosophy:\n *\n * - Kiosk provides guarantees of \"true ownership\"; - just like single owner\n *   objects, assets stored in the Kiosk can only be managed by the Kiosk owner.\n *   Only the owner can `place`, `take`, `list`, perform any other actions on\n *   assets in the Kiosk.\n *\n * - Kiosk aims to be generic - allowing for a small set of default behaviors and\n *   not imposing any restrictions on how the assets can be traded. The only\n *   default scenario is a `list` + `purchase` flow; any other trading logic can be\n *   implemented on top using the `list_with_purchase_cap` (and a matching\n *   `purchase_with_cap`) flow.\n *\n * - For every transaction happening with a third party a `TransferRequest` is\n *   created - this way creators are fully in control of the trading experience.\n *\n * ### Asset states in the Kiosk:\n *\n * - `placed` - An asset is `place`d into the Kiosk and can be `take`n out by the\n *   Kiosk owner; it's freely tradable and modifiable via the `borrow_mut` and\n *   `borrow_val` functions.\n *\n * - `locked` - Similar to `placed` except that `take` is disabled and the only way\n *   to move the asset out of the Kiosk is to `list` it or `list_with_purchase_cap`\n *   therefore performing a trade (issuing a `TransferRequest`). The check on the\n *   `lock` function makes sure that the `TransferPolicy` exists to not lock the\n *   item in a `Kiosk` forever.\n *\n * - `listed` - A `place`d or a `lock`ed item can be `list`ed for a fixed price\n *   allowing anyone to `purchase` it from the Kiosk. While listed, an item can not\n *   be taken or modified. However, an immutable borrow via `borrow` call is still\n *   available. The `delist` function returns the asset to the previous state.\n *\n * - `listed_exclusively` - An item is listed via the `list_with_purchase_cap`\n *   function (and a `PurchaseCap` is created). While listed this way, an item can\n *   not be `delist`-ed unless a `PurchaseCap` is returned. All actions available\n *   at this item state require a `PurchaseCap`:\n *\n * 1.  `purchase_with_cap` - to purchase the item for a price equal or higher than\n *     the `min_price` set in the `PurchaseCap`.\n * 2.  `return_purchase_cap` - to return the `PurchaseCap` and return the asset\n *     into the previous state.\n *\n * When an item is listed exclusively it cannot be modified nor taken and losing a\n * `PurchaseCap` would lock the item in the Kiosk forever. Therefore, it is\n * recommended to only use `PurchaseCap` functionality in trusted applications and\n * not use it for direct trading (eg sending to another account).\n *\n * ### Using multiple Transfer Policies for different \"tracks\":\n *\n * Every `purchase` or `purchase_with_purchase_cap` creates a `TransferRequest` hot\n * potato which must be resolved in a matching `TransferPolicy` for the transaction\n * to pass. While the default scenario implies that there should be a single\n * `TransferPolicy<T>` for `T`; it is possible to have multiple, each one having\n * its own set of rules.\n *\n * ### Examples:\n *\n * - I create one `TransferPolicy` with \"Royalty Rule\" for everyone\n * - I create a special `TransferPolicy` for bearers of a \"Club Membership\" object\n *   so they don't have to pay anything\n * - I create and wrap a `TransferPolicy` so that players of my game can transfer\n *   items between `Kiosk`s in game without any charge (and maybe not even paying\n *   the price with a 0 SUI PurchaseCap)\n *\n * ```\n * Kiosk -> (Item, TransferRequest)\n * ... TransferRequest ------> Common Transfer Policy\n * ... TransferRequest ------> In-game Wrapped Transfer Policy\n * ... TransferRequest ------> Club Membership Transfer Policy\n * ```\n *\n * See `transfer_policy` module for more details on how they function.\n */\n\nimport { MoveStruct } from '../../../utils/index.js';\nimport { bcs } from '@mysten/sui/bcs';\nconst $moduleName = '0x2::kiosk';\nexport const KioskOwnerCap = new MoveStruct({\n\tname: `${$moduleName}::KioskOwnerCap`,\n\tfields: {\n\t\tid: bcs.Address,\n\t\tfor: bcs.Address,\n\t},\n});\n"],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;AAsFA,MAAM,cAAc;AACpB,MAAa,gBAAgB,IAAI,WAAW;CAC3C,MAAM,GAAG,YAAY;CACrB,QAAQ;EACP,IAAI,IAAI;EACR,KAAK,IAAI;EACT;CACD,CAAC"}