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;
fromEntityId: string;
fromAccountId: string;
toEntityId: string;
toAccountId: string;
exactAmountIn?: number;
exactAmountOut?: number;
}
Response - Continuum Transaction:{
executionId: string;
quote: {
inAmount: {
amount: number;
currency: string;
}
outAmount: {
amount: number;
currency: string;
}
exchangeRate: {
rate: number;
conversion: string;
}
fees: {
partnerFees: {
amount: number;
currency: string;
}
zynkFees: {
amount: number;
currency: string;
}
totalFees: {
amount: number;
currency: string;
}
}
}
payloadToSign: string;
validUntil: string;
message: string;
}
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
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
}'
{
"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;
payloadSignature: string;
transferAcknowledgement: string;
signatureType: string;
}
{
executionId: string;
message: string;
}
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
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"
}'
{
"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.
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.