A liquidity bridge quote should tell the user what was checked and how long that observation is useful. Available inventory can change between the quote and destination execution, especially when several users receive quotes against the same pool.
The current Passage Bridge quote response makes this limitation explicit. It returns a timestamp about 30 seconds ahead, the checked block numbers and hashes, and flags stating that inventory is not reserved and execution is not guaranteed. This article follows the local quote implementation. A reservation system would be additional work.
Give the quote a reproducible basis
The service resolves the requested route, then selects checked blocks on the source and destination chains. Contract reads use those block numbers. It reads the fee rate and minimum transfer amount, checks whether either pool is paused, and checks supported routes and assets.
It also compares the configured remote bridge addresses on both sides. For non-native assets, the forward and backward token mappings must agree with the route. A route can therefore be unavailable even while a destination pool has sufficient cash. Returning inventory alone would hide these execution conditions from the user.
After calculating the quote, the service checks that the blocks it read still have the expected hashes. A changed branch returns a service error instead of silently presenting a result assembled from conflicting chain history. The response retains the checked block identities so the observation can be discussed later.
Separate gross amount, fee and destination capacity
The interface and database use raw integer decimal strings. Arithmetic uses large integers, while display formatting applies the asset precision. The local materials show an illustrative 0.15 ETH input, 0.0015 ETH fee and 0.1485 ETH expected output. Those values describe the demonstration configuration, with no promise of a production rate.
For tokens, the address and network identify the asset being quoted. The ERC-20 specification describes decimals as display scaling and makes token metadata optional. A symbol such as USDC cannot substitute for a reviewed token mapping and precision configuration.
Destination spendable inventory is computed from the accounting snapshot, which includes cash, funding, fee and buffer amounts. The quote compares the net payout with that spendable amount. It separately checks the per-message and daily payout limits. A pool can have money available while the configured daily budget prevents another payout.
| Quote field | Meaning in the current local response | Client behavior to review |
|---|---|---|
amount, fee, netAmount |
Raw integer payment values | Format with the selected asset precision |
destinationSpendable |
Computed capacity at the checked block | Label as an observed value |
reasons |
Failed route or payout conditions | Show an actionable explanation |
checkedBlocks |
Source and destination block identities | Retain with the quote evidence |
expiresAt |
Short quote freshness timestamp | Refresh before relying on old values |
reserved and executionGuaranteed |
Both false | Avoid implying a committed payout |
Treat expiry as a refresh boundary
The returned expiration time gives a client a concrete refresh point. It does not create a reservation in the destination pool. The source transaction assembled by the inspected quote method contains the initiation arguments and value; the response's expiry is not passed as a reserved-inventory claim.
A useful client behavior is to refresh before initiating a stale quote and show changed values before asking for a signature. This is a review recommendation, rather than a claim that the timestamp creates a contract-enforced price lock. Any application requiring a guaranteed net amount needs an explicit design for how that guarantee is accepted and enforced.
Execution still occurs later, after source confirmation and independent message approval. The local relayer validates the current message and simulates the destination call before signing. Inventory, quotas or paused state may differ by then. The user interface should retain the original source transaction and explain which stage is waiting instead of suggesting a second source transfer.
Decide whether reservations are actually required
If a project needs reservations, specify who can create one, which asset pool it charges, and when it expires. Concurrent quotes would need an atomic way to allocate capacity. Abandoned purchases need release rules, and a delayed source transaction needs a defined outcome after reservation expiry. These are proposed requirements outside the current implementation.
Begin review with two quotes that fit individually but exceed available inventory together. Add a daily-limit change, a pool pause and a changed token mapping between quote and execution. Record both the original response and the later execution result. That evidence reveals whether the product communicates the difference clearly.
Download the bridge quote requirements and concurrency matrix.
Every worksheet case is marked Not run. Passage Bridge uses local Anvil evidence and independent approval in an operated liquidity model. Production automatic broadcast remains disabled; production liquidity and deployment responsibilities need separate agreement.
