> For the complete documentation index, see [llms.txt](https://docs.metric.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.metric.xyz/run-a-pool/chain-specific-guides/bsc.md).

# BSC

On BSC, a higher fee per gas can improve a transaction's position, but final ordering also depends on **total block profitability**. Large transactions, or bundles with big bids or bribes, can be placed ahead of a market maker's oracle update, even when the update pays a higher fee per gas.

Builders have an incentive to include arbitrage against stale quotes when it makes their block proposal more profitable. This can expose propAMM liquidity to repeated adverse trades and erode market-maker returns. Stale quotes are the main risk for update-dependent pools on BSC; the protected execution lane below reduces it.

## Update-independent pools

If your pool doesn't need constant oracle updates, nothing special is required: follow [Best practices](/run-a-pool/chain-specific-guides.md) for the security and safety of your pool.

## Update-dependent pools

### Protected execution lane

Metric runs a protected execution lane with the BSC builders 48Club and BlockRazor. It is optional. You don't connect to either builder yourself: you submit your signed quote-update transaction to Metric once, and Metric forwards it to both builders at the same time.

```
POST https://api.metric.xyz/public/v1/evm/56/pamm-quote
```

You need a trading API key for this endpoint.

In blocks that 48Club or BlockRazor build, your update is placed ahead of trades against your pool. Blocks from other builders carry no such commitment. See [Freshness and ordering](/how-pools-work/freshness-and-ordering.md).

* 48Club gets your update over a persistent quote stream. When you send a newer quote (a higher seq on the same uuid), 48Club drops the one it replaces. An empty tx cancels your live quote.
* BlockRazor gets your update as a bundle that goes first in the block. It is paid inclusion: every bundle it accepts can land and pay gas on its own, whether or not anyone trades against your pool in that block.

#### What each submission must carry

* **blockNumber**: the last block your quote is valid for. It must be non-zero for a live quote.
* **maxTimestamp** (unix seconds): when your quote expires. It can be at most 5 seconds ahead of the current time. If you leave it out, your update still goes to 48Club, but the BlockRazor leg is skipped.

#### Canceling and stale quotes

BlockRazor has no cancel operation. A bundle it has accepted stays live until its `blockNumber` or `maxTimestamp` passes, even after you send a newer quote or a cancel. The same signed transaction can only land onchain once, so it can never be included twice. But an outdated quote can still land within that window. A short `maxTimestamp` is your only protection against this, so keep it as tight as your update cadence allows.

#### Accepted is not included

The response lists each builder's result. Metric answers within 500 ms; a builder that hasn't answered by then shows `pending: true`, and your quote is still delivered to it. `accepted: true` means at least one builder took your quote by then. It does not mean the quote landed onchain. For BlockRazor, the response also returns a bundleHash. Judge the lane on what lands onchain, not on acceptances.