​

Concept: The Transaction & Signing Lifecycle

A core design goal of Refract is to enable a seamless transaction experience without compromising on security. This is achieved through a carefully orchestrated lifecycle involving the dApp, our OnboardKit SDK, the Refract Passport client, and our backend services. This lifecycle ensures that standard dApp libraries work out-of-the-box while all signing operations occur within a secure, user-controlled environment.

The entire process can be visualized as a multi-stage flow:

​

1. The SecureSign Sandbox Protocol

Every transaction is managed by the SecureSign Sandbox Protocol. This protocol’s primary job is to create a secure context for user approval. It ensures that a dApp cannot spoof its identity or trick a user into signing a malicious payload. As detailed in the SecureSign Security page, this involves strict application identity verification and human-readable transaction previews.

​

2. Signing Transactions with Refract Passport

The Refract Passport is the user-facing component of the signing lifecycle. When the OnboardKit SDK needs a signature, it hands off control to the Passport client.

Technical Flow (TikTok postMessage vs. Telegram/LINE Polling):

The communication protocol between the dApp (via OnboardKit) and the Passport varies by platform:

• On TikTok: Communication is real-time using the postMessage API. The dApp sends a SignTransactionRequest and listens for a TransactionResponse event.
• On Telegram/LINE: Direct, real-time communication between web apps is restricted. Therefore, we use a secure, nonce-based polling mechanism.
  1. Request: The OnboardKit sends the transaction payload to a temporary, authenticated backend cache and receives a unique, single-use nonce.
  2. Handoff: It opens the Refract Passport app, passing the nonce as a start parameter.
  3. Approval: The Passport app uses the nonce to fetch the payload, the user approves, and the backend signs the transaction. The final result (e.g., transaction digest) is written back to the cache against the same nonce.
  4. Polling: Concurrently, the OnboardKit in the dApp polls an endpoint with the nonce. Once the result is written to the cache, the polling request succeeds and returns the final transaction data to the dApp.

​

3. Gas Sponsorship with GasMaster

Refract GasMaster is an optional but powerful component in the transaction lifecycle. It allows dApps to sponsor transaction fees for their users, dramatically reducing onboarding friction.

• Integration Point: GasMaster intervenes just before the transaction is broadcast to the blockchain.
• Process:
  1. When the backend signing engine receives a transaction request, it checks the dApp’s GasMaster policy, configured in the Refract Portal.
  2. If the transaction is eligible for sponsorship (e.g., the user has enough budget), GasMaster provides a fresh gas object to pay for the fees. On object-based chains like Sui, this involves managing a pool of distinct gas objects to avoid conflicts.
  3. The transaction is signed with the sponsored gas payment included.
  4. GasMaster’s budget manager debits the transaction fee from the dApp’s configured budget.

This entire process is transparent to the end-user, who simply sees a gas-free transaction.