Concave is a Historical Staking Term and Withdrawal Workflow

Concave is best understood here as a former Ethereum staking workflow that locked ERC-20 CNV for a chosen term and issued an ERC-721 position NFT. A holder connected a wallet, approved CNV, selected a duration from 45 to 365 days, confirmed the lock and later used the recorded position to retrieve the matured balance.

The original front end no longer serves the protocol interface, so the sequence below explains the on-chain design rather than inviting a new deposit. Its focus stays on term selection, position confirmation and the withdrawal timeline.

The two-transaction entry path

A first Concave position normally required two Ethereum transactions: one ERC-20 approval and one lock call that created the staking NFT in the connected wallet. Approval established an allowance for the staking contract, while the later call moved the selected CNV amount into a distinct position.

Each call consumed ETH as Ethereum gas, but the protocol did not set a flat currency fee for the pair. The first cost equalled the approval's gas used multiplied by its effective gas price; the second used the same formula for the lock call. A wallet with enough existing allowance skipped the approval, leaving one state-changing transaction. CNV also implemented an EIP-2612 permit function, although support at token level did not mean the historical interface combined authorization and locking into one signature for this workflow.

Only the lock confirmation created the position, so an approval by itself never started the staking term.

Wallet and asset prerequisites

The historical Concave flow needed an Ethereum account, CNV in that account and enough ETH to authorize and submit the required contract calls.

Prerequisite setup

Three balances mattered before term selection: spendable CNV, available token allowance and ETH reserved for Ethereum execution.

Wallet and network

MetaMask, Rabby Wallet or a WalletConnect-compatible interface could present the Ethereum account used for the position. A Ledger device could protect the same account while the browser wallet prepared each call. Ethereum mainnet used chain ID 1, and its addresses contained 20 bytes, conventionally displayed as 40 hexadecimal characters after the 0x prefix.

CNV and transaction capacity

The CNV balance had to cover the chosen deposit in token units. CNV followed the ERC-20 model with 18 decimal places, making 0.000000000000000001 CNV its smallest representable unit. ETH paid network execution costs for the approval, lock and eventual withdrawal. That ETH was separate from the staked amount and did not become part of the position.

How did the term selector change the position?

The Concave term selector fixed the maturity timestamp and assigned the deposit to the reward treatment associated with that chosen duration for its full life. A longer selection postponed withdrawal and placed the position in the longer-term side of the staking design.

The selector therefore controlled a calendar commitment rather than a cosmetic preference. The amount field determined how much CNV entered the contract, while the duration determined when that position reached maturity. The displayed reward treatment reflected the selected term and protocol accounting; it did not lock the market value of CNV or promise a fixed currency outcome. Once the wallet confirmed the lock transaction, the on-chain record carried the operative choice, even if the browser later closed or displayed stale data.

The 45-day and 365-day calendars

Concave measured its documented lock range from 45 days at the short end to 365 days at the long end for each position. The staking range set 45 days as the minimum term and 365 days as the maximum term.

Converted into contract-friendly time units, 45 days contained 3,888,000 seconds and 365 days contained 31,536,000 seconds. The distance between those endpoints was 320 days, equal to 27,648,000 seconds. The contract derived maturity from the recorded start time and chosen duration, so the same nominal term selected on different dates produced different calendar maturity dates.

A term ended at its recorded timestamp, not at the start of the calendar day shown by a local wallet.

The commitment encoded by the signature

The lock signature committed one CNV amount and one duration to a single wallet-owned position through one state-changing contract call on Ethereum. The wallet displayed the contract interaction before broadcasting it, and rejecting that request left the account unchanged.

After acceptance, Ethereum ordered the call and the staking contract processed its parameters. A successful execution transferred the approved CNV, created the position record and minted its NFT to the account. A failed execution created no usable position, even when the browser still displayed the previously entered amount or term. The transaction receipt therefore separated a prepared request from a completed lock, while the emitted token transfer showed which account received the new position.

What appeared after the lock confirmed?

After the Concave lock confirmed, the wallet received one Liquid Staked CNV ERC-721 token that represented that individual staking position on Ethereum. Its token ID distinguished the deposit from every other position in the same account.

