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