What TET's signing path can and cannot do

The autosell path is limited to resource delegation

The product's autosell flow creates only DelegateResourceContract and UnDelegateResourceContract transactions. Seller onboarding accepts only an active-permission bitmap naming exactly those two operations and rejects a wider grant. Inside the product, the autosell signer independently refuses every other contract type. These are code and grant checks; they are not, by themselves, proof of how TRON will handle a transaction signed directly with the restricted key.

What the platform can sign, and why that list is short

The code defines four independently configured signing roles: escrow release, seller payouts, autosell delegation, and operations funding. Every role carries a list of transaction types it may sign, and the union of all four lists is exactly three types — TransferContract, DelegateResourceContract and UnDelegateResourceContract. Nothing else appears in any of them. The policy reads the transaction type out of the signed bytes themselves; the accompanying JSON is never consulted, so there is no second representation to disagree with the first and nothing to substitute.

Freeze and permission changes are outside the signing path

FreezeBalanceV2Contract is in none of the four lists. Neither is UnfreezeBalanceV2Contract, FreezeBalanceContract, WithdrawExpireUnfreezeContract, or AccountPermissionUpdateContract — that last one matters because rewriting an account's permissions is another route to the same outcome. A transaction whose type is not on a role's list is refused before anything else happens, and an unrecognised type matches no entry and is refused by default rather than allowed by default. The current product signing path therefore cannot produce a signature for any of those operations. That is a code-path guarantee, not a claim about direct raw-key use or network enforcement. Changing it would require a deliberate code edit that adds the type to a role policy.

How to check this yourself

The contract sets are two constants in `security/signer.py`; the per-role policies are in `security/policies.py`. Both are short enough to read in a couple of minutes, and the check itself is a plain set-membership test — no configuration, no runtime flag, no environment in which the list is longer. If you want to confirm the delegation you received is what you paid for, the delegation transaction is on-chain and names its owner, its receiver and its lock period.

What this proves, and what it does not

It proves what the product's signing path will put a signature on. That is narrower than a guarantee about every possible use of a key or transaction, and the difference is worth being precise about. We have not yet proved that the TRON network rejects a TRX transfer, unstake or other spend signed directly by a key whose active permission contains only the two delegation operations; that needs a funded Nile account. SIGNER_ARMED is runtime configuration, not a fixed product fact: when it is false, the signer refuses to load a non-empty key. This page does not assert the value in any currently deployed environment. We would rather publish the narrower claim we can support than the broader one you would have to take on faith.

Deposits require a personal address; withdrawals and seller payouts are unavailable

Buyer deposits are available only when the GET /v1/balance response or dashboard shows a configured personal platform deposit address. Only an explicit transfer to that displayed address enters the deposit path; an eligible transfer at or above the configured minimum is credited after the required confirmations. If neither surface shows a personal deposit address, do not send funds. Connecting TronLink alone never moves funds, and the sign-in wallet address is not the deposit destination. Buyer withdrawals and seller payout execution remain unavailable. A seller's autosell stake is not deposited into TET, and the autosell signer remains limited to resource delegation and undelegation.

Frequently asked questions