CAP on BNB Chain

Cap (CAP): A Stablecoin and Covered-Credit System Built Around Shared Security

Cap combines a reserve-backed dollar token, a yield-bearing savings token, and a collateralized credit marketplace. CAP is positioned mainly as a governance and protocol-integration asset, while the system’s core activity runs through cUSD, stcUSD, vaults, operators, underwriters, and external security networks.

What Cap is designed to do

Cap describes itself as a platform for USD yield, private credit, and financial guarantees. Its primary user-facing products are cUSD, a dollar-denominated token issued against approved reserve assets, and stcUSD, a yield-bearing token received when users stake cUSD. The protocol documentation lists reserve assets such as USDC, USDT, pyUSD, BUIDL, and BENJI, and says cUSD is intended to be redeemable against available reserve assets at a 1:1 value. These are project descriptions, not an independent assurance that every redemption or reserve claim will hold under stressed conditions.

The core architecture

Cap’s contracts are organized into several modules rather than one lending pool. The Vault stores reserve assets, issues and burns cUSD, tracks utilization, and supplies liquidity to borrowers. The Lender manages borrowing, repayment, interest accounting, and liquidation. The Delegation module connects borrowers to shared-security networks, while oracle contracts provide prices and interest-rate inputs. A fee-auction system converts collected yield and fees into cUSD before distributing proceeds according to the protocol’s configured rules.

For ordinary depositors, the key distinction is between cUSD and stcUSD. cUSD represents the dollar-denominated reserve position, while stcUSD represents staked cUSD and is intended to accrue returns from idle reserves and loans made to approved borrowers. The documentation says idle capital can be deployed into strategies such as Aave V3, while other capital may be borrowed by covered operators. This creates dependency on reserve-asset issuers, external lending venues, oracle feeds, and the operational performance of the borrowers.

How shared security supports credit

Cap’s distinctive mechanism is its use of shared-security networks such as Symbiotic and EigenLayer. A borrower cannot access the vault merely by requesting a loan; the borrower must be registered and obtain delegated collateral from an underwriter or delegator. That delegated collateral determines borrowing capacity and can be slashed if the borrower’s health factor falls below its liquidation threshold. The design attempts to separate the person or institution generating yield from the users providing reserve liquidity, with underwriters accepting borrower-specific risk in exchange for a premium.

The liquidation process is intended to be permissionless and onchain. Cap’s documentation describes a health-factor calculation based on delegated collateral, liquidation thresholds, and outstanding debt. If a position becomes unhealthy, liquidators can open and execute liquidation, with delegated collateral used to cover the resulting shortfall. The model is not equivalent to a conventional overcollateralized retail lending market: it depends on correct oracle data, functioning shared-security integrations, enforceable borrower arrangements, and enough liquid collateral to cover losses.

What CAP does, and what it does not do

The official documentation identifies CAP as a separate token from cUSD and stcUSD. The protocol’s fee-receiver design includes a cap-token address and a staked-cap-token address, with fee distributions directed to staked token holders under the configured system. The available documentation also describes CAP-related protocol integration and governance functions, but it does not establish that CAP is required to mint cUSD, borrow from the vault, or receive the underlying reserve assets. Those activities are primarily defined through cUSD, stcUSD, vault permissions, borrower registration, and delegated collateral.

The current official address page lists the Cap Token contract on Ethereum Mainnet as 0x99991c6AAbba5a096f24f250b73580F5179b9999. It does not list a BNB Chain CAP contract in the inspected address tables. That matters for the asset record supplied to YearBull: the BNB Chain label should be independently reconciled against the project’s current deployment information before readers treat a BNB Chain token address as official. The same page lists cUSD, stcUSD, the lender, oracle, delegation, fee-auction, access-control, and timelock contracts on Ethereum.

Control, upgrades, and practical dependencies

Cap uses granular function-level access control. Different roles can manage oracle settings, vault assets, delegation parameters, fee auctions, pauses, and emergency functions. The documentation states that roles are managed by the Cap multisig and that critical administrative operations pass through a TimelockController with a one-day minimum delay. This provides a visible review window for certain changes, but it is still an administrative control structure rather than token voting proved by the inspected contract documentation.

The system also depends on multiple external components. RedStone and Chainlink are identified as price-data sources for different classes of assets, Aave is used for some rate information, and Symbiotic or EigenLayer provide shared-security infrastructure. Cap’s open-source contract repository contains the core Solidity code and test commands, but the existence of a public repository is not evidence that the deployed system is free of vulnerabilities. Users also face ordinary smart-contract, stablecoin, oracle, bridge, counterparty, liquidity, and governance risks across the connected components.

Key takeaways

• Cap is centered on cUSD and stcUSD, with CAP serving a separate token role.
• The credit model uses delegated collateral and shared-security networks to cover approved borrowers.
• Liquidation protection depends on health factors, oracle inputs, liquid collateral, and functioning external networks.
• Cap’s current official address page identifies the CAP token on Ethereum Mainnet, not BNB Chain.
• Administrative permissions, multisig control, timelocks, and whitelisting remain important parts of the operating model.

Risks and open questions

• The supplied BNB Chain classification is not confirmed by the current official address page, which lists the CAP token under Ethereum Mainnet.
• CAP’s current supply schedule, vesting status, and circulating distribution were not established from the inspected official pages.
• The system depends on external stablecoin issuers, oracle providers, Aave, shared-security networks, and borrower or underwriter performance.
• Whitelisting, multisig administration, emergency permissions, and upgrade controls create governance and operational concentration risks.
• The project’s claims about credible guarantees remain dependent on contract correctness, collateral sufficiency, liquidation execution, and legal or contractual arrangements involving participants.