UNIT: A Screened, Fully-Backed Digital Dollar on TRON

Whitepaper — Version 1.0 Network: TRON mainnet (chain ID 728126428) Token: unitUSD (UNIT), TRC-20, 6 decimals Site: https://unitdefi.com

Editorial note. Items marked ⟨TBD⟩ are facts this document cannot assert on its own — legal entity, jurisdiction, governing terms, and reserve attestation arrangements. They must be filled in by the issuer before this paper is published. Everything else in this document is drawn from the deployed contracts, the application, and the three published security reviews, and can be verified on-chain.

Abstract

UNIT is a US-dollar-denominated token issued on TRON and redeemable one-for-one for USDT. It exists to solve a problem that ordinary stablecoin transfers create and do not solve: a holder of USDT inherits the history of every wallet that touched their balance, and a freeze applied upstream can reach them without warning or recourse.

UNIT addresses this at the only point where it can be addressed cheaply — the moment of issuance. Every deposit is screened before any UNIT is minted. A deposit that fails screening does not enter the protocol; the transaction never happens and the depositor's USDT never leaves their wallet. What circulates as UNIT has therefore passed a check that USDT itself does not apply.

Backing is held one-for-one and deployed into flexible-term positions selected for short-notice recall, so redemption does not depend on unwinding an illiquid book. Holders who wish to may stake UNIT into an ERC-4626 vault and receive a share of protocol proceeds; holders who do not wish to are unaffected. UNIT is self-custodial throughout: it is a TRC-20 balance in the holder's own wallet, transferable on TRON like any other token.

This paper describes the issuance and redemption mechanics, the reserve route, the staking vault, the compliance model, the privileged roles that exist and what they can and cannot do, and the risks a holder takes.

1. Introduction

1.1 The problem UNIT is built for

Dollar stablecoins solved denomination. They did not solve provenance.

When a holder receives USDT, they receive a balance whose history they did not choose and cannot inspect in any practical way. Issuers of major stablecoins freeze addresses at the request of law enforcement, and those freezes are applied to addresses, not to the tainted portion of a balance. A holder who received funds two hops from a sanctioned counterparty may find their entire position immobilised. The remedy is a legal process, not a transaction.

This is a structural property, not an operational failure. The screening that would prevent it has to happen before value enters a wallet, and a general transfer network cannot perform it: by the time a transfer settles, the holder already owns the history.

A second, smaller problem sits alongside it. Stablecoin balances are idle by construction. The reserves backing them earn a return that accrues to the issuer, not the holder. Protocols that pass that return back to holders usually do so by making the token itself rebasing or yield-bearing, which breaks its usefulness as a unit of account and complicates every integration downstream.

1.2 What UNIT is

UNIT is a TRC-20 token on TRON, denominated in US dollars and backed one-for-one by USDT deposits. It has three properties that define it:

1. Screened at issuance. Every deposit is checked against sanctions and illicit-finance screening before the mint transaction is authorised. A deposit that does not clear is not minted — there is no partial acceptance and no quarantine.
2. Redeemable one-for-one. Each UNIT is redeemable for one USDT under the governing terms ⟨TBD⟩. Issuance and redemption are matched to USDT flows. UNIT is not algorithmic and holds no volatile collateral.
3. Self-custodial. UNIT lives in the holder's own TRON wallet. The protocol never takes custody of a user's UNIT, and holding it requires no account, no deposit with an intermediary, and no ongoing permission.

Yield is strictly optional and strictly separate. A holder who wants a share of protocol proceeds stakes UNIT into a vault and receives vault shares; a holder who wants a plain dollar token holds UNIT and nothing changes for them. The UNIT token itself does not rebase, does not accrue interest, and always represents one dollar of claim.

1.3 What UNIT is not

Stating this plainly is more useful than any feature list.

