How Centry works.
Centry is an Arc-native lending protocol built around USDC lending and borrowing, CENT governance, revenue-funded veCENT rewards, and automated self-repayment. These docs describe the live protocol architecture and the flow between its contracts.
Centry in one flow
Users supply assets to earn lending yield or borrow supported debt against collateral. CENT is the protocol token, while veCENT represents locked CENT positions as transferable NFTs. Protocol revenue can be converted into CENT and distributed to veCENT positions. Those rewards can also be routed through Centry's self-repay system to reduce supported debt automatically.
Lending markets & risk
Centry's lending pool is a multi-reserve ERC-20 market. Each reserve has its own LTV, liquidation threshold, liquidation bonus, reserve factor, supply cap, and borrow cap. Interest accrues through liquidity and borrow indexes, so supplier balances and debt balances grow over time without storing a fixed balance per account.
Deposit an active reserve and receive an interest-bearing scaled position.
Borrow supported debt only when the account remains within its collateral limits.
Unhealthy accounts can be liquidated, repaying debt and seizing collateral with the configured bonus.
Arc testnet chain ID: 5042002. The live USDC reserve uses the Arc native USDC ERC-20 interface. Development risk parameters are intentionally treated as testnet values and are not production recommendations.
CENT & veCENT
Locking CENT creates a veCENT position. A position is an ERC-721 NFT identified by tokenId, with a locked amount and a lock end time. The current implementation allows locks from 1 week up to 104 weeks. The position can be increased or extended while it is active.
CENT is escrowed in the veCENT contract and the position receives voting-power accounting over time.
A mature position can withdraw its full amount. Early withdrawal applies the protocol's configured 25% fee split.
Early withdrawal returns 75% of the locked amount. Of the 25% fee, 60% is routed to the rewards controller and 40% to the treasury. That means 15% of the original principal feeds rewards and 10% goes to treasury.
Revenue becomes funded veCENT rewards
Rewards are not a fixed token emission. Protocol revenue is acquired as CENT and funded into the veCENT revenue rewards controller. A keeper produces a Merkle allocation for an epoch, the root is queued, and the contract enforces a two-day delay before activation.
The reward position key is the veCENT NFT tokenId. The rewards controller also tracks the last owner of a withdrawn position so an already-earned allocation remains associated with the position through its lifecycle.
Automated debt repayment
A veCENT owner can configure a self-repay recipient on the rewards controller. A keeper can then claim the owner's funded reward allocation through the Self-Repay Executor V2, swap reward CENT into a supported debt asset, and repay debt in the lending pool. The executor never chooses a route by itself: keepers provide fresh swap data, minimum outputs, and the reward proof for each execution.
The executor is keeper-gated, checks supported debt assets, verifies the minimum swap output, and repays through the configured lending pool. Any reward amount not consumed by the instructions is returned to the borrower.
GitHub Actions keeps the protocol moving
Centry separates off-chain coordination from on-chain enforcement. GitHub Actions handles repeatable keeper tasks such as generating reward allocations, validating manifests, queueing epochs, activating epochs after the delay, and running the self-repay keeper flow. The contracts remain the source of truth for balances, ownership, proofs, permissions, and settlement.
Reward pipeline
Generate allocation → validate root → queue epoch → wait 2 days → activate → claim.
Keeper pipeline
Read active allocations → resolve token owner → build swap instructions → execute self-repay when debt exists.
Live Arc testnet deployment
These are the protocol addresses currently configured by the frontend.
0x90C935687D91b3352b2C55cd79389C92950D94BD0x0e33c05cc844914155B7300aA93085DBB32d4FBE0xC82424D224dbfBF9D41a9cBe5cA2AdF762572fC60x76e6d50D3151f0B4645ac0E53584F4204Fc6f0e30xdcb00Ea10FBeaaB66b88C208Ad09b58E38D6f04e0xFE791C5141ef417100Ce56624bc975DA1fBE98150x1672667EdB27fDF687A0Fe485EeE1240650dF4a9Arc native USDC: 0x3600000000000000000000000000000000000000 · EURC: 0x89B50855Aa3bE2F677cD6303Cec089B5F319D72a · Centry currently also tracks BTC and SOL collateral integrations in the frontend market configuration.
Important before using Centry
Centry is running on Arc testnet. Risk parameters, oracle configuration, reserves, and automation are still development infrastructure. Testnet behavior should not be treated as production-ready financial infrastructure.
Borrowing and liquidation safety depend on fresh, correctly normalized price data.
Independent security review is required before any production/mainnet use.
USDC limits and risk settings are development values and can change as the system is tested.
Keepers coordinate execution, but the contracts verify proofs, permissions, outputs, and repayments on-chain.