CNV used 18 decimal places, while each Liquid Staked CNV position used one ERC-721 token ID. An ERC-721 token ID occupies a uint256 field, giving the identifier a 256-bit numerical range. The NFT represented ownership of the recorded position; it did not replace CNV with another fungible balance. Two locks from one wallet therefore produced two separately identifiable records rather than one blended staking entry.

A wallet thumbnail was only a display layer. The ERC-721 ownership record, contract data and successful mint event provided the durable confirmation, all of which Etherscan could present independently of the former interface.

Reading the position record

The Concave position record combined three facts needed for withdrawal: the NFT owner, the deposited CNV amount and the maturity time stored on-chain. Reading those fields together established who controlled the position, what it represented and when its exit path opened.

Ownership and amount

The ERC-721 owner field identified the account authorized to act on that token ID. The amount field represented CNV in 18-decimal base units, so an interface divided the stored integer by 10 ¹⁸ for human-readable display. A transferred NFT retained its token ID and position data while ownership moved to the receiving Ethereum account.

Start and maturity timestamps

The timing fields used Unix-style timestamps counted in seconds. Subtracting the start timestamp from maturity yielded the selected duration, while comparing maturity with Ethereum's block timestamp established eligibility for withdrawal. Local time-zone formatting could change the displayed clock time without changing the stored value.

Maturity did not extend itself when the owner took no action. The position simply moved from locked status to an eligible state until its owner submitted the required exit call.

When did withdrawal become available?

Withdrawal became available when the position's recorded maturity time had passed, after which the owner still had to submit an Ethereum transaction. Reaching that timestamp changed eligibility; it did not send CNV to the wallet automatically.

A call submitted before maturity reverted and released no balance, while Ethereum still charged gas for the attempted execution. At or after maturity, the account controlling the ERC-721 position could invoke the exit path for that token ID. The contract then applied its position accounting and returned the redeemable CNV through the successful call. This made the maturity timestamp the earliest contract boundary, while actual receipt depended on a later included transaction. The adjacent topic is explained in Concave review steps.

The clean withdrawal sequence

The clean Concave exit used the matured NFT as the position key, then returned the redeemable CNV through one owner-authorized contract call. Five concrete conditions defined whether that call matched the intended position:

• The connected account matched the ERC-721 owner for the selected token ID.
• The wallet showed Ethereum mainnet with chain ID 1.
• The stored maturity timestamp had already passed.
• The account held enough ETH for one state-changing withdrawal call.
• The submitted token ID matched the position amount shown before signing.

After inclusion, the receipt showed whether the call succeeded and whether CNV returned to the owner. The wallet could refresh its fungible balance later, so the transaction status and token transfer supplied the immediate confirmation. Each separately minted position required its own position-specific exit action.

Why a matured position still needed action

A matured Concave position did not push CNV to its owner automatically; maturity only opened the contract path that the owner could execute. This pull-based sequence kept the final timing and gas payment attached to the owner's transaction.

Broadcasting the call produced a transaction hash before Ethereum included it. That hash contained 32 bytes and appeared as 64 hexadecimal characters after the 0x prefix, giving the holder one stable identifier for the pending and completed states. Successful inclusion changed the contract record and returned the calculated balance. A pending transaction had not completed either step, regardless of what the browser button displayed.

Confirmation and the historical interface

Ethereum confirmation completed the Concave workflow, while the discontinued original front end means the sequence now serves as a historical contract reference for existing records. Block inclusion established the immediate result, and network finality added stronger settlement afterward.

Ethereum separated inclusion from finality. A slot lasted 12 seconds and an epoch contained 32 slots. Under normal validator participation, finality followed after two epochs, or 768 seconds and about 12.8 minutes. Wallets commonly showed the NFT or returned CNV after inclusion, before that stronger settlement point. Etherscan exposed the transaction status, logs and token transfers, which let the holder distinguish a pending call from an included one without relying on the retired Concave screen. The receipt also carried a 32-byte hash that remained stable as the lookup key.

An existing position remains an Ethereum contract record rather than an account on the former website. Its owner, token ID, amount, maturity and transaction status provide the data needed to understand the position's final state and complete an eligible withdrawal through a compatible contract interface.