For readers who need to separate institutional vault accounting from retail “farm hopping,” Concrete modularizes deposit, accounting, strategy routing, and redemption instead of asking users to stitch protocols by hand. Per DefiLlama · Concrete at writing time, TVL is about $1.261B, 30D Fees about $2.34M, and 30D Revenue about $49K, under the Onchain Capital Allocator category; total funding is $17M with backers including Polychain, YZi Labs, and Hashed. Step-by-step deposit and redeem flows live in a companion How-to; the sections below cover definitions, mechanics, and boundaries.
Concrete, built by Blueprint Finance, is on-chain yield infrastructure for institutions and protocol-side asset managers. The Concrete Protocol positions itself as an operating layer that packages vaults, strategy adapters, permissions, fees, and distribution so teams can embed yield for crypto assets and RWAs—not a single farming front-end.

The friction it targets is operational: manual DeFi often means picking venues, migrating liquidity, and keeping books, while custody-bound institutions face “assets that cannot leave” constraints. Strategy selection, NAV accounting, and redemption cadence rarely sit in one place, which is why vault infrastructure helps. Concrete turns those jobs into vault modules and permissioned flows so depositors hold composable shares while strategy execution and bookkeeping sit at the vault and strategy layers.
The CT token contract is live on Ethereum at 0x0A092E544DA31150b439a1aAA1A3a2214a867F46 (verifiable on Etherscan). Learning Concrete means keeping the product layer and the CT token layer distinct: the former governs deposits and accounting; the latter governs how configuration rights are allocated.
Typical path: a user deposits a single underlying into an ERC-4626 vault → the vault mints ct[asset] shares (for example, ctWBTC) at the current rate → an allocator pushes assets into one or more strategy adapters → strategies earn or lose value in lending, looping, or custodied venues → total assets move the share exchange rate → redemption returns underlying at the updated rate.
Share accounting is the key: share counts usually do not increase over time; what changes is how much underlying each share can redeem. Curators configure strategies; vaults handle custody, accounting, and access control and do not hard-code a single yield source. In short, the flow is deposit → shares → strategies → rate → redeem; it helps to check the displayed NAV or exchange rate before each signature.
Three ERC-4626 implementations: Atomic (deposit and withdraw in one transaction), Queued Withdrawal (epoch queues that lock a share price and reserve assets before claim—the common production pattern), and Pre-deposit / Cross Chain (source-chain deposit, bridge, then claim shares on the destination). Vaults may also enforce deposit caps and per-tx or per-user limits; over-limit transactions fail. Later Earn versions (including Earn v2-style modules in operator docs) still use the same share-and-rate accounting, even when operator roles or strategy modules expand.

Figure 1. Concrete Earn deposit path: Deposit → ERC-4626 Vault → Strategies → ctAsset; share count usually stays fixed while the exchange rate reflects yield.
Four product lines cover different entry points—from standard deposits to custody-backed representation—while sharing the same vault accounting and strategy framework.
| Product | Primary audience | Core job | Key trait |
|---|---|---|---|
| Earn | Depositors seeking automated yield | Deposit once; quantitative and strategy layers allocate, rebalance, and compound | Standardized vault yield UX |
| Vaults | Protocols, issuers, managers | ERC-4626 vault infrastructure and module composition | Atomic / Queued / Pre-deposit implementations |
| Enterprise | Institutions and industry clients | Institutional vault ops, permissions, and control workflows | Compliance- and operations-oriented |
| AssetCX | Institutions with qualified custody | 1:1 on-chain representation of custodied assets into permissioned vaults | Underlying can remain in qualified custody |
Under DefiLlama’s methodology, Fees measure yield generated by vault strategies for depositors (including exchange-rate growth) plus related protocol fees and partner rewards; Revenue measures management and performance fees collected by the protocol as vault shares. Fees therefore usually dwarf Revenue: the former is closer to “depositor-side total yield,” while the latter is protocol take. The Onchain Capital Allocator category frames Concrete as an on-chain capital-allocation and vault-orchestration layer rather than a single lending market.
Earn covers standard deposits and automated yield; Earn / Earn v2 modules in the docs still focus on what happens after a single deposit into a managed vault. Vaults, Enterprise, and AssetCX then extend access depth for protocols and institutions. Blueprint Finance has disclosed about $17M in funding (backers include Polychain Capital and others), which helps explain the institutional infrastructure focus—not a performance forecast.

