# ElizaOS Developer Update - Week of November 4-10, 2025

## Core Framework

The ElizaOS framework saw several significant architectural improvements this week, enhancing both stability and flexibility:

* **Runtime Initialization Enhancement**: A new `skipMigrations` option was added to `runtime.initialize()`, allowing developers to conditionally bypass plugin migrations during initialization. This is particularly useful for testing environments and scenarios where migrations need to be manually controlled. ([PR #6132](https://github.com/elizaos/eliza/pull/6132))

* **Dynamic Prompt Execution**: A major new feature introduced schema-based dynamic prompt execution, which intelligently adapts prompts to fit within model context windows. This system includes:
  - XML/JSON parsing with validation codes
  - Handlebars state injection
  - Token estimation
  - Automatic retries
  - Performance metrics tracking

  ```typescript
  // Example usage of the new dynamic prompt executor
  const result = await runtime.dynamicPromptExecFromState({
    state: currentState,
    schema: {
      thought: { type: "string" },
      actions: { type: "array" }
    },
    prompt: "{{userMessage}}",
    model: "gpt-4o-mini",
    validationLevel: "strict"
  });
  ```

* **Row-Level Security**: Development continued on entity-level row-level security (RLS), which will provide more granular data access controls at the entity level. This enhancement is still in progress but represents a significant security improvement. ([PR #6107](https://github.com/elizaos/eliza/pull/6107))

## New Features

### React Hooks Package

A new `@elizaos/react` package is now available, providing headless React hooks for building custom UIs for ElizaOS agents. The package features:

* Zero UI coupling (no toasts, navigation, or DOM dependencies)
* Full TypeScript support with proper type declarations
* TanStack React Query for caching and state management
* Network-aware polling that adapts to connection quality

```typescript
import { QueryClient, QueryClientProvider } from '@tanstack/react-query';
import { ElizaReactProvider, useAgents, useStartAgent } from '@elizaos/react';

const queryClient = new QueryClient();

function App() {
  return (
    <QueryClientProvider client={queryClient}>
      <ElizaReactProvider baseUrl="http://localhost:3000">
        <AgentList />
      </ElizaReactProvider>
    </QueryClientProvider>
  );
}

function AgentList() {
  const { data: agents, isLoading } = useAgents();
  const startAgent = useStartAgent({
    onSuccess: () => toast.success('Agent started!'),
  });

  if (isLoading) return <div>Loading...</div>;

  return (
    <div>
      {agents?.map((agent) => (
        <div key={agent.id}>
          <h3>{agent.name}</h3>
          <button onClick={() => startAgent.mutate(agent.id)}>Start</button>
        </div>
      ))}
    </div>
  );
}
```

### X402 Payment Protection

A new middleware system for implementing X402 payment protection has been introduced for plugin routes:

* Support for both EVM (EIP-712/ERC-3009) and Solana verification
* Facilitator payment ID support
* x402scan-compliant 402 responses
* Built-in payment configs for Base USDC, Solana USDC, and Polygon USDC

```typescript
// Example route with payment protection
app.get('/api/premium-data', 
  applyPaymentProtection({ 
    config: 'base_usdc', 
    amount: '0.5' 
  }), 
  (req, res) => {
    // Handle protected endpoint
    res.json({ premiumData: '...' });
  }
);
```

## Bug Fixes

### Entity Names Serialization

A critical bug related to entity creation in PostgreSQL has been fixed. The issue caused failures when storing entity names that weren't properly formatted as arrays:

* Fixed entity creation failures by normalizing the `names` field to ensure it's always a proper array before database operations
* Added handling for `Set` objects by converting them with `Array.from()`
* Implemented comprehensive test suite with 9 new tests
* All 491 plugin-sql tests now pass successfully

```typescript
// Before the fix, this would fail:
const entityWithSet = await db.createEntity({
  type: 'person',
  names: new Set(['John', 'Johnny']),
  metadata: { age: 30 }
});

// After the fix, all these formats work:
await db.createEntity({ type: 'person', names: 'John' });
await db.createEntity({ type: 'person', names: ['John', 'Johnny'] });
await db.createEntity({ type: 'person', names: new Set(['John', 'Johnny']) });
```

### Agent Settings Persistence

A longstanding issue with agent settings not persisting across restarts has been fixed. This ensures that runtime-generated configurations are now correctly retained after restarting an agent, improving reliability and user experience. ([PR #6106](https://github.com/elizaos/eliza/pull/6106))

## API Changes

### Message Service Refactoring

The Message Service module has undergone significant refactoring to utilize the new dynamic prompt execution system:

* Replaced manual `useModel` + XML parsing with `dynamicPromptExecFromState` in:
  - `shouldRespond` evaluation (small model)
  - Single-shot handler (requires `thought`, `actions`)
  - Multi-step decision loop and final summary
* Improved error logging and flow

Developers using the Message Service APIs should review their implementations to ensure compatibility with these changes.

## Social Media Integrations

### Smart Contract Event Broadcasting

A new pattern for monitoring smart contract events and broadcasting them on social media has been discussed. The recommended approach is:

1. Set up a custom event that fires when the smart contract event occurs
2. Handle the custom event with a function that uses the Twitter or Farcaster features

```typescript
// Example for monitoring contract events and posting to social media
function setupContractEventMonitor(contractAddress, eventName) {
  // Set up the contract listener
  const contract = new ethers.Contract(contractAddress, abi, provider);
  
  contract.on(eventName, async (...args) => {
    // Fire a custom event
    const customEvent = new CustomEvent('contractEvent', { 
      detail: { eventName, args } 
    });
    document.dispatchEvent(customEvent);
  });
  
  // Handle the custom event
  document.addEventListener('contractEvent', async (e) => {
    const { eventName, args } = e.detail;
    
    // Post to Twitter
    await twitterPlugin.tweet(
      `Event ${eventName} occurred with data: ${JSON.stringify(args)}`
    );
    
    // Cast on Farcaster
    await farcasterPlugin.cast(
      `Event ${eventName} occurred with data: ${JSON.stringify(args)}`
    );
  });
}
```

## Model Provider Updates

### Hardware Recommendations for Local LLMs

The cost of running large language models locally has decreased significantly. Mini PCs with 128GB memory are now available for around $2,000 (down from $6,000 previously). Recommended options include:

* GMKtec mini PCs
* Minisforum systems
* Bosgame mini PCs

These systems are capable of running most medium-sized language models locally, providing developers with more options for deployment and testing.

## Breaking Changes

### Token Migration (AI16z to ElizaOS)

The token migration from AI16z to ElizaOS is ongoing with a few important notes for developers:

* Migration portal launched November 6th with a 90-day window ending February 4th, 2024
* Conversion ratio: 1 AI16z = 6 ElizaOS tokens
* Exchange migrations (KuCoin, Gate.io) are expected to complete this week
* Bybit will list ElizaOS on November 12th

Developers working with token-based features should update their integrations to support both tokens during the transition period, with eventual migration to ElizaOS tokens only.

### V1 to V2 Migration Issues

If you're experiencing issues with the V1 to V2 migration, particularly around token handling, be aware that:

* Direct swapping of AI16z to ElizaOS on Jupiter is not possible
* You need to bridge/migrate first, then swap on the supported chain where ElizaOS is listed
* The ElizaOS token is mintable to support multichain functionality

```bash
# CLI command to check if your wallet has migrated tokens
elizaos wallet check-migration --address YOUR_WALLET_ADDRESS
```

Remember to update any frontend code that interacts with tokens to handle the new contract addresses correctly.