Build the create_escrow instruction. Sender must sign (their token
authority moves funds into the escrow); payer pays rent for the new PDAs.
Build a createUser instruction that initializes the sender's
UserInfo PDA. Sender signs; payer pays rent.
Derive every PDA + the escrow_sig seed for an escrow. Pure — no RPC.
Fetch the on-chain escrow state. Returns null if the account has been
closed (released or cancelled — both terminal states on chain).
Read the sender's UserInfo PDA and derive the next-to-be-used escrow
nonce. Matches the movemoney parity scheme — opened + 1 when the PDA
exists, 1 otherwise. When userInfoExists is false, the caller is
responsible for prepending a createUser instruction before
create_escrow.
The on-chain escrow program address for this environment.
Build the release_authority_cancel_escrow instruction — the
reject / expire path. Funds return to the sender; escrow PDA closes.
Build the release_authority_release_escrow instruction. Same as the
with-reward variant minus the fee carve-out — useful when no reward
structure is needed.
Build the release_authority_release_escrow_with_reward instruction —
the recipient-claim path. The release authority signs and may skim a
reward amount to its own ATA (set reward = 0n for the no-fee case).
Build the sender_cancel_escrow instruction — the sender-cancel path.
Sender signs; funds return to sender.
Build the update_escrow instruction that attaches a recipient wallet
to a previously-created escrow. Update authority signs; payer pays.
secret must be the preimage of the escrow's stored hash, otherwise
the on-chain assertion will fail.
Whether the sender's UserInfo PDA has been initialized. create_escrow
fails if it has not, so a createUser instruction must precede the
first escrow a sender creates.
StaticderiveDerive the deterministic update-secret for a phone-keyed escrow.
customerId namespaces the secret so two customers sending to
the same phone never produce the same hash.
StatichashCompute the on-chain hash from a sender-supplied secret preimage.
The on-chain program stores only the SHA-256 hash at create time and
asserts sha256(secret) === hash at update time. The preimage is
service-defined; we use a phone-derived deterministic string so the
update authority can recompute it after recipient signup without storing
the secret server-side.
Interact with the CFX escrow Solana program.
The escrow program lets a sender lock funds on chain that an as-yet-unknown recipient (identified by a hashed secret — typically derived from their phone number) can later claim. Once the recipient signs up and a wallet is known, the update authority calls
update_escrowto bind that wallet. The release authority can then release funds to the recipient or, in the reject / expiry case, cancel the escrow and refund the sender.This service returns kit
Instruction[]— composition, signing, and submission stay inSolanaTransactionService.