Integrate your stablecoin with Ammora

A practical starting point for stablecoin issuers, treasury operators and engineering teams. Keep your existing ERC20 token, connect a reviewed pair to an Ammora pool, and build a workflow for liquidity, swaps, fee collection and withdrawal.

This guide targets SDK 0.3.8 and GIWA Sepolia (91342). Start with one pair and a small testnet position. The executable path below uses the explicitly selected giwa-almm-unified-v1 example profile. It does not migrate existing Uniswap positions or change your issuance and redemption system.

1. Decide what your team will integrate

Ammora provides the pool and integration tooling. Liquidity comes from your treasury or participating LPs; it is not automatically supplied by installing the SDK. Token minting, reserves, fiat redemption, bridging and issuer permissions remain with your company. You may keep other DEX markets while creating a separate Ammora position.

2. Prepare the onboarding information

Choose an engineering contact, a treasury operator and the person who can confirm token controls. Assemble these inputs before connecting a signing wallet.

Use your own addresses and approvals. Example tokens and wallets are not issuer credentials. Both assets must pass the selected profile's checks; an asset name or symbol does not establish official GIWA deployment. The example scope is reviewed, exact-transfer ERC20 assets. See the asset review requirements for supported proxy and control interfaces.

3. Install the SDK and open the working code

In your own application, use Node 24:

npm install --save-exact @ammora-protocol/sdk@0.3.8 viem

The SDK brings its Math dependency. For an initial package/import check, follow the SDK quickstart.

For this unified ALMM walkthrough, also use the reviewed example modules below. The fee compatibility module is source code provided with the examples, not a new npm SDK export. Keep its shared imports and profile together.

Everything is readable in Docs without GitHub login. To run the CLI, follow local example setup to prepare all source files and install their dependencies. Installing the SDK alone does not create the example project's commands.

4. Get your first unsigned policy result

You can verify the manifest-checking workflow before your foundation supplies token addresses or a signing wallet. From the prepared example project, run:

npm run --silent stablecoin:inspect -- src/stablecoin/manifests/native-issuer.template.json

Expected status fields:

{
  "classification": "BLOCKED",
  "rpc": false,
  "signing": false
}

The actual output also lists missing issuer provenance, token addresses, decimals, code/proxy reviews, LP owner and payout. This is a successful check of an unfinished template. It tells the engineering and treasury teams what they must supply; it does not indicate a failed installation. Keep the template pending until those inputs have been reviewed.

To move to live policy reads, create and review your partner manifest using step 3 of the complete walkthrough. It starts from the native issuer template, selects model: "almm", removes the old deployment field and records your assets, roles and budget.

Do not mark unresolved fields as reviewed to make a command run. Set the lower-address token as base, then review decimals, raw budgets and quote-per-base price in that order. Use the actual LP owner as AMMORA_ACCOUNT for this first read.

From the prepared example project:

export AMMORA_CHAIN_ID=91342
export AMMORA_GIWA_GENERATION=auto-route
export AMMORA_RPC_URL=https://sepolia-rpc.giwa.io
export AMMORA_RPC_INTERVAL_MS=600
export AMMORA_READ_RECEIPT=''
export AMMORA_SEND=0
export AMMORA_ACCOUNT=REPLACE_WITH_YOUR_LP_ADDRESS

mkdir -p .validation/issuer-onboarding
# Save the reviewed manifest at .validation/issuer-onboarding/partner.json
printf '{}\n' > .validation/issuer-onboarding/policy.request.json

npx --no-install tsx extensions/almm-unified/plan.ts \
  policy \
  .validation/issuer-onboarding/partner.json \
  .validation/issuer-onboarding/policy.request.json \
  .validation/issuer-onboarding/policy.plan.json

Success means the result identifies the selected Factory/Registry binding and reports both assets' policies. It is an unsigned read result; do not submit it as a transaction. If an output file already exists, inspect it and use a new filename for a new observation. The planner intentionally refuses to overwrite evidence.

