{ "interval": { "intervalStart": "2025-05-18T00:00:00.000Z", "intervalEnd": "2025-05-19T00:00:00.000Z", "intervalType": "day" }, "repository": "elizaos/eliza", "overview": "From 2025-05-18 to 2025-05-19, elizaos/eliza had 9 new PRs (11 merged), 0 new issues, and 12 active contributors.", "topIssues": [ { "id": "I_kwDOMT5cIs62U-wk", "title": "Make a publish to npm", "author": "samgermain", "number": 4562, "repository": "elizaos/eliza", "body": "I'm trying to update zod to 3.24.2 in another repo, and I can't do it because eliza has some peerDependencies that use zod@3.23.8, and it causes the build to crash\n\nAnyway none of that really matters, but if make a publish to npm I would really appreciate it!", "createdAt": "2025-05-13T06:50:43Z", "closedAt": "2025-05-18T08:42:25Z", "state": "CLOSED", "commentCount": 1 }, { "id": "I_kwDOMT5cIs6yBHYI", "title": "chore: Update community section", "author": "madjin", "number": 4260, "repository": "elizaos/eliza", "body": "Gathering some ideas and sharing notes on how to improve the community section of docs\n\n\n## AI recommendations\n\n1. **Enhance the Navigation Flowchart** - Add clear paths for both technical and non-technical users, with complexity increasing as users go deeper.\n\n2. **Create a Prominent FAQ Section** - Develop a comprehensive, searchable FAQ that addresses the recurring questions mentioned by respondents.\n\n3. **Add a Clear \"Getting Started\" Guide** - Provide step-by-step instructions for different user types (developers, AI researchers, content creators).\n\n4. **Develop Use Case Examples** - Showcase practical applications that demonstrate real value (addressing the \"useless AI agent\" concern).\n\n5. **Clarify Project Direction** - Include a current roadmap and priorities section that's regularly updated to keep the community aligned.\n\n6. **Highlight Active Community Spaces** - Emphasize where meaningful discussions are happening (coder's channel, braintrust telegram).\n\n7. **Create a Community Structure Overview** - Outline how the community is organized, key working groups, and how decisions are made.\n\n8. **Include Non-Developer Contribution Paths** - Document how non-technical people can contribute (documentation, testing, community management, content creation).\n\n---\n\n## Notes\n\nVision: What We're Building Together\n\nThe internet is transforming, launching an agent is the new launching a new website. We're building:\n\n- **AI agents we can trust**, true ownership via free open source software and native TEE integration\n- **Seamless integration**, meeting us on platforms where we already spend our time\n- **Autonomous systems collaborate in swarms**, sharing context and solving complex problems together\n- **Sustainable community-driven development**, enabled by transparent AI assisted governance\n\n\nProject History\n\nWhat began as ai16z, a venture capital DAO led by AI agents on the Solana blockchain, has grown into a comprehensive open-source framework for building, deploying, and managing AI agents across platforms.\n\n- **October 2024**: Launched on Solana via daos.fun, raising 420.69 SOL\n- **November-December 2024**: Explosive growth in contributors, GitHub stars, and community engagement\n- **January 2025**: Rebranded from ai16z to ElizaOS, focusing on broader AI agent development\n- **March 2025**: Launched research beta of ElizaOS V2, representing a major architectural evolution\n\n\n```\n## Contributing to the ElizaOS DAO: High-Level Overview\n\n### Core Goals\n- Help build AI agents using the Eliza framework\n- Support democratized venture capital through AI-driven decisions\n- Advance the integration of AI and blockchain technologies\n\n### Impactful Contributions\n1. **Technical**: Code contributions to the Eliza framework, building new AI agents, or creating integrations\n \n2. **Governance**: Proposing investments, participating in token votes, and helping shape the project's direction\n\n3. **Strategy**: Researching investment opportunities, contributing to tokenomics discussions, organizing information\n\n4. **Community**: Creating educational content, onboarding developers, and representing the project to wider audiences\n```\n\nother ways to contribute:\n\n```\n- **Answer questions** in the coders/tech support channels—it gets noticed!\n- **Help with documentation**: Test steps, verify information, create issues and PRs\n- **Collaborate on AI news aggregation**: Generate show ideas or automations using our tools\n- **Develop specialized agents**: Create community scribes, lore keepers, moderators, or social media managers\n- **Build plugins**: Extend the ElizaOS framework with new capabilities\n- **Join community events**: Participate in our evolving formats for community coordination and project showcasing\n\n```\n\ntokenomics page: https://hackmd.io/EK6vGnyHT0WnFIL9P4nsQA\n", "createdAt": "2025-04-10T19:10:58Z", "closedAt": "2025-05-18T18:33:42Z", "state": "CLOSED", "commentCount": 0 } ], "topPRs": [ { "id": "PR_kwDOMT5cIs6U33qD", "title": "feat: polygon", "author": "monilpat", "number": 4449, "body": "\r\n\r\n# Relates to\r\n\r\n\r\n\r\n\r\n\r\n# Risks\r\n\r\n\r\n\r\n# Background\r\n\r\n## What does this PR do?\r\n\r\n## What kind of change is this?\r\n\r\n\r\n\r\n\r\n\r\n\r\n# Documentation changes needed?\r\n\r\n\r\n\r\n\r\n\r\n# Testing\r\n\r\n## Where should a reviewer start?\r\n\r\n## Detailed testing steps\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n", "repository": "elizaos/eliza", "createdAt": "2025-05-05T02:30:24Z", "mergedAt": null, "additions": 19482, "deletions": 28 }, { "id": "PR_kwDOMT5cIs6WCKh_", "title": "Added : Polygon Plugin", "author": "Samarthsinghal28", "number": 4573, "body": "# Relates to\r\n\r\nIssue: https://github.com/Sifchain/sa-eliza/issues/450\r\n\r\nThis PR relates to the ticket: \"Ticket: Initialize Eliza Plugin Structure and Configuration (Polygon)\" (Part of Epic: Implement Polygon Plugin MVP)\r\n\r\n\r\n\r\n# Risks\r\n\r\n* **Medium: L1 Gas Estimation Inaccuracy:** The current `GasService` primarily uses L2 (PolygonScan) gas oracles. When used for L1 Ethereum transactions (staking, bridging), this can lead to inaccurate gas estimations, potentially causing transactions to be underpriced (fail) or overpriced.\r\n* **Medium: Missing Heimdall Governance:** The P1 functionality for Polygon-specific governance (interacting with Heimdall) is not implemented. Current governance actions target EVM-based smart contracts. Users expecting native Polygon governance via Heimdall will not find this functionality.\r\n* **Low: User-Facing `withdrawRewards` Action Stub:** The LLM-enabled `withdrawRewards` action is a non-functional stub. The core logic exists via the programmatic `WITHDRAW_REWARDS_L1` action and the `PolygonRpcService`.\r\n\r\n# Background\r\n\r\n## What does this PR do?\r\n\r\nThis PR initializes the foundational structure and boilerplate for the new `@elizaos/plugin-polygon`. It establishes a functional, correctly configured, and buildable plugin skeleton that adheres to current ElizaOS conventions.\r\n\r\nKey functionalities included:\r\n* **Plugin Core**: `package.json`, TypeScript configuration, main plugin definition (`src/index.ts`) with lifecycle methods, and registration with ElizaOS.\r\n* **Configuration**: Handles essential configurations like L1/L2 RPC URLs, private key, and PolygonScan API key, with validation using `zod`. Includes `.env.example`.\r\n* **L1 Staking (Ethereum)**:\r\n * `PolygonRpcService` implements interactions with L1 staking contracts (`StakeManager`, `ValidatorShare`) for delegation, undelegation (partial via `sellVoucher_new` in service), reward withdrawal, and fetching validator/delegator information.\r\n * User-facing LLM-enabled actions and direct programmatic actions for these operations.\r\n* **L1 Native Bridge Deposit (Polygon PoS Bridge)**:\r\n * `PolygonRpcService` implements deposits to the L1 `RootChainManager` contract.\r\n * Actions for initiating bridge deposits.\r\n* **L2 Interactions (Polygon PoS)**:\r\n * Basic L2 interactions like fetching balances, block numbers via `PolygonRpcService`.\r\n * Actions for these operations.\r\n* **Checkpoint Status**:\r\n * `PolygonRpcService` implements checks against the L1 `RootChainManager` to verify L2 block checkpoint status.\r\n * Actions for this functionality.\r\n* **EVM-Based Governance Stubs**:\r\n * Actions (`PROPOSE_GOVERNANCE_POLYGON`, `VOTE_GOVERNANCE_POLYGON`) are implemented to interact with EVM-compatible governor smart contracts (e.g., OpenZeppelin Governor) using `viem`.\r\n* **Providers**: Includes a `PolygonWalletProvider` (using `viem`) for EVM wallet interactions and exposing wallet details.\r\n* **Services**: `PolygonRpcService` (using `ethers.js`) for core L1/L2 EVM logic and `GasService` for L2 gas price fetching (PolygonScan).\r\n* **Documentation**: A comprehensive `README.md` for the plugin.\r\n\r\n## What kind of change is this?\r\n\r\n\r\nFeatures (non-breaking change which adds functionality)\r\n\r\n\r\n## Why are we doing this? Any context or related work?\r\n\r\nThis work establishes the dedicated `@elizaos/plugin-polygon` as outlined in the \"Implement Polygon Plugin MVP\" epic. The goal is to create a focused plugin capable of handling Polygon-specific interactions (L1 staking, native bridge, Heimdall governance) that go beyond the scope of a generic EVM plugin. This PR lays the groundwork for these features, with many EVM-based L1/L2 interactions already functional.\r\n\r\n# Documentation changes needed?\r\n\r\n\r\nMy changes do not require a change to the project documentation. (The plugin includes its own `README.md` which serves as initial documentation for its features and setup).\r\n\r\n\r\n\r\n# Testing\r\n\r\n## Where should a reviewer start?\r\n\r\n1. **`packages/plugin-polygon/README.md`**: For an overview of the plugin's intended features and setup.\r\n2. **`packages/plugin-polygon/src/index.ts`**: For the main plugin definition, configuration handling, and registration of components.\r\n3. **`packages/plugin-polygon/src/services/PolygonRpcService.ts`**: To understand the core logic for L1 staking, L1 bridging, and L2 interactions.\r\n4. **`packages/plugin-polygon/src/services/GasService.ts`**: To review the L2 gas oracle integration.\r\n5. Key action files like `packages/plugin-polygon/src/actions/delegate.ts` (L1 staking) and `packages/plugin-polygon/src/actions/proposeGovernance.ts` (EVM Governance).\r\n\r\n## Detailed testing steps\r\n\r\n\r\nManual testing is recommended for this initial integration, focusing on the implemented P1 functionalities. Automated tests for configuration loading were considered in the ticket but not explicitly verified as present in this review.\r\n\r\n**Setup:**\r\n1. Navigate to the `packages/plugin-polygon` directory.\r\n2. Create a `.env` file based on `.env.example`.\r\n3. Populate the `.env` file with valid:\r\n * `POLYGON_RPC_URL` (Polygon PoS RPC endpoint)\r\n * `ETHEREUM_RPC_URL` (Ethereum Mainnet RPC endpoint for L1)\r\n * `PRIVATE_KEY` (for a wallet with funds on both L1 and L2 for testing)\r\n * `POLYGONSCAN_KEY` (API key for PolygonScan)\r\n * `HEIMDALL_RPC_URL` (placeholder, as Heimdall features are not yet implemented)\r\n", "repository": "elizaos/eliza", "createdAt": "2025-05-13T16:43:08Z", "mergedAt": null, "additions": 15041, "deletions": 10 }, { "id": "PR_kwDOMT5cIs6WCvDn", "title": "Implement Polygon Gas Oracle Integration", "author": "Y4NK33420", "number": 4574, "body": "\r\n# Relates to\r\n\r\n[Implement Polygon Gas Oracle Integration (Polygon Plugin) #452](https://github.com/Sifchain/sa-eliza/issues/452)\r\n\r\n\r\n# Risks\r\n\r\n**Low**\r\n\r\n* **External API Dependency:** The primary gas estimation relies on the PolygonScan API. If PolygonScan has an outage or changes its API contract in an unexpected way, the service will use the RPC fallback. The fallback itself depends on the configured Polygon RPC node.\r\n* **RPC Node Dependency (Fallback):** The fallback mechanism relies on the availability and correctness of the configured Polygon RPC node.\r\n* **ABI Placeholders:** `PolygonRpcService.ts` currently uses placeholder ABIs (`\"[]\"`) for staking and bridge-related contracts. One line (`await this.stakeManagerContractL1.currentEpoch();`) that would test a contract call during initialization was commented out to prevent errors due to these empty ABIs, this have been fixed in the commit but needs to be commented out to reproduce test results at the moment. This does not affect the `GasService` functionality directly, but it's a known state of a related service.\r\n\r\n# Background\r\n\r\n## What does this PR do?\r\n\r\nThis PR implements a robust gas price estimation service for the Polygon (PoS) network within the `plugin-polygon`. The service, `GasService.ts`, fetches gas price recommendations (Safe, Average, Fast priority fees, and Base Fee) primarily from the PolygonScan Gas Oracle API. If the API is unavailable, the API key is missing, or the response is problematic, it gracefully falls back to using the standard `eth_gasPrice` method (via `provider.getFeeData()`) from the configured L2 Polygon RPC node.\r\n\r\nThe service ensures consistent data types (bigint for Wei values) and handles various response formats from PolygonScan, including prioritizing `BaseFee` (in MATIC/ETH) over `suggestBaseFee` (in Gwei) if both are present or one is invalid.\r\n\r\n## What kind of change is this?\r\n\r\n**Features** (non-breaking change which adds functionality)\r\n\r\n\r\n\r\n# Documentation changes needed?\r\n\r\nMy changes do not require a change to the project documentation.\r\n\r\n# Testing\r\n\r\n## Where should a reviewer start?\r\n\r\nA good starting point would be `packages/plugin-polygon/src/services/GasService.ts` to understand the core logic, followed by `packages/plugin-polygon/src/services/__tests__/GasService.test.ts` to see how it's tested. Also, review the changes in `packages/plugin-polygon/src/services/PolygonRpcService.ts` for the `getL2Provider()` method and the ABI placeholder modifications.\r\n\r\n## Detailed testing steps\r\n\r\nAutomated integration tests are provided and cover the main scenarios:\r\n\r\n1. **Successful PolygonScan API fetch and parse:**\r\n * Ensures EIP-1559 style fees are fetched and parsed correctly.\r\n * Verifies `fallbackGasPrice` is null.\r\n * Checks that `estimatedBaseFee` and at least one priority fee tier are valid positive bigints.\r\n2. **Fallback to RPC `eth_gasPrice` when PolygonScan API key is missing:**\r\n * Simulates a missing API key.\r\n * Verifies that EIP-1559 fee fields are null.\r\n * Ensures `fallbackGasPrice` is a valid positive bigint.\r\n\r\n**To run the tests:**\r\n1. Ensure a root `.env` file is configured with valid `POLYGONSCAN_KEY`, `POLYGON_RPC_URL`, `ETHEREUM_RPC_URL`, and `PRIVATE_KEY`.\r\n2. Navigate to the `packages/plugin-polygon` directory.\r\n3. Run `bun run build` to build the package.\r\n4. Run `npx vitest run --globals src/services/__tests__/GasService.test.ts` to execute the integration tests.\r\n\r\nThe tests include `console.log` output for the fetched estimates in both scenarios, allowing for manual inspection of the live data returned.\r\n", "repository": "elizaos/eliza", "createdAt": "2025-05-13T17:56:51Z", "mergedAt": "2025-05-18T23:14:44Z", "additions": 10969, "deletions": 1645 }, { "id": "PR_kwDOMT5cIs6WnMqt", "title": "Added : Polygon Plugin ", "author": "Samarthsinghal28", "number": 4635, "body": "# Relates to\r\n\r\nIssue:\r\n- [#450 Initialize Eliza Plugin Structure and Configuration (Polygon)](https://github.com/Sifchain/sa-eliza/issues/450)\r\n- [#453 Implement Staking Read Operations (Polygon Plugin)](https://github.com/Sifchain/sa-eliza/issues/453)\r\n- [#454 Implement Core Staking Write Operations (Polygon Plugin)](https://github.com/Sifchain/sa-eliza/issues/454)\r\n\r\nThis PR implements the core foundation and staking operations for the Polygon Plugin as part of the \"Implement Polygon Plugin MVP\" epic.\r\n\r\n\r\n\r\n# Risks\r\n\r\n* **Medium: L1 Gas Estimation Inaccuracy:** The current `GasService` primarily uses L2 (PolygonScan) gas oracles. When used for L1 Ethereum transactions (staking, bridging), this can lead to inaccurate gas estimations, potentially causing transactions to be underpriced (fail) or overpriced.\r\n* **Medium: Missing Heimdall Governance:** The P1 functionality for Polygon-specific governance (interacting with Heimdall) is not implemented. Current governance actions target EVM-based smart contracts. Users expecting native Polygon governance via Heimdall will not find this functionality.\r\n* **Low: User-Facing `withdrawRewards` Action Stub:** The LLM-enabled `withdrawRewards` action is a non-functional stub. The core logic exists via the programmatic `WITHDRAW_REWARDS_L1` action and the `PolygonRpcService`.\r\n\r\n# Background\r\n\r\n## What does this PR do?\r\n\r\n1. **Plugin Foundation (#450):** \r\n - Establishes the plugin package structure with proper configuration and boilerplate\r\n - Implements configuration handling for RPC URLs, private keys, and API keys\r\n - Creates the provider structure and plugin lifecycle methods\r\n\r\n2. **Staking Read Operations (#453):**\r\n - Integrates StakeManager and ValidatorShare ABIs for interacting with L1 staking contracts\r\n - Implements `getValidatorInfo(validatorId)` to fetch validator status, total stake, and commission rate\r\n - Implements `getDelegatorInfo(validatorId, delegatorAddress)` to get delegator stake and pending rewards\r\n - Creates robust error handling for contract interactions\r\n\r\n3. **Staking Write Operations (#454):**\r\n - Implements `delegate(validatorId, amountWei)` for staking MATIC/POL to validators\r\n - Implements `undelegate(validatorId, sharesAmountWei)` for initiating the unbonding process\r\n - Implements `withdrawRewards(validatorId)` for claiming accumulated staking rewards\r\n - Implements `restakeRewards(validatorId)` as a convenience function\r\n - Handles transaction creation, gas estimation, signing, and broadcasting\r\n\r\n\r\nKey functionalities included:\r\n* **Plugin Core**: `package.json`, TypeScript configuration, main plugin definition (`src/index.ts`) with lifecycle methods, and registration with ElizaOS.\r\n* **Configuration**: Handles essential configurations like L1/L2 RPC URLs, private key, and PolygonScan API key, with validation using `zod`. Includes `.env.example`.\r\n* **L1 Staking (Ethereum)**:\r\n * `PolygonRpcService` implements interactions with L1 staking contracts (`StakeManager`, `ValidatorShare`) for delegation, undelegation (partial via `sellVoucher_new` in service), reward withdrawal, and fetching validator/delegator information.\r\n * User-facing LLM-enabled actions and direct programmatic actions for these operations.\r\n* **L1 Native Bridge Deposit (Polygon PoS Bridge)**:\r\n * `PolygonRpcService` implements deposits to the L1 `RootChainManager` contract.\r\n * Actions for initiating bridge deposits.\r\n* **L2 Interactions (Polygon PoS)**:\r\n * Basic L2 interactions like fetching balances, block numbers via `PolygonRpcService`.\r\n * Actions for these operations.\r\n* **Checkpoint Status**:\r\n * `PolygonRpcService` implements checks against the L1 `RootChainManager` to verify L2 block checkpoint status.\r\n * Actions for this functionality.\r\n* **EVM-Based Governance Stubs**:\r\n * Actions (`PROPOSE_GOVERNANCE_POLYGON`, `VOTE_GOVERNANCE_POLYGON`) are implemented to interact with EVM-compatible governor smart contracts (e.g., OpenZeppelin Governor) using `viem`.\r\n* **Providers**: Includes a `PolygonWalletProvider` (using `viem`) for EVM wallet interactions and exposing wallet details.\r\n* **Services**: `PolygonRpcService` (using `ethers.js`) for core L1/L2 EVM logic and `GasService` for L2 gas price fetching (PolygonScan).\r\n* **Documentation**: A comprehensive `README.md` for the plugin.\r\n\r\n## What kind of change is this?\r\n\r\n\r\nFeatures (non-breaking change which adds functionality)\r\n\r\n\r\n## Why are we doing this? Any context or related work?\r\n\r\nThis work establishes the dedicated `@elizaos/plugin-polygon` as outlined in the \"Implement Polygon Plugin MVP\" epic. The goal is to create a focused plugin capable of handling Polygon-specific interactions (L1 staking, native bridge, Heimdall governance) that go beyond the scope of a generic EVM plugin. This PR lays the groundwork for these features, with many EVM-based L1/L2 interactions already functional.\r\n\r\n# Documentation changes needed?\r\n\r\n\r\nMy changes do not require a change to the project documentation. (The plugin includes its own `README.md` which serves as initial documentation for its features and setup).\r\n\r\n\r\n\r\n# Testing\r\n\r\n### Where should a reviewer start?\r\n\r\n1. **`packages/plugin-polygon/README.md`**: For an overview of the plugin's intended features and setup.\r\n2. **`packages/plugin-polygon/src/index.ts`**: For the main plugin definition, configuration handling, and registration of components.\r\n3. **`packages/plugin-polygon/src/services/PolygonRpcService.ts`**: To understand the core logic for L1 staking, L1 bridging, and L2 interactions.\r\n4. **`packages/plugin-polygon/src/services/GasService.ts`**: To review the L2 gas oracle integration.\r\n5. **Key staking files:**\r\n - `packages/plugin-polygon/src/abi/`: To verify the StakeManager and ValidatorShare ABIs are properly included\r\n - `packages/plugin-polygon/src/actions/delegate.ts`: For L1 staking operations\r\n - `packages/plugin-polygon/src/actions/getValidatorInfo.ts` and `getDelegatorInfo.ts`: For staking read operations\r\n\r\n## Detailed testing steps\r\n\r\n\r\nManual testing is recommended for this initial integration, focusing on the implemented P1 functionalities. Automated tests for configuration loading were considered in the ticket but not explicitly verified as present in this review.\r\n\r\n**Setup:**\r\n1. Navigate to the `packages/plugin-polygon` directory.\r\n2. Create a `.env` file based on `.env.example`.\r\n3. Populate the `.env` file with valid:\r\n * `POLYGON_RPC_URL` (Polygon PoS RPC endpoint)\r\n * `ETHEREUM_RPC_URL` (Ethereum Mainnet RPC endpoint for L1)\r\n * `PRIVATE_KEY` (for a wallet with funds on both L1 and L2 for testing)\r\n * `POLYGONSCAN_KEY` (API key for PolygonScan)\r\n * `HEIMDALL_RPC_URL` (placeholder, as Heimdall features are not yet implemented)\r\n", "repository": "elizaos/eliza", "createdAt": "2025-05-18T11:31:49Z", "mergedAt": "2025-05-18T23:14:44Z", "additions": 10688, "deletions": 1088 }, { "id": "PR_kwDOMT5cIs6WnU_V", "title": "Merge addpolygon resolution", "author": "HarshModi2005", "number": 4636, "body": "\r\n\r\n# Relates to\r\n\r\n\r\n\r\n\r\n\r\n# Risks\r\n\r\n\r\n\r\n# Background\r\n\r\n## What does this PR do?\r\n\r\n## What kind of change is this?\r\n\r\n\r\n\r\n\r\n\r\n\r\n# Documentation changes needed?\r\n\r\n\r\n\r\n\r\n\r\n# Testing\r\n\r\n## Where should a reviewer start?\r\n\r\n## Detailed testing steps\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n", "repository": "elizaos/eliza", "createdAt": "2025-05-18T12:36:44Z", "mergedAt": "2025-05-18T23:14:42Z", "additions": 10084, "deletions": 1931 } ], "codeChanges": { "additions": 45383, "deletions": 6262, "files": 176, "commitCount": 37 }, "completedItems": [ { "title": "Issue 451", "prNumber": 4575, "type": "other", "body": "# Ticket: Implement Core EVM RPC Wrappers & Basic Reads (Polygon Plugin)\r\n\r\n**Ticket Type:** Dev Ticket \r\n**Priority:** P1 \r\n**Epic:** Implement Polygon Plugin MVP \r\n**Assignee:** Harsh Modi \r\n**Reporter:** AI Assistant \r\n**Dependencie" }, { "title": "Implement Polygon Gas Oracle Integration", "prNumber": 4574, "type": "other", "body": "\r\n# Relates to\r\n\r\n[Implement Polygon Gas Oracle Integration (Polygon Plugin) #452](https://github.com/Sifchain/sa-eliza/issues/452)\r\n\r\n\r\n# Risks\r\n\r\n**Low**\r\n\r\n* **External API Dependency:** The primary gas estimation relies on the Polygon" }, { "title": "chore: update docs", "prNumber": 4586, "type": "other", "body": "This PR focuses on a comprehensive update of the project's documentation.\r\n\r\nKey changes include:\r\n\r\n* **Content Updates:**\r\n * Updated blog posts.\r\n * Added brief versions of all partner documentation.\r\n * Added documentat" }, { "title": "API - return ID of newly created agent", "prNumber": 4634, "type": "other", "body": "When using API calls and creating AGENT it very useful to have returned ID on first API call, so there are not needed subsequent calls after it just to find ID, which is crucial for other types of API calls.\r\n\r\nSo I added ID in return data " }, { "title": "ci: Docs auto deployer.", "prNumber": 4631, "type": "other", "body": "This runs Github Action if anything inside `packages/docs` folder changes and auto deploys to `docs.eliza.how`." }, { "title": "Eliza290/cli command dev", "prNumber": 4618, "type": "other", "body": "This PR enhances the elizaos dev command with better character file handling while ensuring consistent behavior with start cli command\r\n\r\nAll options tested and passed:\r\n\r\n-c/--configure, \r\n-p/--port, \r\n-b/--build\r\n-char/--character\r\n\r\nKey " }, { "title": "chore: Add missing plugin failure test", "prNumber": 4643, "type": "feature", "body": "## Summary\n- test plugin install modifies package.json with plugin-discord\n- verify missing plugin fails with registry error\n\n## Testing\n- `./run_all_bats.sh` *(fails: 'bats' not found in PATH)*" }, { "title": "fix: docs deploy workflow", "prNumber": 4640, "type": "bugfix", "body": "fixes npm cache since doesn't exist for docs package, removes PR runs, should only happen on pushes." }, { "title": "feat: allow world selection in message API", "prNumber": 4637, "type": "feature", "body": "## Summary\n- add optional `worldId` query param for `/agents/:agentId/message`\n- record `worldId` in created memories\n- document new query parameter in OpenAPI & docs\n\n## Testing\n- `bun test` *(fails: Cannot find module '@playwright/test')*" }, { "title": "Merge addpolygon resolution", "prNumber": 4636, "type": "other", "body": "\r\n\r\n# Relates to\r\n\r\n\r\n\r\n