feat: add coinbase plugin starting with cb commerce functionality

.env.example

@@ -91,4 +91,5 @@ STARKNET_ADDRESS=
 STARKNET_PRIVATE_KEY=
 STARKNET_RPC_URL=
 
-
+# Coinbase Commerce
+COINBASE_COMMERCE_KEY=

.github/workflows/ci.yaml

@@ -25,6 +25,9 @@ jobs:
             - name: Run Prettier
               run: pnpm run prettier --check .
 
+            - name: Run Linter
+              run: pnpm run lint
+
             - name: Create test env file
               run: |
                   echo "TEST_DATABASE_CLIENT=sqlite" > packages/core/.env.test

.github/workflows/pre-release.yml

@@ -1,9 +1,6 @@
 name: Pre-Release
 
 on:
-    push:
-        branches:
-            - main
     workflow_dispatch:
         inputs:
             release_type:

.husky/commit-msg

@@ -0,0 +1,12 @@
+#!/usr/bin/env sh
+
+# Inform the user about commit message format requirements
+echo "┌──────────────────────────────────────────────────────────────┐"
+echo "│ ℹ️  Commit message must follow the format: 'type: description' │"
+echo "│    Valid types: feat, fix, docs, style, refactor, test, chore │"
+echo "│    Example: 'feat: add new login feature'                     │"
+echo "└──────────────────────────────────────────────────────────────┘"
+echo ""
+
+# Run commitlint to validate the commit message
+npx --no -- commitlint --edit ${1}

.husky/pre-commit

@@ -0,0 +1,2 @@
+pnpm run prettier-check
+pnpm run lint

CONTRIBUTING.md

@@ -15,32 +15,34 @@ By contributing to Eliza, you agree that your contributions will be licensed und
 
 We believe in the power of the OODA Loop - a decision-making framework that emphasizes speed and adaptability. OODA stands for:
 
-- **Observe**: Gather information and insights about the project, the community, and the broader AI ecosystem.
-- **Orient**: Analyze your observations to identify opportunities for contribution and improvement.
-- **Decide**: Choose a course of action based on your analysis. This could be proposing a new feature, fixing a bug, or creating content.
-- **Act**: Execute your decision and share your work with the community.
+-   **Observe**: Gather information and insights about the project, the community, and the broader AI ecosystem.
+-   **Orient**: Analyze your observations to identify opportunities for contribution and improvement.
+-   **Decide**: Choose a course of action based on your analysis. This could be proposing a new feature, fixing a bug, or creating content.
+-   **Act**: Execute your decision and share your work with the community.
 
 ## How to Contribute
 
 ### For Developers
 
 1. **Extend Eliza's Capabilities**
-   - Develop new actions, evaluators, and providers
-   - Improve existing components and modules
+
+    - Develop new actions, evaluators, and providers
+    - Improve existing components and modules
 
 2. **Enhance Infrastructure**
-   - Review open issues and submit PRs
-   - Test and update documentation
-   - Optimize performance
-   - Improve deployment solutions
 
-1. Fork the repo and create your branch from `main`.
+    - Review open issues and submit PRs
+    - Test and update documentation
+    - Optimize performance
+    - Improve deployment solutions
+
+3. Fork the repo and create your branch from `main`.
     1. The name of the branch should start with the issue number and be descriptive of the changes you are making.
     1. eg. 40--add-test-for-bug-123
-2. If you've added code that should be tested, add tests.
-3. Ensure the test suite passes.
-4. Make sure your code lints.
-5. Issue that pull request!
+4. If you've added code that should be tested, add tests.
+5. Ensure the test suite passes.
+6. Make sure your code lints.
+7. Issue that pull request!
 
 ## Styleguides
 
@@ -74,18 +76,17 @@ This section lists the labels we use to help us track and manage issues and pull
 -   `documentation` - Issues or pull requests related to documentation.
 -   `good first issue` - Good for newcomers.
 
-
 ## Getting Help
 
-- Join [Discord](https://discord.gg/ai16z)
-- Check [FAQ](docs/community/faq.md)
-- Create GitHub issues
+-   Join [Discord](https://discord.gg/ai16z)
+-   Check [FAQ](docs/community/faq.md)
+-   Create GitHub issues
 
 ## Additional Resources
 
-- [Local Development Guide](docs/guides/local-development.md)
-- [Configuration Guide](docs/guides/configuration.md)
-- [API Documentation](docs/api)
+-   [Local Development Guide](docs/guides/local-development.md)
+-   [Configuration Guide](docs/guides/configuration.md)
+-   [API Documentation](docs/api)
 
 ## Contributor Guide
 
@@ -101,19 +102,19 @@ In the interest of fostering an open and welcoming environment, we as contributo
 
 Examples of behavior that contributes to creating a positive environment include:
 
-- Using welcoming and inclusive language
-- Being respectful of differing viewpoints and experiences
-- Gracefully accepting constructive criticism
-- Focusing on what is best for the community
-- Showing empathy towards other community members
+-   Using welcoming and inclusive language
+-   Being respectful of differing viewpoints and experiences
+-   Gracefully accepting constructive criticism
+-   Focusing on what is best for the community
+-   Showing empathy towards other community members
 
 Examples of unacceptable behavior include:
 
-- The use of sexualized language or imagery and unwelcome sexual attention or advances
-- Trolling, insulting/derogatory comments, and personal or political attacks
-- Public or private harassment
-- Publishing others' private information without explicit permission
-- Other conduct which could reasonably be considered inappropriate in a professional setting
+-   The use of sexualized language or imagery and unwelcome sexual attention or advances
+-   Trolling, insulting/derogatory comments, and personal or political attacks
+-   Public or private harassment
+-   Publishing others' private information without explicit permission
+-   Other conduct which could reasonably be considered inappropriate in a professional setting
 
 #### Our Responsibilities
 

SECURITY.md

@@ -0,0 +1,125 @@
+# Security Policy
+
+## Supported Versions
+
+Given the early stage of the project, we currently only support the latest version with security updates:
+
+| Version | Supported          |
+| ------- | ------------------ |
+| 0.0.x   | :white_check_mark: |
+| < 0.0.1 | :x:                |
+
+## Reporting a Vulnerability
+
+We take the security of Eliza seriously. If you believe you have found a security vulnerability, please report it to us following these steps:
+
+### Private Reporting Process
+
+1. **DO NOT** create a public GitHub issue for the vulnerability
+2. Send an email to security@eliza.builders with:
+    - A detailed description of the vulnerability
+    - Steps to reproduce the issue
+    - Potential impact of the vulnerability
+    - Any possible mitigations you've identified
+
+### What to Expect
+
+-   **Initial Response**: Within 48 hours, you will receive an acknowledgment of your report
+-   **Updates**: We will provide updates every 5 business days about the progress
+-   **Resolution Timeline**: We aim to resolve critical issues within 15 days
+-   **Disclosure**: We will coordinate with you on the public disclosure timing
+
+## Security Best Practices
+
+### For Contributors
+
+1. **API Keys and Secrets**
+
+    - Never commit API keys, passwords, or other secrets to the repository
+    - Use environment variables as described in our secrets management guide
+    - Rotate any accidentally exposed credentials immediately
+
+2. **Dependencies**
+
+    - Keep all dependencies up to date
+    - Review security advisories for dependencies regularly
+    - Use `pnpm audit` to check for known vulnerabilities
+
+3. **Code Review**
+    - All code changes must go through pull request review
+    - Security-sensitive changes require additional review
+    - Enable branch protection on main branches
+
+### For Users
+
+1. **Environment Setup**
+
+    - Follow our [secrets management guide](docs/guides/secrets-management.md) for secure configuration
+    - Use separate API keys for development and production
+    - Regularly rotate credentials
+
+2. **Model Provider Security**
+
+    - Use appropriate rate limiting for API calls
+    - Monitor usage patterns for unusual activity
+    - Implement proper authentication for exposed endpoints
+
+3. **Platform Integration**
+    - Use separate bot tokens for different environments
+    - Implement proper permission scoping for platform APIs
+    - Regular audit of platform access and permissions
+
+## Security Features
+
+### Current Implementation
+
+-   Environment variable based secrets management
+-   Type-safe API implementations
+-   Automated dependency updates via Renovate
+-   Continuous Integration security checks
+
+### Planned Improvements
+
+1. **Q4 2024**
+
+    - Automated security scanning in CI pipeline
+    - Enhanced rate limiting implementation
+    - Improved audit logging
+
+2. **Q1 2025**
+    - Security-focused documentation improvements
+    - Enhanced platform permission management
+    - Automated vulnerability scanning
+
+## Vulnerability Disclosure Policy
+
+We follow a coordinated disclosure process:
+
+1. Reporter submits vulnerability details
+2. Our team validates and assesses the report
+3. We develop and test a fix
+4. Fix is deployed to supported versions
+5. Public disclosure after 30 days or by mutual agreement
+
+## Recognition
+
+We believe in recognizing security researchers who help improve our security. Contributors who report valid security issues will be:
+
+-   Credited in our security acknowledgments (unless they wish to remain anonymous)
+-   Added to our security hall of fame
+-   Considered for our bug bounty program (coming soon)
+
+## License Considerations
+
+As an MIT licensed project, users should understand:
+
+-   The software is provided "as is"
+-   No warranty is provided
+-   Users are responsible for their own security implementations
+-   Contributors grant perpetual license to their contributions
+
+## Contact
+
+-   Security Issues: security@eliza.builders
+-   General Questions: Join our [Discord](https://discord.gg/ai16z)
+-   Updates: Follow our [security advisory page](https://github.com/ai16z/eliza/security/advisories)

agent/package.json

@@ -25,6 +25,7 @@
         "@ai16z/plugin-node": "workspace:*",
         "@ai16z/plugin-solana": "workspace:*",
         "@ai16z/plugin-starknet": "workspace:*",
+        "@ai16z/plugin-coinbase": "workspace:*",
         "readline": "^1.3.0",
         "ws": "^8.18.0",
         "yargs": "17.7.2"

agent/src/index.ts

@@ -25,6 +25,7 @@ import {
 import { bootstrapPlugin } from "@ai16z/plugin-bootstrap";
 import { solanaPlugin } from "@ai16z/plugin-solana";
 import { nodePlugin } from "@ai16z/plugin-node";
+import { coinbaseCommercePlugin } from "@ai16z/plugin-coinbase";
 import Database from "better-sqlite3";
 import fs from "fs";
 import readline from "readline";
@@ -249,6 +250,10 @@ export function createAgent(
             bootstrapPlugin,
             nodePlugin,
             character.settings.secrets?.WALLET_PUBLIC_KEY ? solanaPlugin : null,
+            character.settings.secrets?.COINBASE_COMMERCE_KEY ||
+            process.env.COINBASE_COMMERCE_KEY
+                ? coinbaseCommercePlugin
+                : null,
         ].filter(Boolean),
         providers: [],
         actions: [],

commitlint.config.js

@@ -0,0 +1 @@
+module.exports = { extends: ["@commitlint/config-conventional"] };

docs/README.md

@@ -1,6 +1,9 @@
 # Eliza - Multi-agent simulation framework
+
 # https://github.com/ai16z/eliza
+
 # Visit https://eliza.builders for support
+
 # dev branch
 
 <img src="./docs/static/img/eliza_banner.jpg" alt="Eliza Banner" width="100%" />

docs/docs/community/best-practices.md

@@ -44,4 +44,4 @@ It is imperative to run all existing tests (`pnpm test`) before creating a PR to
 
 ## Branching Strategy
 
-All new features and bug fixes must target the `main` branch, except when they are specific to a previously released version. In such scenarios, the bug fix PR should target the respective release branch. If necessary, changes will be backported from the `main` branch to a release branch, excluding any modifications that involve consensus-breaking features or API changes.
+All new features and bug fixes must target the `main` branch, except when they are specific to a previously released version. In such scenarios, the bug fix PR should target the respective release branch. If necessary, changes will be backported from the `main` branch to a release branch, excluding any modifications that involve consensus-breaking features or API changes.