• UNIT is not a bank deposit and carries no deposit insurance.
• UNIT is not unconditionally redeemable. The token contract cannot freeze an address or confiscate a balance, but minting and redemption go through a Minter that an admin role can pause and that will not act without the protocol's signature. Section 8 describes exactly who holds those powers and why they exist.
• UNIT is not permissionless to acquire. Minting requires passing screening and requires access from a supported region. Holding and transferring UNIT, once minted, requires neither.
• UNIT is not a guarantee against loss. The buffer reserve described in §5.4 is a risk-management measure, not an insurance fund.

2. System overview

2.1 Components

UNIT is four contracts and three off-chain services.

On-chain:

Off-chain:

The separation between the screening decision and the signing key is deliberate: the signer produces an authorisation for a specific account, amount, nonce and deadline, and holds no ability to move funds. The reserve is moved by a separate operator key. Neither key alone can both authorise and extract.

2.2 Contract addresses (TRON mainnet)

Every address below is public and can be inspected on Tronscan. The application also publishes them on its transparency page.

The Minter's EIP-712 domain is { name: "Unit Minter", version: "3", chainId: 728126428, verifyingContract: 0xf62ece8fe87928b8b183242bf92b8fc6474e3f6d }. The verifying contract is the Minter's own address in hexadecimal form. A wallet that signs for a different verifying contract produces a signature the Minter rejects — this is what binds an authorisation to one specific deployment.

2.3 Units and precision

USDT, UNIT and the vault share all use 6 decimals. One UNIT is 1000000 in base units. All three are fixed by deployment; the application does not read decimals() per transaction, because a failed read that silently returns zero would scale an amount by a factor of one million.

3. Issuance

A mint is one on-chain transaction preceded by one off-chain authorisation. It settles in seconds and cannot be executed without both.

3.1 Authorisation

Before a mint can be submitted, the depositor's address is screened. The screening service returns one of three outcomes:

• Cleared. The signer produces an EIP-712 signature over the mint struct.
• Rejected on screening. No signature is produced. The response carries a reason of AML and, when available, a risk score on a 0–100 scale. The user is told plainly; no transaction is attempted.
• Unavailable. The service could not reach a decision. No signature is produced and the cause is not disclosed to the client.

The signed struct is:

Mint(
  address account,
  uint256 assets,
  bool    stake,
  uint256 nonce,
  uint256 deadline
)

Four properties follow from what is inside it:

• account binds the authorisation to one wallet. It cannot be replayed by another address.
• assets binds it to one amount. It cannot be reused for a larger mint.
• nonce is read from the Minter's own nonces(account) counter and binds it to one use. A replay reverts with InvalidAccountNonce.
• deadline binds it to a window. A late submission reverts with PermitExpired.

The stake flag is signed rather than passed freely, so the user cannot alter the destination of the freshly minted UNIT after the authorisation was granted.

3.2 The mint transaction

The depositor approves USDT to the Minter, then calls:

mint(
  uint256 assets,
  bool    stake,
  uint256 minUnitOut,
  uint256 deadline,
  bytes   signature
)

The Minter recovers the signer from the signature, checks it holds SIGNER_ROLE, consumes the nonce, pulls assets of USDT from the caller, routes it into the reserve (§5.2), and mints UNIT to the caller — or, if stake is true, into the vault on the caller's behalf.

If the recovered signer does not hold SIGNER_ROLE, the transaction reverts. This is the property that makes screening enforceable rather than advisory: the check is not a front-end convention that a determined user can route around by calling the contract directly. The contract itself will not mint without a signature from a key the protocol controls.

3.3 The output floor

Both legs carry an output floor. mint reverts with InsufficientOutput if it would deliver less than minUnitOut; redeem reverts if it would deliver less than minUsdtOut.

Both legs are one-for-one, so the signed assets is the natural floor. In practice the application allows the mint leg 50 basis points of slack (0.5%) and holds the redeem leg exact. The asymmetry is deliberate and worth stating rather than hiding: the mint leg routes through an external reserve market between the moment the signature is issued and the moment the transaction lands, and that route can return a hair under par. The redemption leg is not permitted any slack at all — a redemption that would pay less than one USDT per UNIT reverts rather than settling at a worse rate.

