Clarity, Carefully — Tx-Sender
Minimizing Exploit(s) That Hijack The Persistence Of Tx-Sender
Keywords are a key part of, well, any programming language. And Clarity, the language behind secured-by-Bitcoin Stacks, much like other blockchain programming languages, is no different. However, what is different is that avoiding or lightly using keywords in other languages is not a deal-breaker (at least not in the early days); in smart contract world though, leaving even a character of doubt when using keywords leaves an abstract surface area for light bugs, or, more likely & infinitely worse, expensive exploit vectors.
Two of the most-common keywords in Clarity, used to refer to a principal (wallet addresses), are contract-caller & tx-sender. Along with block-height, contract-caller & tx-sender are a critical part of a Clarity dev’s arsenal from day 1 — but while they’re easy to understand at the surface level, understanding the minute implementation differences in detail is a non-negotiable. Both keywords are inherently secure, but both keywords can be abused in different ways.
Today, we’re reviewing the slightly more popular tx-sender. Specifically, we’ll see how it’s defining property, principal persistence as the originator, can be exploited through phishing & hijacking that persistence:
