Skip to content
DOCS
GIWA Sepolia
Docs/INTEGRATION GUIDES/SDK 0.3.4 partner examples
GITHUB EXAMPLES / FULL GUIDE

SDK 0.3.4 partner examples

On this page

The original product-design review (GitHub access may be required) maps SDK coverage and remaining operational gates. These commands retain the local synthetic scope below. Direct FeeVault/LP examples have separate actual SDK 0.3.1 GIWA payment evidence (GitHub access may be required).

These five commands are deterministic SYNTHETIC_OFFLINE examples. They use local installed SDK 0.3.4 APIs, chain 31337 and a bounded in-memory RPC fixture. No API service, network, key, signer, wallet prompt or broadcast is involved. Unset AMMORA_SEND; setting it to 1 makes every command refuse to run.

bash
npm run partner:catalog
npm run partner:onboarding
npm run partner:quote
npm run partner:claims
npm run partner:reconcile -- unknown
npm run partner:reconcile -- finalized
Command Actual SDK boundary shown
partner:catalog Install a locally reviewed V2 entry, select/diagnose an exact route or custody purpose; unsupported combinations remain unsupported
partner:onboarding planOnboarding("C2") returns original-claim-authority review with Ammora allocation 0, no automatic execution and no RPC read
partner:quote Per-asset quote cost display: creator/source eligibility differs from treasury; allocation requires receipt and native gas remains unknown
partner:claims Plan a fixed-beneficiary module custody claim and simulate that exact request against a pinned fixture runtime; unsigned and not a payout proof
partner:reconcile Correlate known plan/sender/calldata/runtime/canonical status; unknown/pending/invalid/orphaned/reverted/observed/finalized never permit automatic resend

The fixture's addresses, runtime hash, review evidence hash and local-fork enum are synthetic inputs required by the SDK types. They do not certify a deployed or fork-tested integration, actual source rights, payer authorization, settled revenue or real finality. Never copy this profile into a wallet or deployment workflow.

Move from the fixture to read-only application integration

Install profiles/drivers in trusted local application code. A remote JSON manifest is not executable and cannot install an SDK entry. createReviewedCatalog accepts only locally constructed entries. Review chain/genesis, factory/registry/module/driver pins, assets, route order/mode, wallet family and supported claim authority. Source-specific connectors/ABIs are imported from @ammora-protocol/sdk/partner-adapters; generic client, catalog, custody and receipt methods belong in @ammora-protocol/sdk/partner.

Use a ProductReadOptions transport with exact chain/genesis, cancellation, finite per-operation reads/timeouts and an account-wide beforeRead budget reservation. The fixture throws on unexpected methods; production transports must not silently retry, switch provider or expose raw provider errors. selected/inspect is never execution approval. Reopen against the current catalog; stale references and unreviewed revisions must fail before trading. Preserve historical references for custody/reconciliation.

quoteReviewedPool(handle, intent) in quote.ts calls the selected pool-rights trade handle's real quote method with that transport and formats SDK quote costs. The CLI itself displays only synthetic costs; it does not fabricate an executable trade plan. Live quotes still require the correct runtime/approval/rights epochs, nonce, source configuration and account capabilities. This helper never signs or submits.

preparePartnerClaim(handle, asset, beneficiary) in claims.ts invokes the custody handle's planClaim and then simulateAction for the same beneficiary request. A plan is not authority: the simulation can reject unauthorized/revoked callers, runtime drift or exhausted budget. No callback from a server listing can replace this local plan.

Keep fee families and payout authority separate

  • The existing FeeVault and LP guide retains its exact own/delegate permission and alternate payout behavior. Upgrading the SDK does not redirect those recipients or change their fee economics.
  • The pool-rights module custody claim here encodes claim(asset) for its beneficiary. It has no arbitrary payout parameter. Do not invent alternate-recipient capability because the ARL manager supports one.
  • C2 source manual claim is a different method, planManualClaim(asset, originalActor). The live source driver's original claim authority and fresh simulation are required. C2 preserves 100% of original rights and does not enable managed 20:80. After a source claim, fresh recovery may be required to credit module surplus to its original payee.
  • D1/C1/C3 split only eligible, attributable newly secured managed revenue. Treasury, principal, refunds, old/unmanaged fees, direct LP claims and donations are excluded. C1/C3 exact-input support does not imply exact-output or arbitrary wallet/Hook support.

Receipt status is not a positive payout attestation

partner:reconcile accepts the seven fixture observation names in the table. An SDK finalized action receipt authenticates execution identity/canonical finality within the transport's evidence. It does not independently prove a positive fee event or recipient balance increase. Every displayed result therefore keeps payoutVerified:false and amountPaid:null, including the finalized fixture. Actual payout verification requires source-specific exact events and receipt-1 / receipt-block token balances, as in the preserved GIWA LP proof (GitHub access may be required).

Production submission additionally requires an atomic durable PartnerSubmissionJournal and a separately reviewed sender. Persist submitted/unknown attempts and their hashes; reconcile before reuse of any nonce. Do not release uncertain reservations by timer or stale RPC. These examples intentionally provide no sender or in-memory substitute for that durable store. SDK guidance always has mayResubmit:false and sanitizes errors.

Source/module deployment, independent approver/guardian, actual role consent, timelock, EIP-7702/account support, audit and partner acceptance remain separate activation gates. No existing C1 automation or public contract is restarted by these examples. See qualification (GitHub access may be required).

Direct contract state examples

partner:graduation-state and partner:pool-state read deployed contracts through SDK0.3.1 and RPC. They are separate from the offline examples above and require a raw deployment manifest with independently reviewed addresses, runtime hashes, start blocks, source/destination versions and source-review/admission fields:

bash
AMMORA_CHAIN_ID=91342 AMMORA_SEND=0 AMMORA_READ_RECEIPT='' \
  npm run partner:graduation-state -- <manifest.json> <sourceCurve>
AMMORA_CHAIN_ID=91342 AMMORA_SEND=0 AMMORA_READ_RECEIPT='' \
  npm run partner:pool-state -- <manifest.json> <partnerPool>

JSON startBlock values may be non-negative decimal strings or safe integers. The parser restores bigint coordinates; SDK dependency hashes, chain and registry bindings are still checked. Do not copy a runtime hash from the same RPC response being verified, manufacture a verified context, or upgrade reference-only into a reviewed external partner.

The GIWA prerequisite record (GitHub access may be required) includes a real, isolated reference-source deployment and its manifest. Its source has public test setters. It qualifies these direct reads and binding/migration interfaces; external-source economics/certification, metadata review and aggregation eligibility remain separate and are not implied by a successful state read.

Was this page helpful?