Slack is a silent acceptance of a worse price. It is a parameter, it is small, and it is disclosed here because a floor a user cannot see is not a protection.

3.4 Mint and stake as one transaction

When stake is set, minting and staking happen inside a single transaction. The user does not mint, then approve UNIT to the vault, then deposit — a three-transaction sequence that costs three fees and can be abandoned halfway, leaving a user with an intent they did not complete. The flag is part of the signed struct, so the atomic path is authorised as one operation.

4. Redemption

Redemption reverses issuance and is subject to the same authorisation. Critically, screening runs before any reserve movement. A redemption that fails screening does not cause a withdrawal from the reserve; nothing is unwound on behalf of an operation that will not complete.

The signed struct is:

Redeem(
  address account,
  uint256 assets,
  bool    unstake,
  uint256 nonce,
  uint256 deadline
)

The holder approves UNIT to the Minter (or vault shares, when unwinding a staked position) and calls:

redeem(
  uint256 assets,
  bool    unstake,
  uint256 minUsdtOut,
  uint256 deadline,
  bytes   signature
)

The Minter verifies the signature and nonce, burns the UNIT, recalls the matching USDT from the reserve, and transfers it to the holder. When unstake is set, the vault position is unwound and redeemed in the same transaction.

Redemption is one-for-one. There is no redemption fee taken by the contract and no minimum holding period. Settlement is prompt in the ordinary case; §12 describes the conditions under which it may not be.

5. Reserves

5.1 Backing

Every UNIT in circulation is issued against one USDT received. The token has no other issuance path: unitUSD grants MINTER_ROLE and the Minter is the holder of it. Supply cannot be created by an admin transfer, a governance vote, or an off-chain instruction — only by a mint transaction that moved USDT in the same call.

This makes the invariant checkable by anyone: the UNIT total supply and the reserve position are both public on TRON, and the transparency page publishes the ratio between them continuously.

5.2 The reserve route

Deposited USDT does not sit idle, and it does not go into a discretionary trading book. The Minter routes it along a fixed, contract-encoded path:

USDT → PSM → USDD → jUSDD (JustLend)

The route is set at deployment as immutable references on the Minter (USDT, PSM, USDD, jUSDD). It is not a parameter an operator selects per deposit. A reader can verify where a given deposit went by following the transaction.

jUSDD is a JustLend money-market position. It was selected for the property that matters most to a redeemable token: a position that can be exited on short notice at par, rather than one that maximises return and settles slowly.

5.3 Recall, separation, and why term matters

Three commitments govern the treasury:

• Short-notice recall. Positions are selected for the ability to recall funds promptly. Long lock-ups are avoided, because a lock-up is a promise to holders that redemption may be delayed.
• Separation from operating funds. Treasury assets are held separately from the project's operating funds. The money backing UNIT is not the money that pays the project's bills.
• A dedicated buffer. A portion of treasury proceeds is routed into a buffer reserve, maintained to absorb losses from venue incidents or counterparty failure.

The buffer is a risk-management measure. It is sized to absorb ordinary adverse events, not systemic ones, and it is not a guarantee against loss. Presenting it as insurance would be dishonest, so it is not presented that way.

5.4 Collateral ratio

The collateral ratio — reserves held against UNIT outstanding — is published continuously on the transparency page and derived from public on-chain balances. It is not a periodic attestation produced by the issuer; it is a figure any reader can recompute from the addresses in §2.2.

Arrangements for independent reserve attestation: ⟨TBD⟩.

6. Staking

6.1 The vault

stakedUnit is an ERC-4626 vault whose underlying asset is UNIT. A holder deposits UNIT and receives shares; the shares represent a proportional claim on the vault's total assets, which grow as protocol proceeds are distributed into it. Unwinding burns shares and returns UNIT — principal plus the accrued share.

The vault is not a lock. There is no minimum term, no unbonding period, and no withdrawal queue in the ordinary case.

6.2 Share accounting

Share accounting is standard ERC-4626. convertToAssets and convertToShares express the current exchange rate; previewDeposit, previewMint, previewRedeem and previewWithdraw give the exact result of an operation before it is submitted. Because proceeds accrue to the vault rather than to individual balances, a staker's share count stays constant and the UNIT it converts to increases.

The vault exposes a VaultInsolvent error. It exists so that a vault whose assets have fallen below its obligations refuses to settle at a rate it cannot honour, rather than paying early redeemers in full and leaving later ones short.

6.3 Reward cycle

Reward periods close Saturday at 12:00 UTC, and payouts are executed on Tuesday. Distribution is by cumulative Merkle claim: a root covering the period is published, and each eligible holder claims against it. Cumulative roots mean a holder who misses one period does not forfeit it — a later claim settles the full outstanding amount.

Total rewards distributed are published on the transparency page, cumulatively and by period.

6.4 Shares are not a second token

Vault shares are deliberately not presented to users as a tradable asset, and the vault restricts their transfer — it exposes a NonTransferable error for transfers it does not permit. The application surfaces a staked position simply as "staked UNIT" rather than as a separate ticker.

This is a design choice with a reason. A freely tradable, yield-bearing derivative of a dollar token invites secondary markets that price it away from par, and a holder who acquired it there has none of the screening guarantees that issuance provides. Keeping the share bound to the position that created it keeps the dollar claim and the yield claim from drifting apart.

7. Compliance model

7.1 Screening happens before issuance

The single most important property of the compliance model is its position in the sequence. Screening is not applied to UNIT after it circulates; it is applied to the depositor before UNIT exists. Funds that fail never enter the protocol, so there is nothing to freeze afterwards and no other holder's balance is contaminated by a decision made later.

This is why the check is enforced by the contract's signature requirement rather than by the interface. An interface check is a suggestion. A contract that will not mint without a signature from a key held by the protocol is a rule.

7.2 Regional availability

The application checks regional availability before offering minting or redemption, and fails closed: if the check cannot be completed, access is denied rather than granted. The country determination is made server-side and is never sent to the client. Public, read-only surfaces — the landing page and the transparency dashboard — are deliberately not gated: reading published figures is not a transaction.

7.3 No freeze, no confiscation

Neither the token nor the vault has any administrative power over a holder's balance. unitUSD and stakedUnit expose no freeze, blacklist or confiscation function: no address can be blocked from transferring, and no balance can be moved out of a wallet without its holder's signature.

Compliance acts at the edges instead. Screening decides who may mint (§7.1), and the signature requirement decides who may redeem. The one administrative lever over the flow itself is the Minter's pause: while the Minter is paused, the calls it guards revert with EnforcedPause, and minting and redemption stop. Pausing does not touch UNIT already held — it keeps transferring as an ordinary TRC-20 token.

Two things constrain the pause:

1. Every use is a public on-chain event. Pausing and unpausing emit Paused and Unpaused on a public ledger and cannot be performed quietly.
2. The power is held under a privileged role, not by the signer or operator keys that run day-to-day issuance and reserve movement.

8. Roles and trust assumptions

8.1 On-chain roles

8.2 Key separation

The signing key and the operating key are separate by design. A signature authorises an operation but cannot execute a transfer of reserves; the operator can move reserves but cannot produce a valid authorisation. Compromise of either key alone is materially less damaging than compromise of a single key holding both powers.

The signer address in §2.2 is the configured one, and the application reads the live value from a health endpoint at runtime — roles can be re-granted on a redeploy, and the transparency page shows what is actually in force rather than what was true at build time.

8.3 The powers a holder must trust

Stated without softening, so that a reader can price them:

• The administrator cannot freeze an address or confiscate UNIT or vault shares — the contracts have no such functions.
• The Minter can be paused, which stops minting and redemption until it is unpaused.
• The Minter exposes withdraw(token, to, amount) and executeCall(target, data, value) under the admin role. executeCall is a general-purpose escape hatch: it can make the Minter perform an arbitrary call. It exists so that an integration failure in an external venue can be unwound without redeploying, and it is the single most powerful function in the system.
• The signer service is a liveness dependency. If it is unavailable, no new UNIT can be minted and no redemption can be authorised. Existing UNIT continues to transfer normally — it is a TRC-20 token and needs no permission to move — but the redemption path depends on a service being up.

