
# Building a Safety Net Around DeFi Automation

For the last months I’ve been building a safety layer around DeFi automation.

It doesn’t farm, it doesn’t chase yields, it doesn’t try to be “smart money”. Its only job is much more boring: **watch things, connect a few dots, and say “this is safe enough to act” or “please stop”**.

This post is a small introduction to what I’m building and, more importantly, how I’m thinking about it. I’m *not* going to show you everything – on purpose.

## What problem am I trying to solve?

If you’ve been around DeFi automation for a while, you’ve probably seen at least one of these patterns:

- Scripts that keep running happily long after the original assumptions are dead.
- “Health checks” that only verify that a process is up, not that it’s safe.
- Bots that will try to rebalance or harvest in environments that are clearly hostile: no gas, bad pricing, broken RPCs.

What I want from this safety layer is simple:

> Before you touch funds on-chain, answer one question:  
> **“Is it actually responsible to act right now?”**

Sometimes the answer should be “yes, go ahead”.  
Sometimes the answer should be “no, and here’s why”.  
And sometimes the answer should be “I have no idea, so I’m going to block you”.

That last case is the one I care about the most.

## A tiny bit about how it works (without giving away everything)

Very high level:

- It watches different kinds of signals:  
  balances, gas availability, strategy health, exit conditions…
- It combines them into **explicit decisions**:
  - “act now”,
  - “wait and re-check later”,
  - “refuse to act under current conditions”.
- It tries to make the **reasons** visible:
  - not just “failed”, but “skipped because insufficient gas runway”,
  - not just “error”, but “RPC is blind, treating this as unsafe”.

Under the hood it’s just TypeScript, a bunch of services, and more tests than I’d like to admit. The interesting part is not the framework, it’s the questions I force the code to answer.

There are parts I’m not going to describe in detail:

- exact thresholds and combinations of signals,
- operational internals,
- some of the production wiring.

Think of this series as **field notes**, not a full spec.

## What this blog series will focus on

I don’t want to turn this into a changelog of features. I’d rather write about the decisions behind them, for example:

- When should an automated system **refuse** to act, even if it technically can?
- How do you decide what “enough runway” means before you’re being irresponsible?
- Where do you consciously trade developer comfort for user safety?
- How do you encode those ideas in code so future-you can’t silently ignore them?

Each post will probably zoom into a small piece of the system:

- a service,
- a pattern,
- a specific check or threshold,

and treat it as an excuse to talk about **good vs bad code, and good vs bad decisions**.

You’ll see real snippets from the codebase, but always with a bit of blur where I don’t want to go into operational details.

## What I’m willing to show (and what I’m not)

I *am* willing to show:

- how I design health checks that do more than “is the process up?”,
- how I think about failing *closed* vs failing *open*,
- how I keep myself honest with tests and explicit contracts.

I’m *not* going to show:

- everything that can be configured and how,
- every single signal and threshold,
- anything that would meaningfully leak operational posture.

If sometimes a piece of code looks a bit redacted or simplified, assume it’s deliberate.

## What’s coming next

In the next post I’ll zoom into a piece that sounds trivial and really isn’t:

> how I decide whether there’s “enough gas” for the system to act at all.

On paper it looks like “just check the balance”.  
In practice it becomes a conversation about **runway, RPC failures, and when being blind should mean a hard stop**.


Building a Safety Net Around DeFi Automation


# Getting Started with TypeScript in 2024

TypeScript has become the de facto standard for JavaScript development in 2024. Here's everything you need to know to get started.

## Why TypeScript?

TypeScript offers several advantages over plain JavaScript:

- **Type Safety**: Catch errors at compile time
- **Better IDE Support**: Enhanced autocomplete and refactoring
- **Self-Documenting Code**: Types serve as documentation
- **Easier Refactoring**: Confident code changes

## Setting Up TypeScript

First, install TypeScript globally:

```bash
npm install -g typescript
```

Create a new project:

```bash
mkdir my-typescript-project
cd my-typescript-project
npm init -y
tsc --init
```

## Basic Types

Here are the fundamental TypeScript types:

```typescript
// Primitive types
let name: string = 'Angel'
let age: number = 30
let isActive: boolean = true

// Arrays
let numbers: number[] = [1, 2, 3]
let names: Array<string> = ['Angel', 'Maria']

// Objects
interface User {
  id: number
  name: string
  email?: string // Optional property
}

const user: User = {
  id: 1,
  name: 'Angel Batlles'
}
```

## Functions

TypeScript makes functions much more predictable:

```typescript
function greet(name: string): string {
  return `Hello, ${name}!`
}

// Arrow functions
const add = (a: number, b: number): number => a + b

// Optional parameters
function buildMessage(name: string, age?: number): string {
  if (age) {
    return `${name} is ${age} years old`
  }
  return `Hello, ${name}`
}
```

## Interfaces vs Types

Both serve similar purposes but have subtle differences:

```typescript
// Interface
interface ApiResponse {
  data: any[]
  status: number
  message: string
}

// Type alias
type Status = 'loading' | 'success' | 'error'

type UserWithStatus = User & {
  status: Status
}
```

## Generic Types

Generics allow you to write reusable code:

```typescript
function identity<T>(arg: T): T {
  return arg
}

// Usage
const stringResult = identity<string>('hello')
const numberResult = identity<number>(42)

// Generic interfaces
interface Repository<T> {
  create(item: T): Promise<T>
  findById(id: string): Promise<T | null>
  update(id: string, updates: Partial<T>): Promise<T>
  delete(id: string): Promise<void>
}
```

