DEV Community: Daniel Carter

Getting Paid in USDT as a Freelance Developer in Türkiye: Networks, Fees and Cashing Out

Daniel Carter — Sun, 04 Oct 2026 16:09:47 +0000

A lot of developers in Türkiye work for clients in Europe, the Gulf or the US. Payment is where things get messy: international bank transfers take days, platforms take a cut, and by the time the money lands, the exchange rate has moved. More and more freelancers now ask to be paid in USDT.

This post is the practical guide I wish I had: how to pick a network, what it really costs, how to avoid the classic mistakes, and how to get from USDT back to lira.

1. Pick the network before you share an address

"Send me USDT" is not enough information. USDT exists on many chains, and they are not interchangeable:

Network	Address looks like	Typical fee to send	Notes
TRON (TRC20)	starts with `T`	0 to a few TRX, depends on energy	Most common for P2P in the region
BNB Chain (BEP20)	starts with `0x`	usually cents, paid in BNB	Same address as your other EVM chains
Ethereum (ERC20)	starts with `0x`	can be several dollars	Rarely worth it for invoices

Put the network in your invoice, in bold, next to the address. Something like: USDT on TRON (TRC20) only.

2. Understand what the fee actually is

On BNB Chain you pay gas in BNB. On TRON, a USDT transfer consumes energy; if you have none, the network burns TRX instead, which is why the "same" transfer can cost almost nothing or several TRX. If you send USDT often, use a wallet that can rent energy for the transfer instead of burning TRX.

3. Keep custody of your earnings

If the client pays straight into an exchange account, your income is only as available as that exchange's rules in your country. I prefer a self-custody wallet: a recovery phrase I hold, keys encrypted on my phone, and a PIN plus biometrics on top. Exchanges are fine for trading; your invoice address should be yours.

4. Avoid the four classic mistakes

Wrong network. The client sends BEP20 to a TRC20 address (or the reverse). Always confirm the network in writing.
No gas. USDT arrives on BNB Chain but you hold no BNB, so you cannot move it. Keep a small amount of the native coin on every chain you use.
Address poisoning. Scammers send dust from look-alike addresses so you copy the wrong one from history. Copy from your own receive screen, every time.
Skipping the test. For a new client, ask for a small test payment first.

5. Cashing out to lira

This is the step that matters most for freelancers. Options are exchanges, P2P marketplaces, or a wallet with a built-in local payment desk. With a desk, your USDT never leaves your custody until you place a sell order: you pick your country, choose a method the operator has enabled, send USDT, and receive lira to your local account. Whichever route you use, compare the rate you get to the market rate and check the current tax rules for freelance income in Türkiye.

The wallet I use

I use Taccoin: self-custody, one recovery phrase for Bitcoin, Ethereum, BNB Chain, Polygon, Arbitrum, Optimism, Base, Avalanche and TRON, built-in TRON energy for cheaper USDT transfers, and a local payments section that now lists Türkiye and nine European countries alongside the Arab region. Methods and rates are enabled per country, so check in the app what is live for Türkiye.

Disclosure: I am connected to the Taccoin project. This post is educational and not financial or tax advice.

TRON energy explained: why the same USDT transfer costs 0 or several TRX

Daniel Carter — Sun, 04 Oct 2026 14:27:20 +0000

If you have ever built anything that moves USDT on TRON, you have hit this question from users: "Why did my transfer cost almost nothing yesterday and several TRX today?" The answer is TRON's resource model, and it is worth understanding before you design fees in a wallet or payment flow.

Bandwidth and energy

TRON does not charge "gas" the way Ethereum does. Every transaction consumes two resources:

Bandwidth covers the raw size of the transaction. Every account gets a small free daily allowance, which usually covers simple TRX transfers.
Energy covers smart contract execution. USDT on TRON is a TRC20 contract, so every USDT transfer burns energy.

If the sender has energy (from staking TRX or from renting it), the transfer consumes that energy. If not, the network burns TRX from the sender to pay for it. That is where the "several TRX" comes from.

Why the cost changes per recipient

A USDT transfer() writes to the contract's balance mapping. Writing to a storage slot that already holds a value is cheaper than creating a new one. In practice:

Sending to an address that already holds USDT costs roughly 65k energy.
Sending to an address that has never held USDT costs roughly double, because a new storage slot is created.

So the same amount, from the same sender, can cost very different TRX depending on who receives it. Exact numbers drift with network parameters, so always estimate at send time rather than hard-coding.

What this means for wallet UX

