PUB-005 — DIVULGACIÓN DE TARIFAS DE RED Network Fee Disclosure
- Entidad / Entity
- BLIIM GLOBAL LLC — Delaware, United States
- Documento / Document
- Divulgación de Tarifas de Red / Network Fee Disclosure
- ID
- PUB-005
- Versión / Version
- V1.1
- Fecha de vigencia / Effective date
- 6 de octubre de 2026 / 6 October 2026
- Ámbito / Scope
- Web, app y funcionalidades de activos digitales habilitadas / Web, app and enabled digital-asset functionalities
PRINCIPIO DE TRANSPARENCIA / TRANSPARENCY PRINCIPLE Una tarifa de red no debe confundirse con una tarifa cobrada por Bliim o por un partner. Cuando una tarifa se determine en el activo nativo de una red y se muestre un equivalente en moneda fiat, dicho importe puede ser estimado y variar hasta la ejecución. Antes de confirmar una operación, el usuario debe poder identificar, cuando corresponda, la naturaleza del cargo, quién lo cobra y si puede variar.
A network fee must not be confused with a fee charged by Bliim or by a partner. Where a fee is determined in a network's native asset and a fiat equivalent is displayed, that amount may be estimated and may vary until execution.
Before confirming a transaction, the user should be able to identify, where applicable, the nature of the charge, who charges it and whether it may vary.
1. Purpose
This Disclosure establishes how Bliim communicates fees associated with blockchain networks, distributed ledger technology, infrastructure providers and other third parties involved in a digital-asset transaction. Its purpose is to enable users to distinguish the network's own cost from a Bliim fee, a partner fee, a conversion spread, an FX cost and any other material charge.
PUB-005 does not set production amounts. Specific values must come from the network, provider, partner, quote or pricing configuration actually applicable and must be reconciled with the applicable fee, limits and foreign-exchange disclosure.
2. Scope
It applies to transactions in which a network fee, gas fee, miner/validator fee, protocol fee, bridge fee, Layer 2 fee, relayer fee, provider fee, withdrawal fee or another charge related to the technical execution or processing of digital assets may arise. It may apply to wallet, stablecoins, conversions, on-chain transfers, cross-border flows with a blockchain leg and other expressly enabled flows.
Not every category exists in every product or network.
3. Nature of the Disclosure
PUB-005 is both a general disclosure and an implementation specification. Where the specific fee is known or reasonably estimable before a transaction, the application must display it through a sufficiently prominent just-in-time disclosure before confirmation.
Acceptance of this Disclosure does not authorize undisclosed charges or replace specific regulatory requirements that require a different presentation or breakdown.
4. Fee Taxonomy
The term “fee” must not be used as a single undifferentiated category where economically distinct concepts exist. The architecture must identify, as applicable, network/gas fee, Bliim service fee, partner/provider fee, withdrawal/transfer fee, bridge/protocol fee, card/rail fee, spread/FX component, tax and any material third-party charge.
Users should be able to reasonably understand which portion relates to external infrastructure and which portion constitutes a service price or charge.
5. Bliim's Role and Partner Allocation
Bliim may calculate, estimate, display, charge or pass through certain fees depending on the product, but that does not mean Bliim determines the economic cost of a decentralized network. In other cases the partner may set or charge the fee directly, or Bliim may recover a cost paid on the user's behalf.
UI, receipts and accounting mapping must remain consistent with the entity that actually charges or bears each component.
6. Network Fee ≠ Bliim Fee
A fee paid to validators, miners, sequencers, relayers, protocol participants or other infrastructure operators must be distinguished from a commercial fee charged by Bliim. If Bliim adds a markup, service fee or convenience fee, that component must be separately identified where material and legally required.
A margin retained by Bliim as its own revenue must not be labelled “network fee” where that description would be misleading.
7. Network Fee ≠ Partner Fee
A provider may apply a withdrawal fee, transfer fee, processing fee or network-cost recovery that is not identical to the observed on-chain cost. The application must avoid presenting a partner charge as though it necessarily equals the exact amount paid to the blockchain.
Where the partner bundles several costs into one fee and does not provide a breakdown, Bliim must describe it consistently with partner documentation and must not invent a breakdown.
8. Denomination in the Native Asset
Many networks determine fees in the network's native asset even when the asset being transferred is a stablecoin or another token. For example, a token transaction on an EVM network may require gas denominated in the corresponding native asset.
The asset used to pay the fee, who supplies it and how it is deducted must be defined by product and network.
9. Display in USD or Another Fiat Currency
Where the application displays a network fee in USD, EUR, COP, MXN or another fiat currency while the underlying cost is denominated in a digital asset, it must state that the fiat value is an equivalent or estimate calculated using a specified rate. The UI must not present “USD X” as a fixed dollar fee where the actual charge varies in the network asset.
As a design standard, where material the underlying denomination and fiat equivalent should both be shown, for example: “Estimated Network Fee: [native asset amount] ≈ [USD equivalent]” , without inserting fictitious values into the documentation.
10. Conversion Source, Timestamp and Rounding
Where a fiat equivalent is presented, there must be an identifiable price or FX source, a timestamp reasonably close to the quote, a conversion methodology and rounding rules. The equivalent may differ from the value ultimately observed because of changes in the asset price or the network fee.
If the fiat amount is guaranteed by a quote for a period, the UI must identify its validity and expiry conditions.
11. Estimated Fee vs. Exact Fee
Network fees may not be known exactly before execution. Where the amount is estimated, the word “Estimated / Estimada” or an equivalent term must be visible and users must not receive a representation of certainty that does not exist.
Where the architecture permits a fixed amount to be charged to the user regardless of the network cost, it must be clear who bears the difference between estimated and actual cost.
12. Variation Due to Network Demand
Fees may increase or decrease with demand, congestion, computational complexity, selected priority, transaction size, data availability, consensus mechanism or other network factors. A previously observed fee does not guarantee the cost of a later transaction.
The application must not reuse stale values where a change could be material.
13. Gas and Computational Effort
On networks that use gas, the fee may depend on units of computation consumed and the price per unit.
Transactions involving smart contracts, bridges, swaps or other complex calls may require more resources than a simple transfer.
Terms such as “gas” , “miner fee” or “validator fee” must be used only where technically accurate for the network.
14. Base Fee, Priority Fee and Network-Specific Components
Some networks may divide cost into protocol, priority, data, sequencer or other components. Bliim need not expose every technical mechanism where doing so would impair comprehension, but it must display components that are material to the price or legally required to be broken down.
Bliim must maintain sufficient internal documentation of the calculation logic even where the interface uses a simplified explanation.
15. Layer 2, Rollups and Data Availability
On Layer 2 or rollup systems, cost may include secondary-layer execution, data publication, base-layer settlement, sequencer fees or other components. A lower fee relative to Layer 1 must not be presented as permanently guaranteed.
The specific network and model must be identified so that fees from different layers are not compared as though they were equivalent.
16. Bridges and Cross-Chain Transactions
A cross-chain transaction may generate one or more charges: origin-network fee, bridge/protocol fee, relayer fee, destination-network fee or provider fee. The disclosure must avoid presenting a single “network fee” where doing so conceals known material components.
Where part of the cost is not reasonably determinable before confirmation, that limitation must be communicated clearly.
17. Third-Party and Provider Fees
Banks, custodians, exchanges, liquidity providers, payment rails, card/withdrawal providers or other third parties may impose separate charges. PUB-005 incorporates them only to the extent they are materially part of the digital-asset flow; other fees must be reconciled with the applicable fee, limits and foreign-exchange disclosure and specific terms.
The existence of third-party fees does not authorize Bliim to duplicate the same charge under another label.
18. Bliim Service Fee
If Bliim charges its own fee related to an on-chain transaction, it must be sufficiently clearly identified as a Bliim fee, service fee or another accurate label. The amount, calculation method and charging point must match the applicable fee, limits and foreign-exchange disclosure and the approved pricing configuration.
If the fee is zero, Marketing must not use “free” where network fees, spreads or other unavoidable material costs exist.
19. Spread, FX and Conversion Costs
A spread or cost embedded in a conversion is not a network fee. Where a transaction involves fiat ↔ digital asset or asset ↔ asset conversion, the pricing disclosure must appropriately separate or explain the exchange rate, spread, service fee and network fee according to the product.
the applicable fee, limits and foreign-exchange disclosure and the wallet, stablecoin and fiat-conversion terms must remain consistent with this Disclosure.
20. Gross Amount, Net Amount and Who Bears the Fee
The disclosure must identify whether the fee is added to the amount sent, deducted from the transferred asset, reduces the amount received by the beneficiary, is charged from another balance or is absorbed by Bliim/partner. That mechanism materially affects the final amount and must not remain implicit.
Where applicable, the UI should show “Amount Sent” , “Network Fee” , “Other Fee” and “Estimated/Actual Amount Received” or functionally equivalent terms.
21. Disclosure Before Confirmation
Before executing a transfer for which the fee is material and determinable or estimable, the user must see the applicable amount or estimate, denomination currency/asset, nature of the charge and corresponding total or economic impact. The information must be sufficiently proximate to the confirmation button or event to prevent surprise fees.
Material charges must not be hidden solely behind a secondary link where a user could reasonably believe that the confirmation screen shows the total cost.
22. Post-Transaction Disclosure
After execution, the receipt or transaction details must show, where available and material, the fee actually charged, its type, asset/currency, provider/network and any difference from the estimate.
Post-transaction information must reconcile with ledger, partner statement and on-chain evidence where applicable.
Where the actual fee cannot be individualized because the provider uses batching or aggregate pricing, the methodology used to inform the user must be documented.
23. Difference Between Estimate and Actual
An actual network fee may be higher or lower than the estimate because of network changes, gas usage, batching, execution path, price movement or other factors. The design must establish a tolerance, cap or reconfirmation rule where variation could be material to the user.
The tolerance policy must be documented and tested rather than informally determined by the interface.
24. Maximum Fee, Cap and User-Selected Priority
Where a network or wallet allows a max fee, fee cap, priority level or similar parameter, the UI must explain whether the value represents a potential maximum, reservation, estimate or final amount. A maximum must not be presented as though it will necessarily be consumed.
If the user cannot modify priority because it is automatically managed by the partner, the interface must not suggest that such an option exists.
25. Failed or Reverted Transactions
On certain networks a fee may be consumed even where execution of the transaction fails or reverts after network resources have been used. In other circumstances an instruction rejected before inclusion may consume no network fee. Treatment must be determined by network and processing stage.
Where this risk exists for a supported network, it must appear in the just-in-time disclosure or material accessible from the flow.
26. Dropped, Replaced, Cancelled and Retried Transactions
A transaction may remain pending, be replaced, dropped, re-broadcast or be subject to an attempted cancellation depending on the network and provider. Those actions may create additional costs or may not return a fee already consumed.
Bliim must not promise free cancellation or fee recovery unless the architecture guarantees it.
27. Underpriced, Stuck and Congestion Scenarios
An insufficient fee or abrupt increase in congestion may delay inclusion of a transaction or require repricing/replacement mechanisms where supported. Users should understand that increasing priority may increase cost.
Availability of repricing depends on network, wallet model, custodian and provider.
28. Refundability
Network fees paid to a network or third party may be non-refundable even where Bliim refunds its own service fee. The policy must distinguish network reimbursement, provider reimbursement and Bliim fee refund.
A no-refund clause cannot be used to exclude mandatory legal rights relating to an error or improper charge.
29. Rejection, Suspension, Return and Fees
Where a transfer is rejected, suspended or returned, the user must be informed, where applicable, of fees already incurred and whether reimbursement is possible. An uncompleted transaction must not be assumed to have zero cost automatically.
This treatment must be coordinated with applicable finality disclosures and the relevant legal and compliance controls.
30. Incoming Transfers and Sender-Side Fees
For an inbound transaction, the user may receive fewer assets than originally sent where the sender, exchange, network or provider deducts fees before arrival. Bliim must not automatically present that difference as a fee charged by Bliim.
Where sufficient information exists, transaction details should distinguish the amount received by Bliim infrastructure from the amount originally instructed by the third party.
31. Network Congestion and Fee Spikes
Periods of congestion may cause substantial and rapid fee increases. The application may temporarily suspend a flow, require reconfirmation or display a warning where the cost is abnormally high against approved parameters.
Warning thresholds are operational parameters and must be retained as evidence rather than published as universal limits where doing so could facilitate manipulation or quickly become obsolete.
32. Fee Sponsorship, Gas Abstraction and Subsidies
Bliim or a partner may, for certain products, pay gas on behalf of a user, subsidize it, recover it in another asset or embed it in pricing. Where this occurs, the UI must explain the real economic effect and avoid claiming “no network fee” where the cost is merely recovered through another undisclosed component.
Promotional subsidies must have clear scope, duration and conditions.
33. “Free”
, “Zero Fee” or “No Commission” Claims Expressions such as “free” , “zero fee” , “no commission” or equivalents may be used only where accurate as to the concept described and where they do not conceal material spreads, network fees, withdrawal fees or third-party charges. If Bliim charges no service fee but the user pays gas, the claim must be clearly limited to Bliim's fee.
Marketing and UX must reconcile all claims against the applicable fee, limits and foreign-exchange disclosure and the actual product configuration.
34. Taxes and Regulatory Charges
Taxes, levies or governmental charges must not be combined with network fees. Where Bliim or a partner must collect or display such a charge, it must be separately identified under applicable law.
PUB-005 is not tax advice and does not determine a user's personal tax obligations.
35. United States — Remittance / Consumer Transfer Conditionality
If a Bliim transaction is legally characterized as a remittance transfer under Regulation E and Bliim or the partner is the remittance transfer provider, fee, exchange-rate, covered-third-party-fee, total and amount-received disclosures must comply with the applicable regime. That conclusion depends on the actual product architecture and the legally responsible entity; this Disclosure does not presume that a digital-asset transfer is automatically a regulated remittance transfer.
The cross-border transfer terms and the applicable fee, limits and foreign-exchange disclosure must reconcile any network/third-party fee with the prepayment/receipt disclosure where that regime applies.
36. Spain / EEA — MiCA and Transfer Services
Where the service falls within MiCA, Article 82 requires the transfer-service agreement to identify, among other matters, the fees applied by the CASP. ESMA's Guidelines on transfer services further state that, before execution of an individual transfer, the client should receive the amount of charges and, where applicable, a breakdown distinguishing, for example, gas fees from other fees charged by the CASP.
Those rules apply only where the relevant provider, service and legal scope are confirmed for the specific product.
37. Colombia, Mexico and Brazil
For Colombia, Mexico and Brazil, pricing, consumer-information, FX/payment-disclosure and digital-asset-fee requirements depend on the actual product, responsible entity and applicable law. This Disclosure establishes a general transparency standard but does not replace mandatory local formats, rights or rules.
Labels such as “fee” , “commission” , “network fee” or equivalents must be used consistently with the actual nature of the charge.
38. Marketing, UI and Fair Presentation
Marketing, Product and CX must avoid presenting the lowest possible fee as though it were typical or guaranteed where it depends on network conditions. Screenshots, landing pages, FAQs and tooltips must remain consistent with actual pricing logic and the point at which an estimate may change.
Where a cost advantage is promoted, reasonable evidence must support the comparison and its applicable period.
39. User Responsibilities
Users should review the displayed fee, network, asset, amount to be sent and impact on the amount received before confirming. Where the UI offers priority levels or modifiable parameters, users should understand that their selection may affect cost and speed.
These responsibilities do not remove Bliim's or a partner's disclosure, error-handling or consumer-protection obligations.
40. Complaints, Errors and Fee Disputes
Users may challenge a fee they consider incorrect, duplicated, undisclosed or inconsistent with the applicable quote through Bliim's available support and complaints channels. The investigation must distinguish a network fee, Bliim fee, partner fee, spread and any third-party charge.
The case file must retain the quote, timestamp, pricing configuration, transaction ID, available on-chain evidence and ledger/provider records.
41. Versioning and Pricing Changes
Changes to fee methodology, provider markups, supported networks, pricing source, gas abstraction, fee sponsorship, FX source or UI presentation must be evaluated under the internal change-control process where material. Contractual pricing changes must also follow applicable notice/reacceptance requirements.
A fee label must not be changed without confirming that its economic nature remains consistent.
42. Contact
For legal questions relating to this Disclosure, you may contact [email protected]