⟨TBD⟩ Whether the admin role is held by a multisig or a timelock, and its signer composition, should be stated here. This is the single disclosure that most changes how the above should be read, and it should not be left implicit.

9. Fees and network costs

The Minter charges no protocol fee on mint or redeem. Both legs are one-for-one, subject to the output floors in §3.3.

What a user does pay is the TRON network cost. TRON prices computation in energy and transfers in bandwidth; an account without staked TRX pays for energy by burning TRX. A mint is an approval plus a contract call, and the combined energy cost can exceed what a wallet holding only USDT has budgeted for. This is the most common reason a first transaction fails, and it is a network fee, not a platform charge.

Because of this, the protocol operates an energy rental facility. Energy is rented on TRON's open market and delegated directly to the user's address — no custody, no approval, one TRX transfer. It can be used ahead of an operation automatically, or bought directly from the energy page. Rentals are currently one hour, from 32 000 to 5 000 000 energy. Pricing is market-driven and fixed at the moment an order is created.

10. Transparency

The protocol publishes a continuously updated transparency page covering:

• Supply — UNIT outstanding.
• UNIT staked — the vault's total assets.
• Collateral ratio — reserves against outstanding supply.
• Rewards distributed — cumulative and by period.
• Interaction volume — every UNIT movement (mints, redemptions, wallet-to-wallet transfers) accumulated over time. Turnover only grows: a mint and its later redemption each count their own size.
• Unique wallets.
• The address book of §2.2, each linking to Tronscan.

The figures are derived from public on-chain balances and transfers. Publishing the addresses alongside the numbers is the point: a reader who does not trust the dashboard can recompute every figure on it from the chain.

11. Security review

The contracts have been reviewed three times by parties independent of the development team. All three reports are published in full.

Zenith — UNIT Smart Contract Security Assessment, version 1.1. Audit conducted 24–25 August 2026, report published 27 August 2026. Auditors: Dravee and Mario Poneder. Scope: github.com/AltitudeDP/unit-core, commit 4a5a3b53c79b9bcf76350604d431838d9baaebcc, src/**/*.sol, with a separate mitigation review at commit fcbbc1e88ca3a57e8606e5fd426b12018f32ff99.

Findings:

The high-severity finding concerned two-token JustLend reward claims reverting because the Minter could not receive a native-TRX vault callback. It was resolved. The medium findings covered confiscation being bypassable through transfers and staking, missing minimum-output protection on mint and redemption, and unlimited approvals to external dependencies — all three resolved. Several low-severity findings were acknowledged rather than changed, including the dependence of immediate USDT redemption on shared external liquidity, which is an inherent property of the reserve route rather than a defect (§12).

The output floors described in §3.3 are a direct result of this review. The confiscation functions that the review examined were later removed from the contracts altogether (§7.3).

T1MOH — independent review of unit-core: the minter, the staking vault and the custody adapter. Version 1.0, August 2026.

Hashlock — review of the Unit Technologies contracts, published on the auditor's own site.

An audit is a review of a specific commit at a specific time. It is not a guarantee, and each report states its own scope and the version it covers.

12. Risk factors

A reader should weigh all of the following.

Reserve venue risk. Backing is deployed to an external money market (JustLend, via USDD). A failure, exploit, or freeze at that venue impairs the reserve. The buffer reserve exists to absorb such an event but is not sized for an unbounded one.

Redemption liquidity risk. Immediate USDT redemption depends on shared external liquidity in the reserve route. Under stressed conditions, redemption may be slower than the ordinary case. This was raised in the Zenith review and acknowledged rather than engineered away, because it follows from the choice to deploy reserves at all.

Peg-transmission risk. UNIT is backed by USDT and routed through USDD. It inherits the risk of both. A loss of peg in either propagates to UNIT's backing.

