Contract feature examples — published SDK 0.3.8

This is an audit of contract operations, not an HTTP API integration guide. Each command below has its own TypeScript file with an explicit published SDK call, like the Meteora operation-file pattern. Shared helpers handle transport and signing. The operation files default to read-only previews. Explicitly authorized GIWA-only qualification deployments and receipts are recorded separately from source compilation; these test instances do not change the published SDK deployment catalog.

Current public package checks are recorded in the 0.3.7 release report (GitHub access may be required). The versioned GIWA transaction records below keep their original SDK scope and are reused.

Select an operation

For an issuer deploying its own native GIWA stablecoin, use the separate stablecoin partner flow and 18 operation commands. This consumes the issuer's existing ERC-20 through independent ARL/ALMM pools. It does not mint an issuer asset through Launch/Graduation. Planning is always unsigned; the separate execute command binds the review hash, durable journal, current policy and receipt proof. Unresolved FDUSD/cUSD profiles remain blocked; synthetic qualification is not official issuer support.

Install with npm ci. Select the reviewed GIWA generation and an actual caller:

export AMMORA_CHAIN_ID=91342
export AMMORA_GIWA_GENERATION=auto-route
export AMMORA_ACCOUNT=0xYOUR_OWN_ADDRESS
export AMMORA_SEND=0
npm run quickstart:verify
npm run arl:remove-position-liquidity -- <pool> <managerNftId> <liquidityRaw>
npm run dfs:claim -- <vault> <recipientIndex> [payoutAddress]

Replace placeholders. Amounts ending in Raw, shares and liquidity are integers in contract units, not human token amounts. AMMORA_ACCOUNT is the transaction caller; it must match the signing wallet in send mode. The new action files default to UNSIGNED_PREVIEW: RPC reads/planning, no key, approval or submission. Existing action files retain their documented send gates. An unsigned plan is not proof of authority, positive claimable fees, a successful transaction or a received payment.

For an intentional transaction, review calldata, amounts, destination and permissions, then set AMMORA_SEND=1 using your own wallet setup. The existing transport simulates the exact call and checks nonce/receipt/canonical block; it never automatically resends an unknown hash. Confirmed execution still reports payoutVerified: false: establish actual payment with events and receiver balances at the receipt block, accounting for all same-block transfers. A zero-fee call does not count as payment.

Deployment and authority boundaries

• ALMM/ARL use the explicit reviewed deployment source and factory provenance checks. ARL manager NFT IDs and raw compounding-pool IDs are different namespaces. Locked principal stays locked; an SDK liquidity plan does not grant withdrawal rights.
• ALMM position-delegate accepts revoke, add, remove or remove-to-owner. These can grant principal rights. They are not the ARL fee-only claim-fee / claim-fee-to-owner bits. The existing ARL delegation and alternate-payout examples remain the route for fee-only delegation.
• DFS verifies the vault against the selected reviewed factory. claim requires the connected caller to be the indexed recipient; its optional payout address does not change entitlement. Recipient-fee tokens have unknown net output until receipt. fund-fee-vault refuses incomplete setup; delegated-funding preflight prints owner setup requirements and never sends those permission changes. create creates a new vault with two explicit, distinct recipients; it does not edit existing ones. A DFS vault accounts for one fixed token. Match the source fee asset to that token; routing both assets of a two-token pool to a WETH-only vault can strand base-token debt. A successful WETH funding/claim does not prove that other-token debt is collectible. Use token-specific or quote-only routing where supported.
• Yield/genesis vault, staking, Merkle and presale files use AMMORA_FEATURE_CONTRACT or the first positional address, plus AMMORA_FEATURE_RUNTIME_HASH. Obtain that keccak256 pin from an independently reviewed deployment artifact. Do not derive the expected hash from the RPC response you are checking. A matching runtime is only a code identity check, not factory provenance, economic suitability, proxy implementation approval or proof that a product is deployed on GIWA. For a proxy, independently review its implementation/upgrade authority before use. These raw SDK builders do not perform a complete product preflight; the send path simulates phase/ownership/lock conditions. Staking/presale funding reads the actual stake/ quote token and plans exact approvals; no unlimited approval is requested.
• V5/partner/portable read examples require deployment-team-reviewed raw manifests. The SDK verifies dependency pins and on-chain provenance. JSON is never treated as a pre-verified planning context. There is no invented built-in V5 profile, no trustPoolAddress bypass and no promotion to aggregation eligibility. JSON startBlock coordinates may be non-negative decimal strings or safe integers; the example converts only those coordinates to bigint, then leaves runtime, registry binding, chain and source-review validation to the installed SDK 0.3.7. A reference-only test source stays reference-only after parsing.
• New creator surplus/leftover/partner creation-fee calls use the V4 client's caller, factory, policy and lifecycle checks. Recovery eligibility differs before/after Graduation; these operations are separate from ordinary FeeVault trading fees.

Added operation files

Prefix each command with npm run and append -- before its inputs. READ_ONLY_RPC never sends; PREVIEW / explicit send uses the gate above. An unsupported deployment, missing pin, wrong caller, lock or contract phase is a refusal, not an invitation to substitute a different address.

Atomic Config, launch and first buy

