Yeti

YETI is an app that bridges TradingView alerts to DeFi limit orders from the 1inch protocol. Essentially, it lets you use any TradingView indicators or custom Pine Script strategies to trigger on-chain trades automatically.

The problem we're solving:

Most DeFi trading bots are pretty basic - they do simple stuff like DCA, TWAP, or grid trading. But TradingView has a massive ecosystem of 100+ built-in indicators and hundreds of thousands of community-published scripts, and lets you write custom strategies in Pine Script. We wanted to unlock all that trading logic for DeFi.

YETI works like this:

You create a limit order in the frontend (e.g. buy ETH with USDC), sign it with your wallet, and we generate a unique webhook URL and secret. You then go to TradingView, set up any alert you want (e.g. RSI oversold, custom ML indicator, etc), and configure it to call our webhook when it triggers. When your TradingView conditions are met, it hits our webhook server, which validates everything and publishes the alert data on-chain. This makes your limit order fillable, and takers can execute it using current market prices from Chainlink.

The key innovation is that it's completely non-custodial. Your funds never leave your wallet, you just sign an order that sits dormant until your TradingView alert triggers. And because we use a TEE (Trusted Execution Environment) for the webhook server, no one can fake alerts or manipulate the system.

What makes this powerful is the flexibility, you can use any TradingView strategy, from simple moving average crossovers to complex algorithmic trading strategies you've coded yourself. You could even set up alerts based on external sentiment data (like Trump tweeting about Bitcoin) and have it automatically trigger DeFi trades.

The project includes a full orderbook system where users can discover and fill orders, a React frontend for creating orders, and automated order watching services for takers. It's basically bringing the sophistication of traditional trading platforms to DeFi while maintaining full decentralization and custody.

Architecture Overview

We built this as a six-component system that needed to work together seamlessly:

1. TEE-Secured Webhook Server (Python/FastAPI) This was probably the trickiest part. We needed a way to validate that webhook calls actually came from TradingView and weren't spoofed. We used Phala's TEE to derive cryptographic secrets that only our server knows. The webhook IDs contain embedded HMAC signatures that we can verify without storing any state.

The IP whitelisting was essential - we only accept requests from TradingView's official IP ranges. The HMAC verification works by embedding a 4-byte timestamp and 12-byte signature directly in the webhook UUID, so we can verify it was generated by our TEE without any database lookups.

2. Smart Contracts (Solidity) We built two main contracts:

• WebhookOracle: Stores alert data on-chain with nonce-based replay protection https://base.blockscout.com/address/0x65bec6934b24390F9195C5bCF8A59fa008964722
• WebhookPredicate: Custom predicate for 1inch limit orders that validates alerts https://base.blockscout.com/address/0x3410e3dBef8bc2e5eB7a8e983926B971831177f7
• We also use ```ChainlinkCalculator`: Gets current prices for order execution https://base.blockscout.com/address/0x5220d049f9Ed013d7756DF2e2dF50fe517944948

The predicate was the key piece - it implements the 1inch predicate interface and checks if an alert exists, matches the expected action (LONG/SHORT), and isn't too old (configurable max age). Only orders with valid, recent alerts can be filled.

We used Foundry for development and testing, and deployed everything on Base. The contracts use Solady for gas optimization and follow the 1inch SDK patterns closely.

3. Frontend (Next.js 15/React) Built with the latest Next.js 15 and React 19. We used Privy for wallet connections because it's just way easier than building custom wallet logic. The UI uses Framer Motion for animations and TailwindCSS 4.0 for styling.

The tricky part was integrating with the 1inch limit order SDK while adding our custom conditional logic. We extended their SDK patterns to create our own useYetiSDK hook that handles order creation, signing, and lifecycle management.

4. Custom YetiSDK (TypeScript) We built a TypeScript SDK that extends the official 1inch limit order SDK. This was necessary because we needed to add custom predicate data and webhook references to the orders. The SDK handles all the crypto stuff - generating order hashes, handling signatures, and formatting data for the 1inch protocol.

5. Orderbook Server (Node.js/Express) This was crucial for user experience. We built an automatic blockchain monitoring service that watches for AlertSubmitted events and updates order statuses in real-time. Without this, users would have no idea if their alerts had triggered.

The server uses better-sqlite3 for performance and has proper database migrations. It provides a REST API for order discovery with filtering, pagination, and analytics. We also added Swagger documentation for easy integration.

6. Order Watcher (Node.js) This is essentially the "taker" side - it polls for triggered orders and executes them. We made it configurable so different market makers could run their own execution strategies.

Key Technical Challenges

TEE Integration: Getting the Phala TEE working was initially tricky. We needed to understand their key derivation system and how to use it for HMAC generation. The stateless verification was crucial for scalability.

1inch SDK Extension: The 1inch limit order protocol is complex, and we needed to understand their predicate system deeply to build our custom webhook predicate. We spent a lot of time reading their contracts and SDK code.

Real-time Blockchain Monitoring: Building reliable event listening with automatic reconnection and exponential backoff was essential. We couldn't afford to miss AlertSubmitted events or users would think their system was broken.

Frontend Web3 Integration: Handling wallet connections, transaction signing, and blockchain state management in React is always complex. We used Wagmi + Privy which helped a lot, but there's still a lot of state management complexity.

Particularly Hacky/Notable Stuff

Webhook ID Encoding: We embed the entire HMAC signature directly in the UUID bytes. This lets us do stateless verification without any database lookups. The first 4 bytes are a timestamp, the next 12 bytes are the HMAC signature, all packed into a valid UUID format.

The whole system is deployed on Base, and we've got the contracts verified on Blockscout. The hardest part was honestly just getting all six components to work together reliably - there's a lot of async coordination between the webhook server, blockchain events, and frontend state management.