Stellar testnet bridge

Tokens

The issued-asset id is nep141:stellar-<last 20 bytes of keccak256(the asset's 32-byte Stellar Asset Contract id)>.tp-omft.testnet, the same shape of rule 1Click uses for sol- and EVM ids. USDC and USDT share one issuer, so the hash covers the asset code too. These are Tidepool's own classic assets, not Circle or Tether tokens.

Deposit model: MEMO, not per-quote addresses

Stellar has no cheap per-quote deposit accounts, and 1Click itself requires depositMode: "MEMO" for Stellar. Tidepool does the same: every Stellar-origin quote shares the one treasury depositAddress and gets a unique numeric depositMemo. You pay the treasury with that memo on the transaction (MEMO_TEXT or MEMO_ID, the digits of depositMemo) and the relayer matches the payment to your swap by memo. Consequences:

• Quotes with a Stellar originAsset and depositType: "ORIGIN_CHAIN" must send depositMode: "MEMO" (otherwise 400), and ANY_INPUT is not allowed.
• GET /v0/status takes depositAddress and depositMemo; POST /v0/deposit/submit takes txHash, depositAddress and memo. Submitting is optional: the relayer watches the treasury and detects the payment anyway.
• A payment with the wrong asset, or with no memo or an unknown memo, is not credited and stays in the treasury (it is not auto-refunded). Always set the memo.
• There is no sweep: deposits already land in the treasury, so the NEP-141 is minted and credited to the verifier as soon as the payment is seen on Horizon.

The XLM cap (100 XLM)

Any swap with an XLM leg is rejected at quote time with a 400 if the XLM amount (input or output) exceeds 100 XLM (1,000,000,000 stroops). It covers XLM swaps, payouts and refunds. Why: Friendbot hands out 10,000 XLM per request, so a small cap keeps one user from draining the treasury. Also:

• A payout of XLM to an account that does not exist yet must be at least 1 XLM (it creates the account with createAccount).
• Payout and refund destinations are checked at quote time: the account must exist, and for USDC or USDT it must already trust the asset (a changeTrust operation). Otherwise the quote is rejected with a 400 that names the problem.
• ANY_INPUT quotes that pay out XLM to a Stellar address are rejected.
• USDC and USDT legs are not capped.
• Recipients and refundTo must be plain G... public keys (no muxed M... addresses, no contract C... addresses).

1. Get tokens

XLM: Friendbot gives 10,000 test XLM (the faucet never drips native XLM). USDC and USDT: add a trustline for each (codes USDC and USDT, issuer GDXABUSRHP4YA5CELHLNJQ4M3TX2BSJ6PEMDFCG2RA4PQLAQLRMFFQAN), then use the faucet (also in the dropdown on the Faucet page). It sends 100 of each. To get the bridged USDC, USDT and 5 test XLM into your NEAR intents balance instead, use {"accountId":"alice.testnet","mode":"intents","assets":["stellar"]}; that test XLM lives only inside the verifier.

curl -X POST https://www.usetidepool.tech/v0/faucet -H 'content-type: application/json' \
  -d '{"chain":"stellar","address":"GYourStellarAddress"}'

2. Stellar → NEAR

const quote = await OneClickService.getQuote({
  dry: false, swapType: 'EXACT_INPUT', slippageTolerance: 100,
  originAsset: 'nep141:stellar.tp-omft.testnet',
  destinationAsset: 'nep141:usdc.tidepool-sandbox.testnet',
  amount: '50000000',                       // 5 XLM in stroops
  depositType: 'ORIGIN_CHAIN', depositMode: 'MEMO',
  refundTo: 'GYourStellarAddress', refundType: 'ORIGIN_CHAIN',
  recipient: 'you.testnet', recipientType: 'DESTINATION_CHAIN',
  deadline: new Date(Date.now() + 30 * 60_000).toISOString(),
});
const { depositAddress, depositMemo } = quote.quote;
// Pay depositAddress (a G... address) with Operation.payment (asset: XLM, or the issued asset) and Memo.text(depositMemo).
await OneClickService.submitDepositTx({ txHash: '<stellar tx hash>', depositAddress, memo: depositMemo });
// Poll with both: GET /v0/status?depositAddress=...&depositMemo=...

Runnable: RECIPIENT=you.testnet npm run stellar-deposit in tidepool-examples (it creates and Friendbot-funds a throwaway key unless you set STELLAR_SECRET).

Full quote request and response

The request below sets every required field (plus depositMode: "MEMO" where this route needs it). It is a dry quote, so nothing is created. The response is the real, complete body from the live deployment on 2026-10-30; prices move, so your amounts will differ. Optional fields such as appFees or referral are in Swap types.

curl -X POST https://www.usetidepool.tech/v0/quote -H 'content-type: application/json' -d '{
  "dry": true,
  "swapType": "EXACT_INPUT",
  "slippageTolerance": 100,
  "originAsset": "nep141:stellar.tp-omft.testnet",
  "depositType": "ORIGIN_CHAIN",
  "destinationAsset": "nep141:usdc.tidepool-sandbox.testnet",
  "amount": "50000000",
  "refundTo": "GDXABUSRHP4YA5CELHLNJQ4M3TX2BSJ6PEMDFCG2RA4PQLAQLRMFFQAN",
  "refundType": "ORIGIN_CHAIN",
  "recipient": "user.testnet",
  "recipientType": "DESTINATION_CHAIN",
  "deadline": "2030-01-01T00:00:00.000Z",
  "depositMode": "MEMO"
}'

