From 61ad81b10e63a885c00981be872e8da8b39013e4 Mon Sep 17 00:00:00 2001 From: Navid TehraniFar Date: Wed, 7 Aug 2024 16:07:06 -0700 Subject: [PATCH 1/5] FLIP 281: Integrating `LostAndFound` with Flow Port and Flow Wallet for Token Transfers --- application/20240807-lost-and-found.md | 131 +++++++++++++++++++++++++ 1 file changed, 131 insertions(+) create mode 100644 application/20240807-lost-and-found.md diff --git a/application/20240807-lost-and-found.md b/application/20240807-lost-and-found.md new file mode 100644 index 00000000..9ec02048 --- /dev/null +++ b/application/20240807-lost-and-found.md @@ -0,0 +1,131 @@ +--- +status: draft +flip: 281 +authors: Navid TehraniFar (navid.tehranifar@flowfoundation.org) +sponsor: Greg Santos (greg.santos@flowfoundation.org) +updated: 2024-08-07 +--- + +# FLIP 281: Integrating `LostAndFound` with Flow Port and Flow Wallet for Token Transfers + +## Objective + +When a Flow user wants to send a token to another account, the recipient's account must be initialized to receive that type and have sufficient storage. If these conditions are not met, the token transfer transaction will fail. + +To address this issue, an intermediate contract can store the tokens until the recipient is ready to claim them. Austin Kline (@austinkline) from Flowty has developed a solution based on this concept called [LostAndFound](https://github.com/Flowtyio/lost-and-found). The sender can transfer tokens to the `LostAndFound` contract, and the recipient can claim them when they are online. + +This FLIP proposes integrating the `LostAndFound` contract into the Flow Port and Flow Wallet products to mitigate account initialization and storage errors without altering the Flow protocol or Cadence. + +## Motivation + +Token transfers fail if the recipient's account is not initialized or lacks sufficient storage. This situation requires the recipient to initialize their account before the transaction can complete, negatively impacting the user experience. Our goal is to enhance the token transfer process by providing a solution that allows tokens to be stored until the recipient is ready to claim. + +## User Benefit + +Integrating `LostAndFound` with Flow Port and Flow Wallet ensures that token transfers will not fail due to the recipient's account not being initialized. Senders can transfer tokens to the `LostAndFound` contract, and recipients can claim them when they are online. + +## Design Proposal + +We propose integrating the `LostAndFound` contract, already [deployed](https://contractbrowser.com/A.473d6a2c37eab5be.LostAndFound) on mainnet, with Flow Port and Flow Wallet. The contract uses a type-based ticketing system with support for fee estimation. More details are available in the project's [repository](https://github.com/Flowtyio/lost-and-found). + +#### Sending Tokens + +When the user enters the recipient's address on Flow Port or Flow Wallet, a Cadence script will be executed that checks if the receiving side has initialized their account to receive that type and has enough storage. The result could be one of the following: + +- **Initialized with sufficient storage** + + The transaction proceeds as usual. + +- **Initialized but lacks storage** + + The amount of extra storage and required FLOW tokens will be calculated and displayed to the sender. If the user confirms the transaction, the required FLOW tokens are also sent to the receiver. In this case the `FeeEstimator` contract will be used, but the tokens can be sent directly to the receiver. + +- **Not initialized** + + The amount of needed storage and required FLOW tokens are calculated and displayed to the sender. Upon confirmation, the tokens and required FLOW for storage will be deposited into the `LostAndFound` contract. The receiver can choose to claim the tokens and FLOW when they are online. + +#### Receiving Tokens + +When a user logs in to Flow Port or Flow Wallet the following will happen: + +1. A script will be executed to check if the user has any unclaimed tokens in the `LostAndFound` contract. + +2. If the user has unclaimed tokens, they will be shown in the new "inbox" section. In this screen, the user can: + + - View a list of unclaimed tokens and the associated FLOW stored for each. + + - Redeem one or multiple number of tokens. The user will be prompted to approve the transaction to claim the token(s) and FLOW. + + - Discard one or multiple number of tokens. The user will be prompted to approve the transaction. The tokens will be destroyed and the user can claim the FLOW for storage. + +### Drawbacks + +- This solution addresses token transfer issues at the application level and does not resolve the problem at the protocol level. + +- Different platforms can choose to deploy their own `LostAndFound` contract, which may lead to fragmentation. + +### Alternatives Considered + +#### Using child accounts + +Instead of a contract, the sender could create a child account for the recipient and transfer the tokens there. The recipient can later claim the account. However, the minimum storage balance cannot be claimed by the recipient as accounts cannot be destroyed on Flow, making this solution more costly for the sender and recipient. + +#### Solving at Protocol Level + +Several protocol-level solutions could address this issue, but they would require changes to the Flow protocol and/or Cadence. This FLIP avoids these changes by providing an application-level fix. + +### Performance Implications + +All the tokens are stored in a single universal `LostAndFound` contract. This can cause performance issues if the contract is used by a large number of users. + +### Dependencies + +This FLIP introduces the `LostAndFound` contract as a dependancy for the Flow Port and Flow Wallet products. + +It's recommended that the Flow Foundation co-own the `LostAndFound` contract, ensuring that changes are confirmed by multiple parties. + +### Best Practices + +This FLIP introduces a new best practice especially for wallet providers: always check if the recipient has initialized their account and has enough storage before sending tokens. If not, deposit the token(s) into `LostAndFound`. Documentation and guides will be updated accordingly, and other applications and wallets can adopt the necessary scripts and transactions. + +### Examples + +The `LostAndFound` [repository](https://github.com/Flowtyio/lost-and-found) includes examples for using the contract: + +#### Scripts + +* Estimating storage fee: [estimate_deposit_nft.cdc](https://github.com/Flowtyio/lost-and-found/blob/main/scripts/lost-and-found/estimate_deposit_nft.cdc) + +* Fetching all unclaimed tokens info: [borrow_all_tickets.cdc](https://github.com/Flowtyio/lost-and-found/blob/main/scripts/lost-and-found/borrow_all_tickets.cdc) + +#### Transactions + +* Depositing a token: [try_send_multiple_example_nft.cdc](https://github.com/Flowtyio/lost-and-found/blob/main/transactions/example-nft/try_send_multiple_example_nft.cdc) + +* Redeeming tokens based on type: [redeem_example_nft_all.cdc](https://github.com/Flowtyio/lost-and-found/blob/main/transactions/example-nft/redeem_example_nft_all.cdc) + +### Compatibility + +No compatibility issues are expected. + +### User Impact + +This will be released as a new feature in Flow Port and Flow Wallet. + +## Related Issues + +Supporting token transfers to uninitialized accounts natively is considered out of scope for this FLIP. This FLIP is an application-level solution for token transfer issues. + +## Prior Art + +Storage and account initialization are unique concepts of Flow. + +## Questions and Discussion + +1. Is the design outlined here sufficient to solve the problem? Are there better ways to address token transfer errors? + +2. Does the `LostAndFound` contract meet the requirements outlined here? + +3. Is the contract secure enough? + +4. What are the performance implications of storing all tokens in a single contract? \ No newline at end of file From 755a0cc826eb79292b4dc7961be6e79b5aba8fec Mon Sep 17 00:00:00 2001 From: Navid TehraniFar Date: Tue, 20 Aug 2024 18:38:19 -0700 Subject: [PATCH 2/5] fix storage token design --- application/20240807-lost-and-found.md | 14 +++++--------- 1 file changed, 5 insertions(+), 9 deletions(-) diff --git a/application/20240807-lost-and-found.md b/application/20240807-lost-and-found.md index 9ec02048..16f65a64 100644 --- a/application/20240807-lost-and-found.md +++ b/application/20240807-lost-and-found.md @@ -36,13 +36,9 @@ When the user enters the recipient's address on Flow Port or Flow Wallet, a Cade The transaction proceeds as usual. -- **Initialized but lacks storage** +- **Not initialized** or **Initialized but lacks storage** - The amount of extra storage and required FLOW tokens will be calculated and displayed to the sender. If the user confirms the transaction, the required FLOW tokens are also sent to the receiver. In this case the `FeeEstimator` contract will be used, but the tokens can be sent directly to the receiver. - -- **Not initialized** - - The amount of needed storage and required FLOW tokens are calculated and displayed to the sender. Upon confirmation, the tokens and required FLOW for storage will be deposited into the `LostAndFound` contract. The receiver can choose to claim the tokens and FLOW when they are online. + The amount of needed storage and required FLOW tokens are calculated and displayed to the sender. Upon confirmation, the tokens and required FLOW for storage will be deposited into the `LostAndFound` contract. The receiver can choose to claim the tokens when they are online. #### Receiving Tokens @@ -52,11 +48,11 @@ When a user logs in to Flow Port or Flow Wallet the following will happen: 2. If the user has unclaimed tokens, they will be shown in the new "inbox" section. In this screen, the user can: - - View a list of unclaimed tokens and the associated FLOW stored for each. + - View a list of unclaimed tokens and the associated info. - - Redeem one or multiple number of tokens. The user will be prompted to approve the transaction to claim the token(s) and FLOW. + - Redeem one or multiple number of tokens. The user will be prompted to approve the transaction to claim the token(s). FLOW tokens held for storage will be transferred to the sender. - - Discard one or multiple number of tokens. The user will be prompted to approve the transaction. The tokens will be destroyed and the user can claim the FLOW for storage. + - Discard one or multiple number of tokens. The user will be prompted to approve the transaction. The tokens will be destroyed and the sender will receive the FLOW locked for storage. ### Drawbacks From af2cddcd8bc159d9e97977575df73c136227faaf Mon Sep 17 00:00:00 2001 From: Navid TehraniFar Date: Tue, 20 Aug 2024 18:42:52 -0700 Subject: [PATCH 3/5] add comment --- application/20240807-lost-and-found.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/application/20240807-lost-and-found.md b/application/20240807-lost-and-found.md index 16f65a64..c749ccb7 100644 --- a/application/20240807-lost-and-found.md +++ b/application/20240807-lost-and-found.md @@ -64,7 +64,7 @@ When a user logs in to Flow Port or Flow Wallet the following will happen: #### Using child accounts -Instead of a contract, the sender could create a child account for the recipient and transfer the tokens there. The recipient can later claim the account. However, the minimum storage balance cannot be claimed by the recipient as accounts cannot be destroyed on Flow, making this solution more costly for the sender and recipient. +Instead of a contract, the sender could create a child account for the recipient and transfer the tokens there. The recipient can later claim the account. However, the minimum storage balance cannot be claimed by the recipient as accounts cannot be destroyed on Flow. Additionally, the minimium storage balance might increase in the future, thus making this solution more costly for the sender and recipient. #### Solving at Protocol Level From 210097deb7127080f7af4898020079a05bdcceb1 Mon Sep 17 00:00:00 2001 From: Navid TehraniFar Date: Tue, 20 Aug 2024 18:49:28 -0700 Subject: [PATCH 4/5] update ownership --- application/20240807-lost-and-found.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/application/20240807-lost-and-found.md b/application/20240807-lost-and-found.md index c749ccb7..b3c48ca9 100644 --- a/application/20240807-lost-and-found.md +++ b/application/20240807-lost-and-found.md @@ -78,7 +78,7 @@ All the tokens are stored in a single universal `LostAndFound` contract. This ca This FLIP introduces the `LostAndFound` contract as a dependancy for the Flow Port and Flow Wallet products. -It's recommended that the Flow Foundation co-own the `LostAndFound` contract, ensuring that changes are confirmed by multiple parties. +Flowty will continue to own the `LostAndFound` contract. ### Best Practices @@ -124,4 +124,6 @@ Storage and account initialization are unique concepts of Flow. 3. Is the contract secure enough? -4. What are the performance implications of storing all tokens in a single contract? \ No newline at end of file +4. What are the performance implications of storing all tokens in a single contract? + +5. How can users trust contract owners that there will be no rogue updates to the contract code that could affect locked assets? \ No newline at end of file From 3949e846628059352d8a0768d979930269df477f Mon Sep 17 00:00:00 2001 From: Navid TehraniFar Date: Tue, 20 Aug 2024 18:51:14 -0700 Subject: [PATCH 5/5] update to proposed --- application/20240807-lost-and-found.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/application/20240807-lost-and-found.md b/application/20240807-lost-and-found.md index b3c48ca9..1b583e3e 100644 --- a/application/20240807-lost-and-found.md +++ b/application/20240807-lost-and-found.md @@ -1,5 +1,5 @@ --- -status: draft +status: proposed flip: 281 authors: Navid TehraniFar (navid.tehranifar@flowfoundation.org) sponsor: Greg Santos (greg.santos@flowfoundation.org)