Centry is an Arc-based onchain capital application focused on lending, collateralized borrowing, swaps, bridge liquidity, portfolio visibility, and user-owned automation.
Arc · Chain ID 5042USDC · EURC · cirBTCNon-custodial
Centry brings core onchain capital actions into one account-driven experience. Users can supply supported assets, borrow against collateral, swap supported tokens, move USDC between configured networks, and monitor the resulting position from a single application.
The application is non-custodial: the wallet remains the signing authority, while Centry's contracts and validation layers enforce the rules around supported assets, risk, permissions, and execution.
01Fund
Start with assets in the connected wallet or an eligible funding route.
02Supply
Supply an active reserve and receive a live lending position.
03Borrow
Borrow supported liquidity while staying inside the account's collateral limits.
04Manage
Swap, bridge, repay, or monitor the position as conditions change.
02
LENDING
Markets built around collateral.
SUPPLY
Earn lending yield
Users supply assets into active reserves. The lending pool tracks scaled balances and applies the reserve's interest model over time.
BORROW
Borrow against collateral
Borrowing is constrained by the account's live borrow capacity, reserve liquidity, and the configured risk parameters for the market.
RISK
Risk stays onchain
Loan-to-value limits, liquidation thresholds, reserve caps, oracle checks, and repayment accounting are enforced by protocol logic.
Centry uses validated swap infrastructure rather than arbitrary contract calls. Cask and the application only prepare supported swap paths using configured token addresses and fresh route data.
BRIDGE
USDC liquidity routes
Configured bridge routes support USDC across Arc, Base, Arbitrum, and Ethereum. Fees, route state, and timing should always come from the current transaction or bridge preview.
GATEWAY
Pending liquidity is not spendable liquidity.
Gateway balances are separated into finalized and pending amounts. Centry only treats finalized liquidity as available for supported account actions.
04
ACCOUNT & DATA
See the position as it actually exists.
The Overview and Portfolio surfaces combine wallet balances, supplied assets, debt, borrow capacity, health, market composition, and reserve information. Market pages expose the same underlying account and reserve state in a more focused workspace.
Analytics are designed around current protocol and market data. The application does not need a separate historical analytics story to explain the position shown today.
OVERVIEW
Account snapshot
A quick view of supplied value, debt, net position, health, and active markets.
PORTFOLIO
Position composition
See collateral, debt, available capacity, and the assets making up the account.
MARKETS
Reserve health
Compare supply and borrow rates, liquidity, utilization, and market-specific risk.
05
CASK
A Centry assistant, not a wallet.
Cask is Centry's conversational interface. It can answer general questions about the project, explain supported features, and use verified application data when a connected account is available.
A wallet is only required for personal state or a state-changing action. For a transaction, Cask prepares a supported transaction plan and opens the wallet signing flow. The user remains responsible for approving the transaction.
BOUNDARY
No arbitrary execution.
Cask does not receive the owner's private key and does not create arbitrary calldata, contract targets, token addresses, recipients, or hidden transaction parameters.
06
AGENTS
User-owned automation with explicit permissions.
Centry agents use user-owned smart accounts. The owner controls activation and operator authorization, while supported automation runs through scoped actions and onchain permission checks.
The runtime coordinates scheduled work, owner requests, activity, and execution receipts. Offchain services coordinate the work; the smart account remains the enforcement boundary for what an operator is allowed to execute.
OWNERSHIP
You keep control
The smart account has an owner and a separate operator model. Chat does not change ownership or silently broaden permissions.
PERMISSIONS
Actions are bounded
Supported functions, expiration, native-value limits, and financial caps can be enforced before execution.
A2A
Agent-to-agent opt-in
Incoming agent tasks require the recipient to opt in, with optional sender allowlisting.
07
SECURITY
Validation before execution.
APPLICATION
Fresh state checks
User-specific transaction plans use verified account and market state rather than treating browser-provided values as authoritative.
ONCHAIN
Contract enforcement
Permissions, financial limits, supported recipients, protocol spenders, and execution rules are enforced at the smart-account boundary.
RUNTIME
Short-lived authorization
Hosted agent permissions are designed to expire rather than remaining active indefinitely through the normal configuration flow.
DATA
Signed service traffic
Internal agent-store requests use timestamped HMAC signatures with replay protection instead of an always-on bearer header.
IMPORTANT
Protocol configuration is still live infrastructure.
Oracles, reserves, risk parameters, deployed contract addresses, and automation services should be checked against current application and onchain state before relying on them.
08
REFERENCE
Core contracts.
These addresses are the core contracts currently referenced by the application. Token and reward-system contracts are intentionally kept out of the core reference and documented separately below.
The token and voting layer is intentionally separated from the core Centry product discussion. When this area is enabled, it will cover the protocol token, locked voting positions, revenue-funded rewards, claims, and the governance system around them.
CENT
Protocol token
The CENT token is the protocol's reward and governance asset. Its user-facing flows are kept separate from the current lending and capital-management experience.
veCENT
Locked voting positions
veCENT represents locked token positions used for voting and reward accounting. Detailed locking, voting, and position lifecycle docs will live here when the feature is released.
REVENUE REWARDS
Funded rewards
Revenue can feed a rewards system that allocates rewards to eligible locked positions through an auditable epoch-based process.
GOVERNANCE
Protocol voting
Governance documentation will cover voting power, proposal flow, timelocks, and execution once those controls are part of the active product.
COMING SOONSeparate from the current Centry lending experience.