Plan first, then ask the wallet

Validate the deployment and metadata boundary before showing a transaction to the connected account.

Overview

Start with a repeatable integration boundary

The client setup gives every NFT feature the same reviewed network profile, metadata policy, simulation step, and receipt verification path.

Initialize one client and reuse the same chain and runtime checks across the complete SDK.

Receive a structured plan that the application can explain before it opens the wallet.

Move to another reviewed EVM network by changing the RPC and deployment profile rather than rewriting product logic.

Use this when

Begin here before integrating any write operation or when creating a shared NFT service layer for multiple product teams.

Recommended flowFrom product intent to verified state

01Confirm the beta artifact
02Create a verified client
03Prepare and simulate
04Send and verify

Beta on GIWA Sepolia

NFT workflows are available to selected testers on GIWA Sepolia. Users review, sign, and pay for each transaction.

const nft = await createAmmoraNftFromRpc({
  rpcUrl,
  profiles: [giwaSepoliaNftBetaV2],
  requireRuntimeCodeHashes: true,
});

const metadata = validateNftMetadataUri(metadataUri);
const plan = prepareMintCoreAsset721(nft, {
  collection,
  sender: account,
  to: recipient,
  name,
  uri: metadata.uri,
});

await simulatePlan(nft, plan);
// Show the plan, then let the connected wallet send it.

SDK output is never submitted automatically.

Confirm package availability before integration

The documentation is public, but anonymous npm installation for @ammora-protocol/nft-sdk is not enabled yet. The current testnet evidence is tied to artifact version 0.1.0-preview.0. Do not direct external users to npm or substitute another package version until the public registry lookup succeeds.

Item	Current status	Developer action
Documentation	Public	Use these guides without an account
Public npm package	Pending publication	Do not rely on anonymous npm install yet
Qualified artifact	0.1.0-preview.0	Use only the approved artifact supplied to the test cohort
Product stage	Beta on GIWA Sepolia	Keep the integration testnet-only

Beta and package version are separate

Beta describes the current product program. 0.1.0-preview.0 is the immutable SDK artifact identity recorded in the existing qualification evidence. A future public npm release must publish an explicit version and update this documentation together.

Package entrypoints

The root entrypoint re-exports the stable surfaces for convenience. Feature entrypoints make an application's dependency boundary clearer and keep experimental APIs visibly separate.

Entrypoint	Primary exports
@ammora-protocol/nft-sdk	Client context, profiles, plans, capabilities, metadata validation, and stable re-exports
@ammora-protocol/nft-sdk/core	ERC-721, ERC-1155, Core Asset V2, logical collections, and creation plans
@ammora-protocol/nft-sdk/mint	Mint Campaign V1 and V2 inventory, phase, policy, mint, and settlement helpers
@ammora-protocol/nft-sdk/assets	Direct RPC reads, indexed provider interface, searches, metadata, and image verification
@ammora-protocol/nft-sdk/plugins	Creators, attributes, autographs, and external plugins
@ammora-protocol/nft-sdk/groups	Taxonomy groups and membership
@ammora-protocol/nft-sdk/experimental	Asset accounts, agents, and Execute Freeze research APIs
@ammora-protocol/nft-sdk/experimental/storage	Optional upload adapters and metadata construction research APIs
@ammora-protocol/nft-sdk/experimental/rules	Reserved rules entrypoint; currently planned and not usable

Use a reviewed chain profile

A caller may change the RPC URL, but the returned chain ID must match a reviewed profile with deployed addresses and runtime code hashes. Never reuse GIWA addresses on another EVM network.

Confirm chain ID 91342 for GIWA Sepolia
Require runtime code hashes before enabling writes
Show the expected sender, target, value, and warnings
Register a separate reviewed profile for every additional EVM chain

Bring a published metadata URI

The stable SDK begins after the metadata has been uploaded. Ammora validates the supplied URI and can inspect the referenced metadata and image, but it does not host or pay for storage.

Ammora validates	Your application owns
Supported URI scheme and bounded input length	Storage provider selection and billing
Optional JSON shape and safe image reference	Uploading, pinning, retention, and availability
Optional SHA-256 for metadata and image	Gateway or CDN policy for displayed media
Absolute URI for each Core Asset V2 item	Supplying the final public metadata URI

Supported schemes: ipfs://, ar://, and public https://
Bounded data:application/json is available where the API explicitly allows it
Use immutable storage when the NFT content should not change

Verification is point-in-time evidence

A content hash proves which bytes were checked. It does not guarantee that a storage provider will keep serving them.

Keep execution explicit

The application owns the final wallet interaction. Persist the transaction hash and the SDK and deployment profile versions so failed tester sessions can be diagnosed later.

1
Review
Display every call, approval, warning, and expected event.
2
Simulate
Use the connected address and current chain state.
3
Send
Pass the approved plan to the user's wallet provider.
4
Resolve
Decode the receipt before planning a dependent action.

Understand the plan before sending it

Every TransactionPlanV2 is immutable and contains enough information for a wallet application to explain the operation. Its ID is derived from chain ID and call content, so rebuilding with different calldata produces a different plan ID.

Plan field	Use in the application
calls	Display sender, target, value, calldata purpose, and ordering
approvals	Request token approval before the dependent call when present
typedSignatures	Collect typed data only for the stated purpose
expectedEvents	Verify the successful receipt changed the intended state
feeQuote	Show native value and any action fee separately from gas
warnings	Surface irreversible or preview-specific consequences
validUntil	Rebuild expired plans instead of submitting stale calldata

Was this page helpful?