Tangible – USDR

We express our gratitude to the Tangible – USDR team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.

USDR Redemption v2 is a fixed rate redemption contract on Polygon PoS that allows holders of the legacy USDR stablecoin to exchange their tokens for USDC at an immutable rate of $0.532 per whole USDR. Each redemption is atomic and settles on a first come first served basis: the contract burns the caller's USDR through an allowance and pays out USDC from the balance it holds at that moment, reverting when the balance cannot cover the payout in full. The audit covered the redemption contract and the two interface files that define its external API.

The system users should acknowledge all the risks summed up in the risks section of the report

Documentation quality

The project provides a README that documents the redemption mechanics, the rate representation, the deployment parameters, and the intended operational flow from the owner multisig. NatSpec coverage is complete across the contract and the interface, and the contract header declares five numbered specification invariants together with design rationale for the reentrancy guard, the owner gated funding path, and the deliberate absence of an upgrade path. No separate formal specification document is present in the repository, and references to an out of tree specification were removed before the audited commit. Several cases were identified in which the documented behaviour is stated more strongly than the implementation enforces, and these were reported.

Code quality

The codebase consists of a single 231 line contract and two interface files, and it follows Solidity and OpenZeppelin conventions throughout. OpenZeppelin Contracts v5.6.1 supplies two step ownership, safe ERC20 transfer handling, and the transient storage reentrancy guard, and the build pins both the compiler version and the Cancun EVM version so the transient storage opcodes match the deployment target. The design keeps a single mutable storage slot and no per user accounting, which removes an entire class of state consistency defects, and the constructor validates the token addresses, the rate, and the decimal assumptions of both tokens so a misconfigured deployment fails at construction. All issues identified during the audit are informational in severity and concern documentation accuracy, input validation consistency, and the inherited ownership surface.

Test coverage

Coverage of the contract in scope is 100 percent across lines, statements, branches, and functions as measured by the Foundry coverage tool, and that figure is reached by the mock based suite alone. The project supplies 72 tests: 51 unit tests against mock tokens, a stateful invariant campaign of 64 runs at depth 128 asserting value conservation, monotonicity of the funding timestamp and the sweep unlock relationship, and 18 integration tests that redeem live USDR on a Polygon fork pinned to block 88250000, parameterised over both native USDC and the bridged variant. Three improvements are recommended:

• The invariant configuration enables the option that tolerates reverting calls, so an unexpected revert passes without failing the campaign and targeted revert assertions would close that gap

• The invariant handler bounds every fuzzed redemption by the maximum redeemable view, which leaves the band between that bound and the true settlement limit unexercised

• The fork suite depends on an archive endpoint, falling back to a public node on which three of its tests do not complete, so provisioning a dedicated endpoint would keep the integration path exercised on every change rather than skipped in continuous integration.

USDR Redemption v2 is the wind down mechanism for USDR, a Polygon based stablecoin formerly backed by tokenized real estate that lost its peg. The contract offers holders a single deterministic exit: burn USDR and receive USDC at a rate fixed at deployment. It is a deliberate departure from the first version of the redemption system, which used epochs, pro rata rationing, per user accounting, and identity checks. None of those mechanisms are present in this version.

The system in scope consists of one contract, USDRRedemption, together with the IUSDRRedemption interface that publishes its full external API, its events, and its custom errors, and the IUSDR interface that declares the single USDR token function the contract consumes. The contract is deployed once with no proxy and no upgrade path, and the token addresses and the rate are immutable, so no post deployment configuration can alter the pricing or the assets involved.

A holder grants the contract a USDR allowance and calls the redemption entry point, optionally naming a separate address to receive the USDC. The contract computes the payout, rejects a payout that rounds down to zero, and reverts when the payout exceeds the USDC balance held at that moment. It then burns the USDR directly from the caller using the token's allowance based burn function and transfers the USDC to the receiver in the same transaction. The contract never takes custody of USDR and requires no burner role on the USDR token, because that token's burn function is permissionless and spends the caller's allowance. Settlement is all or nothing with no queue and no deferred claim, which makes access to the reserve a race between holders for the USDC currently on hand.

The reserve is replenished by the owner through a dedicated funding function that pulls USDC from the owner and stamps the sole mutable storage variable, the funding timestamp. Funding is restricted to the owner so that third party dust deposits cannot reset the wind down clock. USDC that reaches the contract through a direct transfer is still redeemable but does not stamp that timestamp. Once 180 days elapse with no funding, the owner may sweep the entire remaining USDC balance to a chosen recipient, and every funding call restarts the 180 day period. The timestamp is initialised to the deployment time so the delay also applies to any USDC received before the first funding call. A separate recovery function returns the full balance of any stray token to an owner chosen address and explicitly rejects USDC so the sweep delay cannot be circumvented.

Four view functions support integration. One previews the USDC payout for a given USDR amount, one reports the live USDC balance available to redemptions, one reports an amount intended to size a redemption against that balance, and one reports the earliest timestamp at which a sweep may occur.

The contract depends on two external tokens, both of which are upgradeable proxies outside the audit scope. Redemption relies on the USDR token's burn function, which executes only while that token is unpaused, so a pause of USDR halts all redemptions until it is lifted. The reentrancy guard uses transient storage under EIP-1153, which the Polygon PoS target supports from the Napoli upgrade onward, and the build pins the Cancun EVM version so no later opcode is emitted.

Privileged roles

• Owner: Ownership follows the two step transfer pattern and is assigned in the constructor, with a Gnosis Safe multisig named as the intended holder in the deployment script and the README. The owner is the only party that can supply USDC to the reserve, and therefore controls whether redemption remains possible at all. The owner can also sweep the entire USDC balance to any address once 180 days have passed since the last funding call, recover the full balance of any non USDC token held by the contract, initiate a two step ownership transfer, and renounce ownership in a single step through the inherited function. Compromise of the owner key would allow the reserve to be withdrawn as soon as the sweep window is open and would allow any stray token balance to be redirected immediately. The multisig requirement is an operational convention enforced by the deployment procedure rather than by the contract, because the constructor accepts any non zero address as the owner. No timelock constrains the recovery function or the ownership transitions, and the sweep delay is the only time based restriction in the system.

• No other privileged role exists. The redemption entry points are permissionless and callable by any USDR holder, no pause capability is present, no address can alter the rate or the token addresses, and the deploying account holds no privilege after construction because ownership is assigned during deployment.

• The pause authority on the USDR token is held by the token issuer and sits outside the audit scope, yet it determines whether redemption functions at all, because the burn call reverts while that token is paused.

The scope of the project includes the following smart contracts from the provided repository:

Assets in Scope