Four things a storage project should not put in one budget cell
| Item | Role in the selected workflow | Evidence to obtain |
|---|---|---|
| USDT used for this exchange | Input asset used to buy FIL | Sending network and the exchange funding instruction |
| FIL received in your wallet | Native asset needed for Filecoin gas in the documented quick start | Correct receiving account and native FIL credit |
| USDFC storage funding | Separate service-payment asset in the Onchain Cloud workflow | Current application funding requirements |
| Stored file and retrieval result | The actual outcome your project needs | Service record plus a successful retrieval check |
A FIL credit is not evidence that a file has been stored
The exchange transfers an asset. It does not select a storage provider, upload your dataset or create a storage agreement for it. Filecoin’s own explanation separates storage tools, provider agreements and data retrieval. Keep those actions in the storage application rather than expecting a wallet credit to perform them.
This matters when a developer asks you to “fund Filecoin.” Ask which balance is missing: native FIL for network operations, a service-payment balance, or a particular application deposit. The current Onchain Cloud documentation describes storage payments in USDFC. Substituting more FIL for that balance does not establish that its payment account is funded.
Prepare a short funding handover before buying FIL
- Name the application and environment
Record the actual storage product, the account that will operate it and whether the instructions are for production. A generic Filecoin label is not a complete purchase request. Obtain the receiving instruction from the wallet or application owner who will use the gas balance.
- Separate the required assets and their purposes
Ask for the current funding check and distinguish gas from storage charges. Use the application’s current cost preview where available. Do not convert an old dollar estimate into a supposed fixed amount of FIL or assume that all Filecoin-related services bill in the same asset.
- Confirm receipt before handing the project back
After the exchange, identify the FIL credit in the intended account and keep the payout reference. The application owner can then check the next storage operation. Treat storage readiness and the eventual retrieval result as separate acceptance checks, not as statuses supplied by the exchange.
If the upload still fails, identify the missing condition
A received FIL balance can coexist with an unfunded service account. A funded service account can also exist before any file has been uploaded. Describe what the application actually reports rather than buying the same asset repeatedly. Ask the storage operator about its own account readiness and payment conditions.
For a usable handover, save the exchange reference, the receiving account, the storage service’s own record and the retrieval instruction in separate fields. Do not send a private dataset or wallet recovery material to exchange support to prove that storage failed. A storage problem and an asset-transfer problem need different evidence.
Questions before funding a storage workflow
- Does buying FIL automatically pay for an Onchain Cloud upload?
- No. Its quick start distinguishes FIL for gas from USDFC for storage payments, and the upload remains a separate application action.
- Are USDT and USDFC the same payment balance?
- No. Do not substitute the USDT spent on an exchange for the USDFC account balance requested by the storage application.
- What proves that my file is available?
- Use the storage service record and test the intended retrieval process. A FIL payout reference proves a different stage and is not an availability test.
Storage workflow documentation
- Filecoin Onchain Cloud quick start: FIL and USDFC roles
- Onchain Cloud payment operations
- Filecoin storage and retrieval overview
Reviewed: