Security Approach

Osito Protocol's security model is built on calculating safe lending limits without relying on external price feeds or oracles. By focusing on verifiable on-chain data and worst-case scenarios, the protocol aims to maintain solvency under all market conditions.

Key Security Design Principles

Osito approaches security differently than many traditional lending protocols:

This approach eliminates several common security concerns in DeFi lending.

Security Advantages

1. No Oracle Dependence

Traditional lending protocols typically rely on oracles for price data:

Traditional: Collateral Value = Token Balance × Oracle Price

Oracles can potentially be manipulated, delayed, or fail during market volatility.

Osito's approach avoids this dependency:

Osito: max_borrow = pool_BERA - extractable_BERA

By using real-time AMM pool data rather than reported prices, the protocol eliminates oracle-related risks.

2. Minimal Governance Requirements

Many protocols rely heavily on governance for security parameters:

Traditional: if (governance.isApproved(token)) allow_collateral(token);

Osito reduces governance requirements through objective criteria:

Osito: if (token.hasFixedSupply() && token.hasBurnedLP()) allow_collateral(token);

With fewer governance decisions, there are fewer subjective judgments required for the protocol to function.

3. Protection Against Market Manipulation

The protocol includes safeguards against market manipulation:

Osito:
// At key operations:
_updateWberaRate();
_updateTokenState(token);
_updatePosition(positionId);
uint256 maxBorrow = calculatePositionMaxBorrow(positionId);

By recalculating security parameters at each significant operation, the protocol can adapt to changing market conditions.

Focusing on Worst-Case Scenarios

Osito's security approach centers on preparing for extreme scenarios:

1. It calculates what would happen if all circulating tokens were sold at once
2. It ensures loans never exceed what could be extracted in that scenario
3. It updates these calculations in real-time as conditions change

This conservative approach helps maintain protocol solvency even during significant market stress.

Security Properties

This design creates several important security properties:

1. Solvency Protection

The protocol works to maintain solvency because:

Total Borrows ≤ Sum of all max_borrow limits
max_borrow ≤ pool_BERA - extractable_BERA

This means that even if token prices drop dramatically, the protocol should have sufficient BERA to cover all loans.

2. Objective Security Parameters

Rather than relying on subjective risk assessments:

Traditional: max_ltv = governance.decide_safe_value(); // Subjective

Osito uses calculations based on verifiable on-chain data:

Osito: max_borrow = pool_BERA - (pool_BERA * pool_tokens) / (pool_tokens + dumpable_tokens); // Based on actual pool data

This provides more transparent and consistent security parameters.

3. Permissionless with Safety Constraints

The protocol allows any token meeting the objective criteria to be used, while maintaining security through the mathematical borrowing model. This balance enables permissionless expansion while still protecting protocol solvency.

Remaining Trust Assumptions

While Osito reduces many trust assumptions, some necessarily remain:

1. Fixed Supply Verification

The protocol trusts that tokens from whitelisted deployers have fixed supply. This is mitigated by:

• Using established token factories
• Requiring verifiable code
• Focusing on the specific property needed for security calculations

2. AMM Pool Behavior

The protocol relies on AMM pools functioning according to their specifications. This is mitigated by:

• Supporting different pool types with appropriate calculations
• Directly querying pool state rather than using intermediaries
• Working with established AMM implementations

Key Benefits

The Osito security approach provides several benefits:

1. Reduced External Dependencies: Less reliance on oracles and governance
2. Permissionless Integration: Any token meeting criteria can be used
3. Transparent Security: Security parameters based on verifiable calculations
4. Market Stress Resilience: Designed to handle significant market volatility