SDK 0.3.7 includes the reviewed GIWA helper and runtime pins. The convenience example calls createConfigAndPoolWithFirstBuy with the team policy and no deployment/targets JSON. Follow the integrated guide for approval and execution. Public-package validation (GitHub access may be required) distinguishes the new read-only CLI check from reused actual atomic transaction and payout evidence.

Audit scope and remaining specialized surfaces

The audit reads the installed npm 0.3.7 declarations and implementation, rather than an unpublished SDK source branch. It inventories 23 non-API client classes and 472 exported build* symbols. These are not 495 distinct user tasks: many are ABI encoders, legacy generation variants, low-level alternatives to authenticated planners, or operator/governance methods. npm run audit:contracts emits every method and builder with its actual explicit call sites to .validation/contract-surface.json. Empty call-site lists remain visible; this is not a claim that every export has a standalone CLI or a new testnet transaction.

Current validation classification

The public SDK 0.3.7 validation (GitHub access may be required) is the package reference. The public034 audit (GitHub access may be required) preserves a historical subset: 58 REUSED operation paths / 0 unresolved blockers in that subset, with its original 147 TypeScript files and 121 commands. It preserves original execution versions and excludes API integration. The special surfaces above still retain their deployment/authority limits; zero historical blockers does not claim live coverage of every SDK method or low-level encoder.

Historical sequence (superseded counts, preserved failures)

The initial addition was qualified by package integrity, strict typechecking, registered-file/import checks and offline regressions. The subsequent 2026-10-25 GIWA matrix (GitHub access may be required) tests the 58 files from a fresh public SDK 0.3.1 installation: 29 PASSED_THIS_RUN / 29 BLOCKED. It records 58 successful transactions including setup/approvals/cleanup, plus read-only and refusal proofs. This does not mean all 58 features have executable GIWA targets.

The 29-blocker follow-up (GitHub access may be required) adds actual Token Lock and managed reward payments. That historical classification was: 2 PASSED_THIS_RUN / 29 REUSED / 27 BLOCKED. It separates reviewed deployment references, real authority, positive funding and lifecycle prerequisites for every remaining row. The reward slot persists and its bounded program/residual balance are recorded; this is not a fully reclaimed reward-program claim.

The live test fixes V5 JSON block parsing, the omitted RevenueCenter creator view, stable snapshot code-pin reads and explicit leftover payout display. Installed SDK artifacts are unchanged. Full ALMM/compounding removals automatically burn their positions; a separate close needs a still-live empty NFT. The dedicated close test uses another newly created empty position. No strategy profit or unreviewed target is inferred from cash-vault withdrawal or an unsigned plan.

The existing SDK 0.3.1 fee/LP proof (GitHub access may be required) and its original receipts remain REUSED for their original fee/LP paths. At that historical stage, all 94 pre-existing source/lock inputs matched their retained hashes. Original claims, fee-only delegation and nonce/receipt helpers are reused within that scope. The current dependency lock pins public037; the final audit records the exact unchanged claim closure and scoped env/swap differences. New operations keep their own hashes.

Reuse is invalidated by changes to a qualified claim/delegation path, artifact, beneficiary/payout, authority, chain/generation or exact-block receipt evidence. A changed balance today does not retroactively invalidate a canonical historical receipt; a new claim must obtain its own evidence. See the accompanying implementation validation record (GitHub access may be required).

Historical SDK 0.3.4 launchpad completion

The unified guide adds launch:author-config, launch:config-json, launch:migrate, launch:config-enabled, launch:creator-metadata, arl:create-position and arl:vest-position. These seven commands and two supporting TypeScript modules are qualified in the full GIWA report (GitHub access may be required). Historical rows above retain their original SDK/deployment/evidence scope.

Initial optional-action qualification (historical SDK 0.3.4)

The optional examples close the 18 method-level source gaps from the builder handbook with 13 focused commands. The initial qualification report (GitHub access may be required) preserves its unsigned reads, expected refusals, then-existing uint40 issue and helper prerequisites. The uint40 fix shipped in 0.3.6 and the default GIWA first-buy helper in 0.3.7; follow the public release (GitHub access may be required) and current optional usage. Historical live payment proofs remain unchanged; source coverage is not a fresh transaction PASS.

Fee sharing setup (public SDK 0.3.7)

Recipient/ratio setup and role-based claims connects launch:fee-config (preview/document → existing Config creation), before/after-Graduation distribution, and dfs:create-json (2–5 recipients, relative weights, reviewed exact calldata). Existing Creator/Partner/LP/delegate/DFS claim paths retain their historical GIWA validation scope. See changed-boundary validation (GitHub access may be required); no SDK publication or GitHub CI.

FeeVault, DFS sources and sequential LP batches

FeeVault delegation and batch claims, DFS source setup and funding, and ALMM rebalance cover the new explicit SDK 0.3.7 calls. FeeVault batchClaim is owner/operator-only; the ordinary wallet example uses separate claimFor transactions. Source previews and zero-credit receipts are not positive payment proof.

The 2026-10-28 FeeVault/DFS/batch/ALMM GIWA report (GitHub access may be required) covers payments, rebalancing, permission denials, new-LP exits, and remaining reward/rounding state.