Bind the details.
A recipient-signed request fixes the destination, token mint, amount, expiry and unique nonce. A substituted address should fail the intent checks.
A proposed confirmation layer for crypto transfers. Align the intent. Verify both sides. Give every important transfer a deliberate beginning.
Protocol concept · Interactive simulation · No wallet required
Walk through a successful handshake, test an address mismatch, or cancel before release. Every interaction is a local simulation.
A payment request binds the recipient, asset and amount to one specific intention.
The displayed phrase and wallet labels are illustrative. This demo does not create signatures, escrow accounts or blockchain transactions.
The proposed design brings context and recipient consent into the process before funds reach their final destination.
A recipient-signed request fixes the destination, token mint, amount, expiry and unique nonce. A substituted address should fail the intent checks.
A short phrase derived from the transfer details helps two people compare the same intent through an independently trusted channel.
Funds wait in a proposed escrow stage. Recipient approval and a pre-enrolled second-device confirmation precede a brief cancellation window.
The phrase makes the transfer easier to compare. Signatures and on-chain checks would enforce the actual rules. A matching phrase alone never authorizes a payment.
The proposed program would bind approvals to the same unique transfer, lock its terms, enforce the release deadline and make expired transfers reclaimable.
See every stage ↗Expiry would permit a refund transaction; the blockchain does not automatically initiate it.
The long-term goal is a consistent confirmation experience across blockchains. Each network requires its own implementation, wallet integration and security review.
No live network integrations are available. Multichain support does not imply cross-chain transfers or compatibility with every blockchain today.
Define the transfer intent and show the confirmation flow through this interactive prototype.
Implement a Solana testnet prototype, test adversarial scenarios and obtain independent security review.
Research additional networks and wallet integrations after the core design has been validated.
Address substitution, accidental recipient changes, reused approvals and single-device blind confirmation. Intended for high-value transfers and first-time recipients.
It cannot identify a scammer you intentionally approve, guarantee delivery of goods or undo a released transfer. Compromised devices and program defects remain risks. Extra steps and network fees are expected.
No. Tacto is currently a protocol concept and interactive presentation. No audited smart contract, token, working wallet integration or live escrow service is provided here.
In the proposed design, a funded transfer can be cancelled before release during the permitted window. After final release it is irreversible. Expired funds require someone to submit a refund transaction.
A separately enrolled key could approve the exact transfer details from an independent screen. This reduces reliance on one compromised interface, but only if enrollment and the second device remain trustworthy.
No. Escrow, timelocks and signed payment requests are established ideas. Tacto proposes combining them into a clearer two-sided confirmation flow. Market-wide novelty has not been established.
That is an ambition, not current compatibility. Token extensions, chain execution rules and wallet capabilities would require explicit support and validation. Initial development would focus on selected Solana assets.
Explore what a clearer beginning for crypto transfers could look like.
Experience the handshake ↗