Show the fee before confirmation. Estimate energy for the actual recipient and convert to TRX at current prices.
Check the TRX balance first. A user with 100 USDT and 0 TRX cannot send USDT at all unless energy is provided another way. This is the single most common support ticket for TRC20 wallets.
Consider energy rental. Renting energy for a single transfer is often cheaper than burning TRX. If you integrate a rental provider, handle the case where the rental arrives late or partially.
Let the payer be explicit. In flows where someone else receives the funds (gifts, payouts, claimable links), decide upfront who covers energy.

A real example: claimable links

I worked on the fee logic for Taccoin Wallet's send-by-link feature, where a sender locks USDT into a link and the receiver claims it later, possibly into a brand-new address. Because the receiver may have zero TRX and an empty address (the expensive case above), the sender pays the fees upfront: on TRON that is a small TRX amount plus a USDT reserve for energy, quoted before the link is created. On BNB Smart Chain the equivalent is a small BNB gas reserve. The receiver gets the full amount and never needs to acquire TRX first.

The general lesson: on TRON, "who pays energy, and is the recipient address new?" should be a first-class question in your design, not an afterthought.

Quick checklist

Estimate energy per recipient, not per token.
Block or warn on sends when TRX is insufficient.
Prefer rented or staked energy over burning TRX for high-volume flows.
Make the fee payer explicit in any flow involving a third party.

Disclosure: I am connected to the Taccoin project. This post was generated with AI tools. Numbers are approximate; verify current TRON network parameters before relying on them.

Claimable crypto links: why the secret lives after the #

Daniel Carter — Sun, 04 Oct 2026 12:54:22 +0000

Sending crypto to someone who has never installed a wallet is a surprisingly hard UX problem. You need their address, they need to pick the right network, and on chains like TRON or BNB Chain they also need a little native coin (TRX or BNB) just to move the token later.

One pattern that solves this is the claimable link: the sender creates a URL, shares it in WhatsApp or email, and whoever opens it can claim the funds. Here is how that works at the protocol level, and why the secret part of the link sits after the #.

1. An ephemeral wallet per link

When the sender creates a link, the app generates a fresh random private key on the device (32 bytes from a CSPRNG). That key controls a brand-new, single-use address on the target chain.

The sender then funds that address with:

the transfer amount (for example USDT), and
a small fee reserve, so the claim transaction can pay its own gas.

On BNB Chain the reserve is a bit of BNB. On TRON it is a little TRX to activate the account plus enough to cover energy for the USDT transfer. The key point: the sender pays the fees up front, so the receiver gets the full amount and never needs to hold a native coin.

2. The key travels in the URL fragment

The link looks roughly like this:

https://example.com/r/<link-id>#k=<key-material>

Everything after # is the fragment. Browsers never send the fragment to the server in the HTTP request. That gives a nice property: the backend can store the link ID, the ephemeral address, the amount and the expiry, while never seeing the key that can spend the funds.

The claim page reads location.hash in JavaScript, entirely client-side.

3. Claiming = signing on the receiver's device

When the receiver opens the link and chooses where to receive (a new wallet created on the spot, or an address they already own):

The page or app reconstructs the ephemeral key from the fragment.
It builds a transfer from the ephemeral address to the receiver's address.
It signs locally and hands the signed transaction to the server.
The server verifies it matches the link (right amount, right destination rules, not expired, not already claimed) and broadcasts it.

The server is a relay and a bookkeeper, not a custodian.

4. An optional second factor

A link in a chat is a bearer token: whoever has it can claim. To reduce the risk of a forwarded or leaked link, the fragment can carry the key XOR-ed with a value that is only released after the receiver enters a short security code. The sender shares that code over a different channel (a call, SMS, another app).

5. Expiry and refunds

Unclaimed links should not lock funds forever. After an expiry window (for example 7 days), the sender can sweep the ephemeral address back to their own wallet. Since the sender's device also kept the key, this needs no cooperation from the server beyond broadcasting.

Threat model in one table

Risk	Mitigation
Server breach	Server never stores the spending key
Link forwarded to the wrong person	Optional security code on a second channel
Receiver has no gas	Fee reserve pre-funded by the sender
Link never opened	Expiry + sender refund
Link posted publicly	Nothing technical helps: treat it like cash

Real-world example

This is the design behind send-by-link in Taccoin Wallet, the wallet I work on: USDT on TRON and BNB Chain, sender-paid fees, key in the #k= fragment, optional code, 7-day expiry with refund. There is a short write-up here: wallet.taccoin.com/en/features/send-by-link.

If you have built something similar (or found holes in this model), I would like to hear about it in the comments.

Disclosure: I work on Taccoin Wallet. This post was generated with AI tools. It is educational and not financial advice.