This page addresses common questions about Refract Network’s security model.

Q: How do you ensure only authorized applications can initiate transaction requests?

A: Every transaction request is bound to a registered application id (appId) and a user profile id (profileId). The signing interface prominently displays the originating application’s name and logo, which are verified against our registry. Users can only approve transactions from applications they’ve explicitly interacted with, and only for profiles they own.

const requestBody: AuthBody = {
  authType: "extx",
  payload: tx,
  chainType: "sui",
  profileId: user.profileId, // Bound to user's profile
  appId: "your-dapp-identifier", // Bound to your registered dApp
  dappName: "Your DApp Name",
  // ... other fields
};

Q: How do you prevent replay attacks using old transaction requests?

A: Each transaction request uses a unique, single-use identifier (nonce) that is:

  • Generated using cryptographically secure random values.
  • Automatically invalidated immediately after processing (approval or rejection).
  • Bound to a specific user session and application context.
  • Set to expire after a short time period (default: 2 minutes).
// Nonce lifecycle
const nonce = generateSecureNonce(); // Cryptographically random
await storeTransactionRequest(nonce, requestData); // Temporary storage
const result = await processUserApproval(nonce); // One-time use
await deleteNonce(nonce); // Immediate cleanup

Q: What prevents unauthorized modification of pending transaction requests?

A: Transaction request data is stored in an authenticated, backend key-value store with access restricted exclusively to Refract Network services. dApps never have direct write access. The payload remains immutable during the user approval process. When a user approves a transaction, our signing engine uses this pristine, stored payload, not anything resent from the dApp.

Q: How do you secure postMessage communication between the dApp iframe and the parent window?

A: We implement multiple validation layers for all cross-origin communication:

  1. Origin Validation: Both the parent window and the dApp iframe strictly check event.origin to ensure messages are only coming from expected domains.
  2. Message Structure Validation: Messages that don’t conform to the expected type and structure are ignored.
  3. Request Correlation: All requests and responses are linked with a unique request ID to prevent spoofing.

Q: How do you ensure transactions are only signed by the intended user?

A: Transaction requests are cryptographically bound to a specific user profile via profileId. Our backend verifies the user’s social authentication token (e.g., Telegram’s Init Data or a TikTok access token) for every sensitive operation, ensuring the request is coming from an authenticated session owned by that user.

Q: What happens if someone gains access to a raw transaction request?

A: The request itself is not enough to authorize a transaction. The signing process can only be completed within the authenticated Refract Passport environment, which is itself secured by the platform’s social authentication and, optionally, user-configured biometrics or a PIN.

Q: What information do users see during transaction approval?

A: Our signing interface provides a comprehensive, human-readable summary, including:

  • The source dApp’s name and logo.
  • The transaction type (e.g., Transfer, Contract Interaction).
  • The exact assets and amounts being moved.
  • The recipient address or contract.
  • The network being used and estimated gas fees (including sponsorship status).