Figure 2. Concrete product stack: how Earn, Vaults, Enterprise, and AssetCX divide roles on the same yield infrastructure.
AssetCX’s boundary matters: clients move assets to a designated wallet that remains inside the custodian account; Concrete mints AssetCX 1:1 against that custody balance and deposits it into a vault, issuing ERC-4626-style share receipts while the underlying can stay in qualified custody. On the Earn app, AssetCX vaults often use [asset]cx naming and show “Permission Required”; participation typically needs a separate request rather than open public minting.
CT is the native governance and configuration token of the Concrete ecosystem: a fixed-supply, non-inflationary ERC-20 on Ethereum. Eligible holders who lock CT may participate in defined protocol-parameter governance (strategy approvals, collateral classifications, fee frameworks, treasury-related policies, and related module settings). Staking CT may unlock configuration features such as adjustments to certain protocol-side fees on the staker’s own interactions with supported modules. The Concrete Foundation coordinates governance and the CT treasury; issuance and white-paper disclosure proceed through the relevant entities under applicable rules.
| Dimension | CT token | ct[asset] vault shares |
|---|---|---|
| Nature | Governance and configuration token | ERC-4626 deposit receipt |
| How obtained | Market circulation / ecosystem allocation | Deposit the underlying into the matching vault |
| What value tracks | Token supply/demand and governance utility | Vault NAV × share exchange rate |
| Link to yield | Not the same as a vault deposit claim | Redeem underlying at the then-current rate (P&L included) |
| Examples | CT | ctWBTC, ctDefiUSDT, and similar |
A common mistake is equating buying CT with “entering a vault to earn yield.” The clean boundary is: CT primarily confers governance/configuration capabilities; ct[asset] corresponds to a claim on a specific vault’s assets. Both can exist in the same ecosystem, but they are different accounting objects and different risk exposures.
Manual farming usually means choosing venues, migrating liquidity, and tracking incentives and liquidation risk, with each rebalance as a separate operational step. Concrete Protocol standardizes accounting and strategy interfaces: users mainly hold a single vault share, while routing sits with allocators and curator configuration; differences show up mainly as redemption cadence (atomic / queued / cross-chain pre-deposit).
Contrast dimensions include interface complexity, accounting transparency (ERC-4626 rates), liquidity boundaries, and permission models (open pools vs Enterprise / AssetCX). Concrete does not remove strategy risk; it concentrates execution and accounting at the vault layer so performance, returns, and share NAV can be reviewed in one place. Before increasing deposit size, check redemption type, caps, and venue risk.
On the advantage side: ERC-4626 shares are easier to compose and reconcile; multiple strategies can coexist in one vault; Queued Withdrawal fits custody-heavy flows; AssetCX lets hard-to-move custodied assets gain on-chain yield representation; public dashboards support checks of TVL, Fees, and Revenue definitions.
On the risk side: smart-contract and permission risk; strategy losses that lower exchange rates; queued-redemption delay; cross-chain bridge risk; custody and access dependencies for AssetCX / Enterprise; CT utility that depends on governance rollout and does not automatically hedge vault losses. Public trading of CT also requires verifying the official site and disclosed contract against spoofed assets.
CT trades on Gate as CT/USDT spot via the CT/USDT spot page. Spot fills settle in the exchange account and are for buying or selling CT; they do not deposit assets into a Concrete vault.

Keep the two paths separate: Gate spot holdings are CT; on-chain Concrete Earn deposits mint ct[asset] and expose users to vault strategies. When studying yield mechanics, do not mix the traded token with the deposited asset. If the goal is a transferable governance token, use spot and verify contracts and networks; deposit, withdrawal, and convert rules follow Gate’s live pages and are not yield or price promises.
Concrete (CT) places institutional vaults, strategy adapters, custody representation, and a governance token in one frame: deposits mint ct[asset], strategies move the exchange rate; Earn / Vaults / Enterprise / AssetCX map to different access depths; CT handles governance and configuration and must not be read as a vault share. Separate Fees from Revenue on DefiLlama; trading CT on Gate and using Earn on-chain are different paths. Concrete Protocol prioritizes shared vault accounting and orchestration before strategy choice—buying CT is not the same as completing a vault deposit.
Concrete is full-stack on-chain yield infrastructure (the Concrete Protocol), with products spanning Earn, Vaults, Enterprise, and AssetCX, centered on ERC-4626 vaults and strategy orchestration. CT is the ecosystem governance and configuration token on Ethereum. Keep the product layer distinct from the CT token layer; without shared share accounting, each venue needs its own books and redemptions—which is why vault infrastructure matters.
Users deposit an underlying asset into an ERC-4626 vault and receive ct[asset] shares; share counts usually stay fixed while strategy P&L shows up in the exchange rate. The vault handles custody, accounting, and permissions; strategy adapters allocate assets into venues. Redemption returns underlying at the then-current rate and may be atomic or queued for later claim. Shared vault accounting is closer to institutional infrastructure than to another single-market farming front-end.
CT is a governance and configuration token. Eligible holders who lock CT may vote on defined parameters such as strategy approvals and fee frameworks; staking CT may unlock configuration features such as protocol-side fee adjustments on the staker’s own module interactions. CT is not automatically a claim on a specific vault’s deposit yield—that claim sits with ct[asset] shares.
No. A ct[asset] token is an ERC-4626 share receipt from a specific vault and tracks that vault’s net asset value; CT is the ecosystem governance and configuration token that trades separately. Buying CT does not mint ctWBTC, and depositing WBTC does not convert the deposit into CT.
Key risks include smart-contract and permission risk, strategy losses that lower exchange rates, queued-redemption and cross-chain delays, custody and access dependencies for AssetCX/Enterprise, and liquidity plus spoofed-contract risk when trading CT publicly. Fees and Revenue differ: Fees are closer to depositor-side strategy yield, while Revenue is protocol take.
* The information is not intended to be and does not constitute financial advice or any other recommendation of any sort offered or endorsed by Gate.
* This article may not be reproduced, transmitted or copied without referencing Gate. Contravention is an infringement of Copyright Act and may be subject to legal action.





