Recreate Buyable Tokens PR

HIP/hip-498.md

@@ -0,0 +1,125 @@
+---
+hip: 498
+title: Buyable Tokens
+author: The Matt Smithies <matt.s@dovu.io>, Wes Geisenberger <wes@hbar.fund>, Brian Johnson <johnsonb@objectcomputing.com>, Ciju John <johnc@objectcomputing.com>, Andy Gastwirth <andrew.gastwirth@dlapiper.com>, Jo Vercammen <jo.vercammen@meeco.me>
+type: Service
+category: Service
+needs-council-approval: Yes
+last-call-date-time: 2022-06-01T07:00:00Z
+status: Last Call
+created: 2022-03-03
+discussions-to: https://github.com/hashgraph/hedera-improvement-proposal/discussions/485
+updated: 2022-05-30
+---
+
+## Abstract
+
+Proposes platform enhancements to enable token transactions without an additional signature.
+
+## Motivation
+
+Token transfer transactions currently require the token owners signature. This requires token owners to be actively involved in the token transaction. As such innovations such as asynchronous atomic swaps are not currently feasible.
+
+## Rationale
+
+Availability of criteria driven pre-authorized transactions leads to some innovative use cases e.g. users can do fire-and-forget token sale listings without the need for third-party custody agents. The features proposed herein will facilitate users to predefine sale criterias. The Hedera platform will then asynchronously facilitate atomic swap operations matching said user defined criterias.
+
+As a one time event upon minting, we introduce the boolean field “is_buyable_token”. When this field is enabled, and a sale criteria defined, the token can be transferred as part of an atomic swap transaction that meets said criteria.
+
+In the DEFI scenario, it might be appropriate to programmatically purchase every NFT created by a certain artist, or a series of carbon offsets with particular attributes. This HIP enables the trading of a specific token, either fungible or non-fungible, for another specific token, either fungible or non-fungible.
+
+However this does not cover a scenario where a buyer has fungible tokens that they want to be available for purchasing a "category" of token. Examples of a "category" of token could be a basket of other fungible tokens, or NFTs with specific attributes like created by a specific artist in a specific time period. This would be handled by an additional proposal, the Delegated Token Authority. This will enable users to delegate purchase authority without losing custody. Some example use cases for this are delegated purchase of NFTs with specific attributes like created by a specific artist in a specific time period or carbon offsets with particular attributes. This will enable users to define fire-and-forget purchase directives enabling token transactions without an additional signature.
+
+## User stories
+
+As a software program I want to be able to purchase “buyable tokens” without having to acquire that token owner's signature. I just want to buy it for the listed price.
+
+As a person who wants a particular amount of HBAR (or token) for the buyable tokens listed but does not care about anything else, I want to check a button to make that happen.
+
+As a person who wants to spend a particular amount of HBAR (or token) towards the purchase of a set of tokens with particular attributes, I want to authorize a trusted party to make that happen.
+
+## Specification
+
+```
+message TokenCreateTransactionBody {
+
+    string name = 1;
+    string symbol = 2;
+    uint32 decimals = 3;
+    uint64 initialSupply = 4;
+    AccountID treasury = 5;
+    Key adminKey = 6;
+    Key kycKey = 7;
+    Key freezeKey = 8;
+    Key wipeKey = 9;
+    Key supplyKey = 10;
+    bool freezeDefault = 11;
+    Timestamp expiry = 13;
+    AccountID autoRenewAccount = 14;
+    Duration autoRenewPeriod = 15;
+    string memo = 16;
+    TokenType tokenType = 17;
+    TokenSupplyType supplyType = 18;
+    int64 maxSupply = 19;
+    Key fee_schedule_key = 20;
+    repeated CustomFee custom_fees = 21;
+
+    //new field
+    Bool is_buyable_token = 22;
+}
+
+//new messages
+Message buyableTokenProperties {
+   TokenId buyable_token_id = "COF";    // Token Id that is being sold
+   Uint64 buyable_token_amount = 1000;  // Amount of tokens for sale; amount is in lowest denomination of this token
+   TokenId tradeable_token_id = ;       // The token to be taken in trade for the buyable token; if left empty signifies HBAR token id
+   Uint64 tradeable_token_amount = 10;  // Amount of tradable tokens; amount is in lowest denomination of this token
+   Timestamp buyable_at = <now>;        // sale start
+   Timestamp expire_at = <end>;         // sale end
+}
+
+Message delegatedTokenProperties {
+   TokenId token_id = ;                 // Token Id that is being delegated; if left empty signifies HBAR token id
+   Uint64 delegated_token_amount = 100; // Number of delegated tokens, in smallest unit of this token
+   Account delegatedAccount = "arm";    // Delegated account
+   Timestamp buyable_at = <now>;        // sale start
+   Timestamp expire_at = <end>;         // sale end
+}
+```
+
+New tokens can be defined to be sellable by setting the `is_buyable_token` flag to True.
+
+Tokens can be put up for sale by issuing `buyableTokenProperties` messages. Existing token sales can be canceled by reissuing the `buyableTokenProperties` message with `expire_at` values set in the past.
+
+Purchase directives can be issued via `delegatedTokenProperties` messages. Existing purchase directives can be canceled by reissuing the `delegatedTokenProperties` message with `expire_at` values set in the past.
+
+`buyableTokenProperties` and `delegatedTokenProperties` messages are mutually exclusive. A token can only have one of the kind active at any time.
+
+Both `buyableTokenProperties` and `delegatedTokenProperties` messages temporarily freeze ownership of the associated tokens for the duration of the message. Token owners can cancel active messages to unfreeze tokens.
+
+
+## Backwards Compatibility
+
+Tokens without a `is_buyable_token` field will be defaulted to False.
+
+## Security Implications
+
+Unbounded growth of `buyableTokenProperties` can lend to performance and storage concerns and can be an abuse vector. To mitigate this, users are limited to defining a single active `buyableTokenProperties` for any token the user possesses. New `buyableTokenProperties` for the same token will override the previous buyable criteria with the latest criterias. This caps the number of active `buyableTokenProperties` for any user.
+
+A `delegatedTokenProperties` while retaining token custody, delegates authority. This can be an abuse vector and therefore the user needs to ensure the `delegatedAccount` is trusted.
+
+## How to Teach This
+
+A user can issue fungible or non-fungible tokens set to be sellable (is_buyable_token = True). For any unique NFT or buyable fungible tokens the user holds, they can issue a `buyableTokenProperties` with sale criteria. Buyers interested in said tokens can at any time execute atomic swaps that meets the individual sale criteria. The seller need not be present for the sale as long as the defined sale criteria is met. Sellers can close one or more sale by issuing new `buyableTokenProperties` for those tokens with expired expire_at values.
+
+## Reference Implementation
+
+## Rejected Ideas
+
+## Open Issues
+
+## References
+
+## Copyright/license
+
+This document is licensed under the Apache License, Version 2.0 -- see [LICENSE](../LICENSE) or (https://www.apache.org/licenses/LICENSE-2.0)