Administrative risk. Pause, withdraw and executeCall exist and are held under privileged roles (§8.3). A compromised or malicious administrator cannot touch balances in holders' wallets, but can halt minting and redemption and can move what the Minter holds on the reserve route.

Service liveness risk. Minting and redemption require the signer service. Its unavailability suspends both, though it does not affect the ability to transfer UNIT already held.

Screening risk. Screening is automated and can produce false positives. A legitimate user may be declined. A support path exists ⟨TBD: escalation and appeal process⟩.

Regulatory risk. The regulatory treatment of dollar-denominated tokens is unsettled and varies by jurisdiction. Availability may change. ⟨TBD: issuing entity, jurisdiction, and licensing status.⟩

Smart-contract risk. Three audits reduce this risk. They do not eliminate it.

Vault solvency risk. If vault assets fall below obligations, the VaultInsolvent guard halts settlement rather than paying some stakers in full at others' expense. This protects fairness, not principal.

13. Glossary

Base units — the integer representation of an amount. All three tokens use 6 decimals, so one token is 1000000 base units.

EIP-712 — a standard for signing structured data. Used here so an authorisation is bound to a specific account, amount, nonce, deadline and deployment, and is unreadable as anything else.

Energy / bandwidth — TRON's resource model. Energy pays for computation, bandwidth for transfers. Both can be obtained by staking TRX or, in energy's case, rented.

ERC-4626 — the tokenised vault standard. Defines deposit, redeem, and the conversion between assets and shares.

Nonce — a per-account counter on the Minter, consumed by each authorised operation, making replay impossible.

Output floor — minUnitOut / minUsdtOut. The minimum a leg must deliver or revert.

PSM — peg stability module. The venue converting USDT into USDD along the reserve route.

Screening — automated sanctions and illicit-finance checks run against a depositing address before issuance is authorised.

Appendix A — Verifying this document

Every factual claim about the system can be checked without trusting the issuer:

1. Supply and backing. Read totalSupply() on unitUSD and the reserve position at the jUSDD address. Both are public.
2. Issuance authority. Read hasRole(MINTER_ROLE, …) on unitUSD. Only the Minter should hold it.
3. The reserve route. Read USDT(), PSM(), USDD() and jUSDD() on the Minter. They are immutable and must match §2.2.
4. The signing domain. Call eip712Domain() on the Minter. It must return Unit Minter, version 3, chain 728126428, and the Minter's own address.
5. Any individual mint or redemption. Minted and Redeemed events carry the account and amounts. Every issuance in existence is enumerable.

Appendix B — Interface reference

Minter

function mint(
    uint256 assets,
    bool stake,
    uint256 minUnitOut,
    uint256 deadline,
    bytes signature
);

function redeem(
    uint256 assets,
    bool unstake,
    uint256 minUsdtOut,
    uint256 deadline,
    bytes signature
);
function nonces(address account) view returns (uint256);
function eip712Domain() view returns (...);

// admin
function withdraw(address token, address to, uint256 amount);
function executeCall(address target, uint256 value, bytes data);
function claimAndDistributeRewards(...);
function pause();
function unpause();
function paused() view returns (bool);

// errors
error InsufficientOutput();
error PermitExpired();
error InvalidAccountNonce();
error InvalidIntegration();
error OperationFailed();
error EnforcedPause();
error TransferFeeActive();
error ZeroAddress();

unitUSD

function mint(address to, uint256 value);            // MINTER_ROLE
function burn(uint256 value);
function burnFrom(address from, uint256 value);

stakedUnit

function deposit(uint256 amount, address receiver);
function withdraw(uint256 amount, address receiver, address owner);
function depositFor(address account, uint256 value);
function withdrawTo(address account, uint256 value);
function asset() view returns (address);
function underlying() view returns (address);

Open items before publication

This document describes a software protocol. It is not an offer to sell, a solicitation to buy, investment advice, or a prospectus. UNIT is not a deposit and is not insured. Nothing here is a guarantee of redeemability, price stability, or return. Read §12 before acquiring UNIT.