{
  "correlationId": "aa0c43a1-0f60-4d9d-88f2-4647365e177d",
  "timestamp": "2026-10-30T16:28:50.432Z",
  "quoteRequest": {
    "dry": true,
    "swapType": "EXACT_INPUT",
    "slippageTolerance": 100,
    "originAsset": "nep141:stellar.tp-omft.testnet",
    "depositType": "ORIGIN_CHAIN",
    "destinationAsset": "nep141:usdc.tidepool-sandbox.testnet",
    "amount": "50000000",
    "refundTo": "GDXABUSRHP4YA5CELHLNJQ4M3TX2BSJ6PEMDFCG2RA4PQLAQLRMFFQAN",
    "refundType": "ORIGIN_CHAIN",
    "recipient": "user.testnet",
    "recipientType": "DESTINATION_CHAIN",
    "deadline": "2030-01-01T00:00:00.000Z",
    "depositMode": "MEMO"
  },
  "quote": {
    "amountIn": "50000000",
    "amountInFormatted": "5",
    "amountInUsd": "0.8503",
    "minAmountIn": "50000000",
    "amountOut": "846688",
    "amountOutFormatted": "0.846688",
    "amountOutUsd": "0.8465",
    "minAmountOut": "838221",
    "timeEstimate": 60
  },
  "signature": "ed25519:3GSSTxmugek3CjxgU72ZMdU65ioYcbLkdRCD9gWDiWXQYd3C64YNaft7vCyyYLuPWnS2dRRaXWpMUvtgMQHzGA1S"
}

With "dry": false and a deadline between a minute and a day ahead, the quote also carries depositAddress, deadline and timeWhenInactive and depositMemo (the memo or destination tag you must attach to the deposit). See Quotes and pricing and the status response for what comes back after the deposit.

3. NEAR → Stellar

Quote with a Stellar destinationAsset, recipient: 'GYourStellarAddress' and recipientType: 'DESTINATION_CHAIN', then deposit on NEAR as usual. The verifier ft_withdraws the bridged token to the relayer, which pays out on Stellar from the treasury (payment, or createAccount for XLM to a new account). Payouts are signed first and the signed transaction (with a deterministic hash and a 3 minute time window) is recorded before it is sent, so a crash or retry never pays twice: the hash is looked up on Horizon first and a new transaction is only signed after the window has provably expired.

Refunds

Same reasons as every route (DEADLINE_PASSED, PARTIAL_DEPOSIT, …). A refund with refundType: "ORIGIN_CHAIN" is paid from the treasury to refundTo on Stellar in the asset you sent.

Limits

• Testnet resets. Stellar testnet is reset periodically (about quarterly). After a reset the accounts, assets and balances are gone and the route has to be bootstrapped again.
• Reserves. A new Stellar account needs 1 XLM of base reserve, plus 0.5 XLM per trustline.
• One transaction at a time. The treasury is a single account with one sequence number, so payouts are serialized.
• Treasury XLM. The server tops the treasury up from Friendbot (through a temporary account that is merged back) when it drops below 1,500 XLM. If XLM is critically short, XLM payout quotes answer 503.
• Unreachable destinations. If a payout keeps failing on-chain (for example the recipient removed its trustline after the quote), the swap stays in PROCESSING with a note and needs operator attention.
• Horizon. The relayer uses the public testnet Horizon; congestion or rate limits can delay a swap.

Mapping to mainnet 1Click

Same request and response fields, blockchain: "stellar", depositMode: "MEMO" and a numeric depositMemo. One real difference: on mainnet 1Click lists Stellar assets as nep245: ids from the HOT bridge, with 7 decimals, while Tidepool lists them as nep141: OMFT-style ids (above). When you switch the base URL, take the Stellar asset ids from GET /v0/tokens of the environment you are calling. Mainnet has no 100 XLM cap and uses real Stellar addresses.

Verified flows

These ran end to end on the live Tidepool testnet against Stellar testnet (real Stellar transactions, real NEAR testnet settlement) on 2026-10-29:

• XLM → NEAR USDC (5 XLM, MEMO deposit): Stellar deposit tx, NEAR settlement tx.
• NEAR USDC → XLM payout (5 USDC): NEAR deposit tx, NEAR settlement tx, Stellar payout tx.
• NEAR USDC → Stellar USDC payout (5 USDC, recipient with a trustline): NEAR deposit tx, NEAR settlement tx, Stellar payout tx.
• PARTIAL_DEPOSIT refund (quoted 10 XLM, sent 4 XLM): Stellar deposit tx, NEAR refund tx, Stellar refund tx. Final status REFUNDED.
• Over the cap: a 100.0000001 XLM quote is rejected with 400 ("XLM is capped at 100 XLM ... per swap"), and so is a quote that would pay out more than 100 XLM, before any deposit memo is issued.