By Alan Wu
Onchain systems often collect a large mix of tokens, ranging from blue chips to long tails and dust, but ultimately want to convert them into a single token.
TJAR turns this conversion into an open market. Fees accumulate in a Token Jar, and searchers compete to exchange a fixed amount of the chosen token for assets in the jar. The destination of the chosen token is configurable to support common patterns in DeFi, such as routing it to a treasury, burning it, or bridging it to an L1 recipient.
TJAR grew out of the infrastructure built for Uniswap protocol fees. It generalizes the protocol fee conversion and UNI burn mechanism into reusable infrastructure for any onchain system.
TJAR has been audited by OpenZeppelin and is deployed at the same addresses across multiple chains. Robinhood is using this system across its supported chains, choosing to receive its trading fees through the Uniswap API in USDC and USDG.
The onchain fee conversion problem
Fee conversion is conceptually simple, but involves operational overhead for DeFi projects. Teams often build their own infrastructure just to routinely convert assets.
TJAR outsources this work to searchers, using open economic incentives to coordinate conversion.
How it works
Each operator can deploy their own Token Jar and Releaser contracts through the TJAR Factory.
- The Token Jar: accumulates native and ERC-20 tokens
- The Releaser: defines the rules for converting these assets into the operator’s chosen token
Searchers monitor Token Jars and perform conversions when the economics become attractive.
- A searcher provides the amount of the chosen token required by the Releaser.
- The selected assets in the Token Jar are released to the searcher.
- The chosen token is sent to the configured destination, such as a treasury, bridge, or burn address.
Why searchers clear Token Jars
Economically, TJAR is a posted-price mechanism. There’s a standing offer to exchange a fixed amount of the chosen token for the accumulated assets in the Token Jar.
That amount is the release threshold, and it stays fixed until the Releaser owner changes it. Meanwhile, the value of the jar fluctuates as assets accumulate and market prices move.
As the jar fills, the value of the jar eventually becomes high enough to make a release profitable. A searcher’s surplus is the difference between the value they recover from the jar and the total cost of releasing it. That profit creates the incentive to trigger conversions.
As searchers compete for these opportunities, they act at smaller and smaller margins, allowing jars to clear more efficiently.
Choosing the release amount
The release threshold should be calibrated to how fees arrive. A lower threshold generally allows the jar to clear more frequently, reducing exposure to asset price movements.
However, lower thresholds are also more sensitive to large individual fee deposits. If a relatively large fee deposit arrives, the jar value can jump well above the value of the release threshold, increasing the surplus available to searchers.
Say a jar has a 1,000 USDC release threshold and holds $950 of assets. If a $500 fee deposit arrives, the jar’s value jumps to $1,450 while the release threshold remains 1,000 USDC. A searcher can capture a relatively large surplus, reducing the efficiency of the conversion for the operator.
Higher thresholds reduce sensitivity to individual deposits, but also cause assets to remain in the jar longer before a release, increasing their exposure to price movements.
There’s no universally optimal threshold. The right setting depends on how fees arrive, how large the deposits are, and the operator’s tolerance for price exposure. Because those conditions change, the release configuration is designed to be adjustable. The Releaser owner or a delegated config setter can update the threshold as needed.
An early use case
Robinhood is already using TJAR across its supported chains for fees collected through the Uniswap API. Its Token Jars are configured for USDC and USDG, with searchers competing to convert accumulated fees into those chosen tokens.
The same jars can also accept additional fee sources in the future without requiring changes to the conversion mechanism.
Permissionless infrastructure
Anyone can create a Token Jar and Releaser through the TJAR Factory. The Factory deploys them with the operator’s desired config and has no control over them post-deployment.
The Releaser’s owner or its delegated config setter can update parameters such as the chosen token, release threshold, and destination. The Token Jar can be paired with a new Releaser if the operator wants a different release behavior. These controls can also be relinquished entirely if the operator wants to provide a guarantee of immutability.
Seamless across chains
TJAR also supports deterministic deployment across chains. The Factory is deployed at the same address on every supported chain, and operators can deploy their Token Jars to the same address across those chains. For multichain integrations, that means using a single fee destination everywhere instead of managing a list of chain-specific addresses.
Build with TJAR
TJAR is open source, audited, and live today:
