The problem Sentinel-AMM solves

The Problem It Solves
Providing liquidity on Uniswap V3 is an expert-level task, fraught with technical and financial challenges. Our project provides a direct, technical solution to these core issues.

1. 📉 Amplified Divergence Loss
   In concentrated liquidity, the financial loss resulting from asset price divergence (Impermanent Loss) is significantly amplified when the spot price moves outside the LP's active [tickLower, tickUpper] range. A passive or slow strategy guarantees suboptimal returns or even losses.

2. ⏳ Capital Inefficiency & Latency
   When liquidity is out-of-range, it becomes "dead capital"—deployed on-chain but generating zero fees. Manual rebalancing is reactive; it happens after the price has already moved, leading to periods of inefficiency and missed fees.

3. 💸 Prohibitive Gas Costs
   The process of rebalancing a position (burn, collect, mint) is a gas-intensive operation. For many users, the cumulative gas costs can exceed the fees earned, making active management economically unviable.

4. 🚨 Centralization & Security Risks
   Automated strategies often depend on centralized off-chain scripts. This creates two critical failure points:

Downtime Risk: If the central server goes down, the entire strategy halts, leaving positions exposed.

Security Risk: The on-chain contract must blindly trust the off-chain server. A bug or malicious attack on the API could command the contract to move liquidity to a disastrous range, causing a total loss of funds.

How Sentinel AMM Makes Liquidity Provision Easier & Safer
Sentinel AMM is an autonomous, on-chain vault that abstracts away this complexity and risk. It provides a technical solution to each of the problems identified above.

✅ For The User: A "Deposit & Forget" Vault
Sentinel AMM makes providing liquidity easy. Users no longer need to perform complex calculations for tick ranges or sqrtPriceX96 conversions. They simply deposit their assets (e.g., WETH and USDC) into the SentinelAMM contract, and the vault handles all interactions with Uniswap V3 automatically.

🧠 For Profitability: A Proactive, AI-Driven Strategy
Instead of reacting to past prices, our system is proactive. It uses an off-chain LSTM neural network to forecast the likely future trading range. By positioning liquidity where the price is going to be, it aims to maximize the time capital is active and earning fees.

🛡️ For Security: The On-Chain "Safety Guardrail"
This is our most critical innovation. We solve the "Blind Trust" problem by creating a trust boundary on-chain. The SentinelAMM contract does not blindly execute the AI's command. First, it calls latestRoundData() on a Chainlink Price Feed to fetch the current, tamper-proof market price. It then performs an on-chain validation:

Solidity

function updatePredictionAndAdjust(
int24 predictedTick,
uint256 predictedPrice_8_decimals
) external nonReentrant onlyAuth {

// --- Sentinel Safety Guardrail ---
// 1. Fetch trusted on-chain price from Chainlink
(, int256 currentChainlinkPrice_8_decimals, , , ) = priceFeed.latestRoundData();

// 2. Validate that the AI prediction is within a safe threshold (e.g., 10%)
require(
    predictionIsCloseToChainlinkPrice(
        predictedPrice_8_decimals,
        currentChainlinkPrice_8_decimals
    ),
    "Sentinel: Prediction deviates too much!"
);

// 3. Only if validation passes, proceed with the strategy...
_adjustLiquidity(...);

}

⚙️ For Reliability: Decentralized Execution
We solve the "Centralized Server" problem by replacing fragile cron jobs with Chainlink Automation. Our AutomationTrigger contract is called reliably by Chainlink's decentralized network of nodes at a predefined interval. This guarantees that the strategy rebalancing logic is executed consistently and on time, making the entire system more robust and trust-minimized.

Challenges I ran into

🧗‍♂️ Challenges I Ran Into
Building a robust system that bridges off-chain intelligence with on-chain execution presents unique and complex challenges. Our primary hurdles were not in the core logic itself, but in creating a reliable testing environment and ensuring seamless identity management across the full stack.

🎯 Challenge 1: The On-Chain Data Dilemma
The Hurdle: Testing with Live Oracles
Our Goal: To test our contract's most critical feature, the "Safety Guardrail," which validates AI predictions against a live Chainlink Price Feed.

Our Approach: Use Hardhat's mainnet forking to get a live copy of the Uniswap and Chainlink contracts.

The Problem: The Unreliability of Forked State
💥 RPC Failures: Public RPC endpoints frequently failed to return the specific state for the Chainlink oracle contract, causing our tests to be slow and flaky.

❌ Stale Data: When pinning the fork to older blocks, the Chainlink oracle data was often unavailable, blocking our ability to test the full logic.

The Solution: A Hybrid Testing Strategy
💡 Our Insight: We needed the best of both worlds—live protocol interaction without the dependency on a live oracle.

✅ The Fix: We implemented a professional hybrid strategy:

1. Forking for Uniswap: We kept mainnet forking enabled only to interact with the complex Uniswap V3 protocol for realistic swaps.
2. Mocking for Chainlink: We completely decoupled our tests from the live oracle by creating and deploying our own MockAggregatorV3.sol. Our smart deployment script automatically uses this mock in the test environment.

Solidity

// contracts/mocks/MockAggregatorV3.sol
contract MockAggregatorV3 {
// Our mock always returns a predictable, fixed price.
int256 private constant MOCK_PRICE = 2440 * 10**8;
function latestRoundData() external view returns (uint80, int256, ...) {
return (1, MOCK_PRICE, ...);
}
}

This approach made our tests fast, 100% reliable, and deterministic.
🔐 Challenge 2: Aligning On-Chain & Off-Chain Identities
The Hurdle: Enforcing Smart Contract Security
Our Goal: Our system has a strict security model. Key functions are protected with onlyOwner modifiers. We needed our off-chain Python script to have the correct permissions to call these functions.

The Problem: Signer Identity Mismatch
💥 The Error: We repeatedly encountered Ownable: caller is not the owner reverts.

❌ The Root Cause: We discovered a mismatch between the identities used during deployment versus testing. The deployment script was using Hardhat's default account (0xf39...) as the owner, but our Python test script was using a different account from our .env file to call the functions. Our contracts were working perfectly by rejecting these unauthorized calls.

The Solution: Unifying the Signer Across the Stack
💡 Our Insight: The "deployer" and the "caller" must be the same identity throughout the entire workflow.

✅ The Fix: We modified our deployment script to be driven by the environment variables, ensuring consistency. We forced it to construct the deployer's identity from the same .env file that the Python script uses.

JavaScript

// Snippet from our corrected deploy script
if (!process.env.PRIVATE_KEY) {
throw new Error("PRIVATE_KEY is not set in your .env file!");
}
// This ensures the deployer is ALWAYS the account from the .env file
const deployer = new hre.ethers.Wallet(process.env.PRIVATE_KEY, hre.ethers.provider);

console.log("Deploying contracts with the account:", deployer.address);

Overcoming this challenge demonstrated a deep understanding of how signer contexts