🏎️Deploy

The deploy route prepares an unsigned versioned transaction to deploy a new SPL token along with its associated metadata and bonding curve initialization. It combines several steps—fetching ephemeral signing keys and metadata URIs, building token creation instructions via Umi builders, and initializing the bonding curve via Anchor—into a single transaction that anyone can sign.

How It Works

1. Tip Transfer: The route adds a jio tip instruction to send a small amount of lamports for faster transaction landing. This is similar to the swap route.

2. Umi Setup & External API Calls:

   • A Umi instance is created and configured with the mpl-token-metadata and wallet adapter identity plugins.

   • Two external API calls are made concurrently:

     • Vanity/Pop: Returns an ephemeral keypair (for token minting) so that the server does not use a persistent key.

     • Pin-Body: Uploads metadata (name, image, description, and custom attributes like textModel and generationId) and returns a metadata URI.

3. Building Token Instructions (Branch A): Using Umi builders, the route:

• Creates a fungible token with the provided name, symbol, and metadata URI.

• Ensures that an associated token account (ATA) exists for the token.

• Mints a fixed supply of tokens.

• Removes the mint authority, freeze authority, and update authority so that the token is fully decentralized post-deployment.

• Converts the Umi instructions to Web3.js TransactionInstructions.

1. Bonding Curve Initialization (Branch B): In parallel, the route builds an Anchor instruction to initialize the bonding curve for the token. This instruction sets up the pairing between the token and wrapped SOL (WSOL) so that further actions can be performed.

• Combining & Signing: The instructions from both branches (plus the tip transfer) are combined into a single list. A versioned transaction is then built from these instructions. Before returning the transaction, it is signed with the ephemeral key (generated from the vanity API call).

• Response: The final output is a base64-encoded unsigned transaction along with the token mint’s public key. Clients can then sign this transaction using their wallet and submit it to the blockchain.

Example Request:

curl -X POST https://api.aiis.dev/v2/deploy \
-H "Content-Type: application/json" \
-d '{
  "name": "MyToken",
  "symbol": "MTK",
  "supply": "1000000",
  "description": "A test token for deployment.",
  "imageUri": "https://aiisdev.mypinata.cloud/ipfs/QmZRW9zbDnoQawwr8UxFDuduG43N7p4iQn3jpHKNBBZ5yf",
  "textModel": "GPT4",
  "generationId": "cm7mfh3cs000zn20frerj7ahe",
  "walletPublicKey": "YourWalletPublicKeyHere"
}'

Example Response:

{
  "transaction": "BASE64_ENCODED_TRANSACTION_STRING",
  "mint": "NewTokenMintPublicKey"
}

How It Works on the Client

1. Send Request: The client sends the above payload to the deploy endpoint.

2. Receive Transaction & Mint: The server responds with a base64-encoded unsigned transaction and the token mint’s public key.

3. Sign and Submit: The client deserializes the transaction, signs it using their wallet, and then submits the signed transaction to the blockchain (for example, via a bundler like Jito).