FAQ & Integration Guide
FAQ & Integration Guide
Section titled “FAQ & Integration Guide”Liquidity Pool
Section titled “Liquidity Pool”Is the liquidity pool custodial?
Section titled “Is the liquidity pool custodial?”No. The /liquidity pool is a non-custodial AMM deployed on the Snowside subnet
(Uniswap v2 + v3). You sign every transaction in your browser wallet; ecashfarm.com
never holds your keys or your funds. The server remains a read-only relay, consistent
with the project’s core rule: the server is only a block-explorer/broadcast relay.
What’s the difference between “Basic Provider” and “Advanced Provider”?
Section titled “What’s the difference between “Basic Provider” and “Advanced Provider”?”- Basic Provider (Uniswap v2) — You deposit a token pair and receive fungible LP tokens (ERC-20) representing your share of the whole pool. Liquidity covers the full price range (0 → ∞) automatically and earns a fixed 0.30% fee. This is “deposit and forget” — simple, but capital-inefficient (most of your funds sit idle at prices that aren’t trading).
- Advanced Provider (Uniswap v3) — You choose a fee tier (0.05% / 0.30% / 1%) and a custom price range. Your position is a non-fungible NFT (ERC-721) with its own parameters. Concentrating liquidity where the price actually trades is far more capital-efficient, but requires tending: if price leaves your range, you stop earning and must rebalance. Fees are collected manually per position.
Why are pairs listed as pECX/USDC instead of USDC/pECX?
Section titled “Why are pairs listed as pECX/USDC instead of USDC/pECX?”The volatile asset is listed first (the base); the stable/denomination asset is second (the quote). This is the standard exchange convention: the price reads as “1 base = ? quote.”
| Pair | Reads as | Example (pECX ≈ $0.90, BTC.b ≈ $78k) |
|---|---|---|
| pECX/USDC | 1 pECX = ? USDC | $0.90 |
| BTC.b/pECX | 1 BTC.b = ? pECX | ~86,666 pECX |
The platform hosts two pairs: pECX/USDC (the primary pair, traded against the stablecoin) and BTC.b/pECX (the bridge pair, moving BTC into/out of the pECX ecosystem). A generic BTC.b/USDC pair is intentionally omitted — it doesn’t serve the pECX ecosystem and is available on any DEX.
Note: On-chain, Uniswap orders token0/token1 by raw address comparison
(whichever address is numerically smaller), not by your listing order. pECX/USDC
and USDC/pECX resolve to the same on-chain pool; the base/quote choice is purely
a display convention.
What decimals do the tokens use?
Section titled “What decimals do the tokens use?”- pECX: 8 decimals (follows Bitcoin — 1 pECX = 10⁸ base units). This is NOT the ERC-20 default of 18.
- USDC: 6 decimals (Circle standard).
- BTC.b: 8 decimals (Avalanche wrapped BTC follows Bitcoin).
When does the pool go live?
Section titled “When does the pool go live?”The UI is in preview mode until the Snowside engineers deploy Uniswap to the Snowside subnet. Once the contracts are deployed, the addresses are dropped into a single config file and the page goes live — no other code changes needed.
How is custody handled for the BTC side?
Section titled “How is custody handled for the BTC side?”Custody follows a two-track model — neither custodial to ecashfarm.com:
- BTC.b is bridged via the Avalanche Bridge (Ava Labs Core Bridge) → ICTT (Interchain Token Transfer, via ICM/Teleporter) → Snowside. This custody rests with Ava Labs permanently — BTC.b is a wrapped asset by design, not a candidate for the drivechain peg.
- pECX / ECX ↔ Bitcoin L1 is reserved for the BIP-300 drivechain peg (enforcer 2-way peg). That is a separate track — the long-term trustless exit for pECX/ECX, not for BTC.b.
See the Sidechains registry for the BIP-300 proposals (RISCy, Snowside) advancing through M1/M2.
Front-End Integration Guide
Section titled “Front-End Integration Guide”How do front-ends integrate with the pool?
Section titled “How do front-ends integrate with the pool?”The pool is a non-custodial AMM on Snowside. A front-end integrates entirely through the ecashfarm.com API — it never talks to Snowside directly:
- Read configuration from
GET /v1/liquidity/config(chain, tokens, contract addresses, pairs). Always read addresses from here; never hardcode. - Read pool state + stats from the
/v1/liquidity/*endpoints (reserves, ticks, LP balances, NFT positions, TVL, volume, APR). These are read-only. - Build + sign transactions client-side against the Uniswap Router
contracts (
addLiquidity,removeLiquidity,decreaseLiquidity,collect) using the addresses from/config. The user’s browser wallet signs every transaction; no operator keys are involved in the trade path.
See the Liquidity API reference for the full
endpoint list. In preview mode (Snowside Uniswap not yet deployed) the stats /
pools / quote endpoints return deterministic mocks so you can build the full
flow now; they flip to real Snowside reads when mode becomes live.
Which contracts do I integrate against?
Section titled “Which contracts do I integrate against?”Contract addresses are published on the /liquidity page once Snowside deploys
Uniswap. Until then, the UI runs in preview mode with placeholder addresses.
Which ABIs do I need?
Section titled “Which ABIs do I need?”Minimal ABIs are in the eCash Farm source:
packages/web/src/scripts/liquidity/abi.js — covering ERC-20, the Uniswap v2
Router + Pair, and the Uniswap v3 NonfungiblePositionManager + Pool + Quoter.
Is there a REST API for the pool?
Section titled “Is there a REST API for the pool?”Yes. The /v1/liquidity/* endpoints abstract Snowside behind
ecashfarm.com/v1 so front-ends (including 3rd-party partners) never touch
Snowside directly. The server is a read + broadcast relay only (rule 5) — it
holds no funds, no keys, and never signs. See the Liquidity API reference.
The broader ecashfarm.com API worker also serves the Solana ECASH swap tracker and the sidechain-proposal registry, but those are unrelated to the pool.