Zynk
Getting StartedProduct GuidesAPI ReferenceFAQ'sRecipes
Getting StartedProduct GuidesAPI ReferenceFAQ'sRecipes
  1. Continuum - Wallet Infrastructure
  • Transformer - Cross Border Transfer
    • Overview
    • Customers & Identity
      • Entities/Customers
      • About KYC/KYB
      • RFI Scenarios for Customers
      • Identity Rejection Reasons
    • Accounts & Wallets
      • External Accounts(To be deprecated soon)
      • Fetch Requirements for External Accounts V2
      • External Accounts V2
      • Funding Accounts
      • About Plaid Integration
    • Transfers
      • Counterparty Risk details
      • Addition transfer requirements
      • Transfer in Action
      • Limits and Minimums
      • Fee details
    • Miscellaneous
      • Bank Codes
      • Supported chains and currencies
      • Partner payments signature generation
      • Reserves requirements
      • Partner Payments
      • Status updates - Webhooks
  • Transporter - Automated Liquidity Manager
    • Overview
    • Visibility Protocol
    • Instant liquidity process - How it works
    • Status updates - Webhooks
  • Teleport - Pay-In Accounts
    • Overview
    • About Teleport routes
  • Warp - Pay-Outs
    • Overview
  • Continuum - Wallet Infrastructure
    • Overview
    • Authentication
    • Continuum APIs
    • Transactions on Continuum
    • Details on generating signatures
Getting StartedProduct GuidesAPI ReferenceFAQ'sRecipes
Getting StartedProduct GuidesAPI ReferenceFAQ'sRecipes
  1. Continuum - Wallet Infrastructure

Transactions on Continuum

All transactions from Continnum wallets have to be done using Transformer, Teleport or Warp. This ensures that all transactions are compliant to our internal guidelines.
We will utilise our existing Simulate and Transfer flow from Transformer to enable transaction from Continuum wallets.
In Simulate, when both jurisidctions are blockchain jursidictions, then transaction is adjusted to be a part of the Continuum flow. This requires:
Transaction simulation to generate an unsigned blockchain transaction
User signing of the transaction payload using passkey
Execution by submitting the signed transaction
Request Body:

{
  transactionId: string;       // Required. Unique transaction identifier
  fromEntityId: string;        // Required. Source entity ID
  fromAccountId: string;       // Required. Source account ID (must be NON_CUSTODIAL_WALLET type)
  toEntityId: string;          // Required. Destination entity ID
  toAccountId: string;         // Required. Destination account ID (blockchain account)
  exactAmountIn?: number;      // Required if exactAmountOut not provided. Amount to send
  exactAmountOut?: number;     // Required if exactAmountIn not provided. Amount to receive
}
Response - Continuum Transaction:
{
  executionId: string; // Execution ID (starts with "cexec-" prefix for crypto)
  quote: {
    inAmount: {
      amount: number; // Input amount
      currency: string; // Input currency (e.g., "USDC")
    }
    outAmount: {
      amount: number; // Output amount
      currency: string; // Output currency
    }
    exchangeRate: {
      rate: number; // Exchange rate (1 for direct transfers)
      conversion: string; // Human-readable conversion string
    }
    fees: {
      partnerFees: {
        amount: number; // Partner fee amount
        currency: string; // Fee currency
      }
      zynkFees: {
        amount: number; // Zynk platform fee
        currency: string; // Fee currency
      }
      totalFees: {
        amount: number; // Total fees
        currency: string; // Fee currency
      }
    }
  }
  payloadToSign: string; // ⭐ NEW: Unsigned transaction payload to be signed
  validUntil: string; // ISO 8601 timestamp when quote expires
  message: string; // Status message
}
Key Differences from Fiat Simulate:
Includes payloadToSign field containing the unsigned blockchain transaction
Execution ID starts with cexec- prefix instead of regular format
No deposit account information (direct wallet-to-wallet)
Fees are typically zero for direct transfers
Example Request:
curl -X POST /api/v1/transformer/transaction/simulate \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "transactionId": "txn_crypto_001",
    "fromEntityId": "entity_123",
    "fromAccountId": "account_456",
    "toEntityId": "entity_789",
    "toAccountId": "account_012",
    "exactAmountIn": 10.5
  }'
Example Response:
{
  "executionId": "cexec-abc123def456",
  "quote": {
    "inAmount": {
      "amount": 10.5,
      "currency": "USDC"
    },
    "outAmount": {
      "amount": 10.5,
      "currency": "USDC"
    },
    "exchangeRate": {
      "rate": 1,
      "conversion": "1 USDC = 1 USDC"
    },
    "fees": {
      "partnerFees": {
        "amount": 0,
        "currency": "USDC"
      },
      "zynkFees": {
        "amount": 0,
        "currency": "USDC"
      },
      "totalFees": {
        "amount": 0,
        "currency": "USDC"
      }
    }
  },
  "payloadToSign": "{\"type\":\"ACTIVITY_TYPE_SIGN_TRANSACTION_V2\",\"organizationId\":\"org_xyz\",\"timestampMs\":\"1698765432000\",\"parameters\":{...}}",
  "validUntil": "2024-10-27T11:30:00.000Z",
  "message": "Transaction simulation successful"
}
Post Simulate, Transfer API needs to be initiated with the following changes:
Request Body - Continuum Transaction:
{
  executionId: string; // Required. Execution ID from simulate (starts with "cexec-")
  payloadSignature: string; // ⭐ Required. Signed transaction payload (X-Stamp header value)
  transferAcknowledgement: string; // Required for fiat. Transfer confirmation
  signatureType: string; // ⭐ Required. Either "WebAuthn" or "ApiKey"
}
Response:
{
  executionId: string; // Execution ID
  message: string; // Success message
}
Key Differences from original Transfer:
Requires payloadSignature instead of transferAcknowledgement
Requires signatureType field
No counterPartyRiskAcknowledged field
No verificationCode field
Execution ID must start with cexec- prefix
Example Request:
curl -X POST /api/v1/transformer/transaction/transfer \
  -H "Authorization: Bearer -token-" \
  -H "Content-Type: application/json" \
  -d '{
    "executionId": "cexec-abc123def456",
    "payloadSignature": "eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9...",
    "signatureType": "WebAuthn"
  }'
  
Example Response:
{
  "executionId": "cexec-abc123def456",
  "message": "Wallet execution completed successfully"
}

Summary of flow#


1. Simulate Transaction
   ↓
   POST /api/v1/transformer/transaction/simulate
   → Returns: executionId + payloadToSign

2. Sign Payload (Client-Side)
   ↓
   User signs the payloadToSign using their passkey
   → Generates: payloadSignature

3. Execute Transaction
   ↓
   POST /api/v1/transformer/transaction/transfer
   {
     executionId,
     payloadSignature,
     signatureType: "WebAuthn"
   }
   → Returns: Success confirmation

4. Transaction Broadcast
   ↓
   Signed transaction is broadcast to blockchain
   → Transaction hash recorded in execution
Notes on Continuum Transactions:
Account Type Requirement: The source account (fromAccount) must be of type NON_CUSTODIAL_WALLET.
Jurisdiction Matching: For direct transfers, both accounts must use the same jurisdiction (same token on same blockchain). Cross-jurisdiction transfers require swap or bridge functionality.
Signature Types:
WebAuthn: For passkey-based signing (browser/device authentication)
ApiKey: For API key-based signing (server-to-server)
Gas Fees: Blockchain gas fees are separate from the quoted fees and are handled by the transaction execution layer.
Modified at 2025-11-14 15:16:53
Previous
Continuum APIs
Next
Details on generating signatures
Built with