If a token is already supported, continue. An unclassified asset without an owner-configured policy may use the reviewed small round-trip registration flow. A blocked or owner-defined policy requires resolution; it is not a reason to force registration. Use the registration procedure.

5. Complete one liquidity lifecycle

Follow the complete command walkthrough for request JSON, amounts and execution. Use the same unified profile throughout. Default-catalog ARL/ALMM examples have different deployment and fee conditions and should not be mixed into this sequence.

If discovery returns summary.route: "existing-pool", its creation preflight may report ready: false with DLMM canonical pool key already exists. This blocks duplicate creation, not use of the confirmed pool. Continue with summary.preflight.existingPool after reviewing its pair and fees. Do not send the diagnostic summary.preflight.transaction; only the top-level transactions list contains actions for the selected plan. An existing-pool discovery plan has no transactions to submit.

A 1 bin-step or a historical low-fee example is not a promise about every pool's fee. Read the actual pool/profile economics and compare them with your approved cap. Review fresh price evidence for new exposure and never treat a pool's own spot price as proof of its peg.

Keep one plan under review at a time for each signing wallet. Approval receipts change state: replan the dependent operation afterward. For an unknown transaction result, reconcile its hash, nonce and receipt before sending anything again.

6. Build the issuer's application

Start with four screens. Each should use the same reviewed profile and manifest.

The CLI entry files use Node facilities and are implementation references. In a browser app, keep manifest review and data preparation in suitable application/server code, and use the connected wallet for signing the reviewed unsigned to, data and value. Do not copy CLI private-key handling into client code. Managed wallets need an executor reviewed for their actual signing model.

Do not expose a claim button merely because the wallet is an issuer admin or the payout address. Inspect the position's real fee authority. Show pending, confirmed and reconciled states separately; a submitted hash is not a received payment.

7. Understand the money flow

A swap pays the trading fee configured by the selected pool. Its actual policy allocates LP and protocol shares. The LP's accrued share is inspected and claimed through the applicable fee path; the claim goes to the reviewed payout address. A delegate executes permitted claims and does not gain the right to withdraw LP principal.

Keep supplied capital, withdrawn capital and earned fees in separate accounting fields. Token balances alone do not identify which flow produced the funds. A zero feePreview or no-op plan is not revenue. This guide does not assign a fixed yield, commercial revenue share or automatic referral payment to the issuer.

8. Decide when the pilot is ready

A useful pilot report contains:

• The reviewed chain, pair, manifest and deployment/profile revision.
• One completed position lifecycle with receipts and actual amounts supplied and returned.
• A swap in each required direction, with the quoted constraints and actual received amounts.
• A fee claim with feeOwner/delegate authorization and reconciled payout amounts.
• A tested withdrawal path and, when delegation is used, grant/revoke results.
• A transaction journal, reconciliation handling and the operator responsible for pause or upgrade changes.

Keep local build/type results separate from live-chain results. Another team's testnet receipt does not validate your assets or wallets. Production/mainnet readiness requires a separately reviewed deployment and operating scope; this page establishes the GIWA Sepolia integration path.

9. Give this guide to your coding assistant

Read or copy the Markdown version together with the complete walkthrough.

Build a stablecoin issuer integration for GIWA Sepolia 91342.
Read https://docs.ammora.org/ai/stablecoin-team-integration.md and
https://docs.ammora.org/ai/stablecoin-quickstart.md first.
Use SDK 0.3.8 and the giwa-almm-unified-v1 example profile with its
source-pinned fee compatibility module. Inspect all related files in
https://docs.ammora.org/examples before implementing calls.
Start with reviewed asset inputs, policy reads and unsigned operation plans.
Build asset setup, liquidity, swaps, revenue and receipt-history screens.
Separate LP principal, fee ownership, delegated claims and payout recipients.
Use the connected wallet to sign reviewed transactions; never put CLI keys
in browser code. Do not invent addresses, prices, budgets or SDK exports.
Keep the Docs navigation and component styles. Report local validation and
actual chain receipts separately, and reconcile uncertain sends before retrying.

For alternative models, read liquidity path selection. For the full overview, return to stablecoin liquidity integration.