## Best Practices

1. **Use strict mode**: Enable strict checks in `tsconfig.json`
2. **Avoid `any`**: Use specific types or `unknown` instead
3. **Leverage type inference**: Don't over-annotate
4. **Use utility types**: `Partial<T>`, `Required<T>`, `Pick<T, K>`

## Conclusion

TypeScript is an investment in code quality and developer experience. Start small, add types gradually, and enjoy the benefits of safer, more maintainable code.

Happy coding! 🚀


Getting Started with TypeScript in 2024


# Building Responsive Web Apps with Next.js 15

Next.js 15 has arrived with significant improvements in performance, developer experience, and new features that make building modern web applications even better.

## What's New in Next.js 15

### Turbopack (Stable)

Turbopack is now stable and provides up to 53% faster local iteration and 94% faster initial builds compared to Webpack.

### React 19 Support

Full support for React 19 features including:

- Server Components
- Concurrent features
- New hooks like `use()`

### Improved Caching

Better caching strategies with more granular control over cache invalidation.

## Setting Up Next.js 15

Create a new Next.js 15 project:

```bash
npx create-next-app@latest my-app
cd my-app
npm run dev
```

### Key Configuration Options

Update your `next.config.js`:

```javascript
/** @type {import('next').NextConfig} */
const nextConfig = {
  experimental: {
    turbo: {
      rules: {
        '*.svg': {
          loaders: ['@svgr/webpack'],
          as: '*.js'
        }
      }
    }
  },
  images: {
    remotePatterns: [
      {
        protocol: 'https',
        hostname: 'example.com'
      }
    ]
  }
}

module.exports = nextConfig
```

## Building Responsive Components

### Using CSS Grid and Flexbox

```jsx
// components/Layout.jsx
import styles from './Layout.module.css'

export default function Layout({ children }) {
  return (
    <div className={styles.container}>
      <header className={styles.header}>
        <nav className={styles.nav}>{/* Navigation items */}</nav>
      </header>
      <main className={styles.main}>{children}</main>
      <footer className={styles.footer}>{/* Footer content */}</footer>
    </div>
  )
}
```

```css
/* Layout.module.css */
.container {
  display: grid;
  grid-template-rows: auto 1fr auto;
  min-height: 100vh;
  max-width: 1200px;
  margin: 0 auto;
  padding: 0 1rem;
}

.header {
  padding: 1rem 0;
  border-bottom: 1px solid #eee;
}

.nav {
  display: flex;
  justify-content: space-between;
  align-items: center;
}

.main {
  padding: 2rem 0;
}

.footer {
  padding: 1rem 0;
  border-top: 1px solid #eee;
  text-align: center;
}

@media (max-width: 768px) {
  .container {
    padding: 0 0.5rem;
  }

  .nav {
    flex-direction: column;
    gap: 1rem;
  }
}
```

### Server Components for Better Performance

```jsx
// app/blog/page.jsx (App Router)
import { getPosts } from '@/lib/posts'
import PostCard from '@/components/PostCard'

export default async function BlogPage() {
  const posts = await getPosts()

  return (
    <div className="grid grid-cols-1 md:grid-cols-2 lg:grid-cols-3 gap-6">
      {posts.map(post => (
        <PostCard key={post.id} post={post} />
      ))}
    </div>
  )
}
```

## Optimized Images and Performance

```jsx
import Image from 'next/image'

export default function Hero() {
  return (
    <section className="relative h-screen">
      <Image
        src="/hero-bg.jpg"
        alt="Hero background"
        fill
        style={{ objectFit: 'cover' }}
        priority
        sizes="100vw"
      />
      <div className="absolute inset-0 bg-black/50 flex items-center justify-center">
        <h1 className="text-4xl md:text-6xl text-white font-bold text-center">
          Welcome to Our Site
        </h1>
      </div>
    </section>
  )
}
```

## Dynamic Routing and API Routes

```jsx
// app/blog/[slug]/page.jsx
import { getPost } from '@/lib/posts'
import { notFound } from 'next/navigation'

export async function generateStaticParams() {
  const posts = await getPosts()
  return posts.map(post => ({
    slug: post.slug
  }))
}

export default async function PostPage({ params }) {
  const post = await getPost(params.slug)

  if (!post) {
    notFound()
  }

  return (
    <article className="max-w-4xl mx-auto">
      <h1 className="text-3xl font-bold mb-4">{post.title}</h1>
      <div dangerouslySetInnerHTML={{ __html: post.content }} />
    </article>
  )
}
```

## Best Practices for Next.js 15

1. **Use Server Components by default**: Only use Client Components when needed
2. **Implement Incremental Static Regeneration**: For dynamic content that doesn't change frequently
3. **Optimize images**: Always use the Next.js Image component
4. **Implement proper error boundaries**: Handle errors gracefully
5. **Use TypeScript**: Better development experience and type safety

## Deployment Considerations

### Vercel Deployment

```bash
npm install -g vercel
vercel
```

### Docker Deployment

```dockerfile
FROM node:18-alpine

WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
RUN npm run build

EXPOSE 3000
CMD ["npm", "start"]
```

## Conclusion

Next.js 15 provides an excellent foundation for building modern, responsive web applications. With Turbopack's improved performance and React 19 support, development has never been smoother.

The combination of Server Components, optimized images, and smart caching makes Next.js 15 a powerful choice for any web project.

Start building today! 🚀
