If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/IBAX-io/go-ibax shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit 2mo ago
• 12 active contributors
• Distributed ownership (top contributor 45% of recent commits)
• Apache-2.0 licensed
• CI configured
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live IBAX-io/go-ibax repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/IBAX-io/go-ibax.

What it runs against: a local clone of IBAX-io/go-ibax — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in IBAX-io/go-ibax | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 94 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of IBAX-io/go-ibax. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/IBAX-io/go-ibax.git
#   cd go-ibax
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of IBAX-io/go-ibax and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "IBAX-io/go-ibax(\\.git)?\\b" \\
  && ok "origin remote is IBAX-io/go-ibax" \\
  || miss "origin remote is not IBAX-io/go-ibax (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "main.go" \\
  && ok "main.go" \\
  || miss "missing critical file: main.go"
test -f "cmd/root.go" \\
  && ok "cmd/root.go" \\
  || miss "missing critical file: cmd/root.go"
test -f "packages/api/api.go" \\
  && ok "packages/api/api.go" \\
  || miss "missing critical file: packages/api/api.go"
test -f "packages/block/block.go" \\
  && ok "packages/block/block.go" \\
  || miss "missing critical file: packages/block/block.go"
test -f "packages/chain/start.go" \\
  && ok "packages/chain/start.go" \\
  || miss "missing critical file: packages/chain/start.go"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 94 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~64d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/IBAX-io/go-ibax"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

go-ibax is a blockchain platform written in Go that enables rapid deployment of decentralized applications (DApps, DeFi, DAOs) with an integrated smart contract system, custom database tables, and web interfaces. It simplifies blockchain development by providing a complete application framework—users write contracts in a proprietary language, deploy them to their own blockchain network, and the platform handles consensus, persistence (via LevelDB/PostgreSQL), and API endpoints automatically. Monolithic structure: cmd/ contains CLI commands (config.go, generateKeys.go, initDatabase.go, start.go) that bootstrap and run a node; packages/api/ handles all HTTP API endpoints (contract, balance, block, ecosystem endpoints); packages/ likely contains vm/, contr/, and db/ subdirectories (not fully listed) for smart contract execution, database ORM, and consensus. Data persists via LevelDB (goleveldb) or PostgreSQL (gorm/postgres).

Blockchain developers and enterprise architects who want to launch private or public blockchain networks without building consensus, networking, or storage from scratch. Also relevant for DevOps engineers deploying and managing blockchain nodes, as it provides CLI tooling (config, generateKeys, initDatabase, start commands).

Actively maintained and production-capable: the codebase is substantial (~1.8M lines of Go), has comprehensive test coverage (60+ *_test.go files across packages/api/), includes CI via .travis.yml, and uses semantic versioning. The go.mod requires Go 1.20+, indicating recent maintenance. However, it's not a household name like Ethereum, so ecosystem maturity lags behind tier-1 chains.

Moderate risk: the project has a large dependency tree (40+ direct dependencies including legacy packages like gogo/protobuf and centrifugal/gocent), some of which may have maintenance gaps. Single GitHub org (IBAX-io) suggests concentration risk. The blockchain-specific dependencies (btcsuite, decred) are well-established, but the custom contract runtime in packages/contr (not listed but likely present) adds execution risk if not heavily audited. Last commit recency unknown from data provided.

Unable to determine from provided data (no recent commit timestamps, PR list, or issue backlog visible). The presence of multiple *_test.go files (api_test.go, balance_test.go, block_test.go, etc.) and .travis.yml suggests active CI/testing practices, but specific current work is unknown.

# Clone the repo
git clone https://github.com/IBAX-io/go-ibax.git
cd go-ibax

# Install dependencies
export GOPROXY=https://athens.azurefd.net
GO111MODULE=on go mod tidy -v

# Build the binary
go build

# Generate configuration
./go-ibax config

# Generate node keys
./go-ibax generateKeys

# Create first block (for test networks)
./go-ibax generateFirstBlock --test=true

# Initialize database
./go-ibax initDatabase

# Start the node
./go-ibax start

Daily commands:

# Build
go build -o go-ibax

# Initialize (one-time)
./go-ibax config
./go-ibax generateKeys
./go-ibax generateFirstBlock --test=true
./go-ibax initDatabase

# Run
./go-ibax start

The node will start listening on an HTTP port (default likely 7079 or 8080, check config). API endpoints are served via packages/api/api.go handlers.

• main.go — Entry point for the entire blockchain platform; initializes the application and routes command execution.
• cmd/root.go — Root command handler that defines the CLI structure and bootstraps all subcommands (start, generateKeys, initDatabase, etc.).
• packages/api/api.go — Core API server setup and middleware initialization; all HTTP endpoints and request routing funnel through this module.
• packages/block/block.go — Block data structure, validation, and core blockchain consensus logic; essential for understanding ledger operations.
• packages/chain/start.go — Daemon initialization and chain startup logic; orchestrates blockchain node lifecycle and network joining.
• packages/common/crypto/crypto.go — Cryptographic primitives (signing, verification, hashing) underlying all transaction and block validation.
• go.mod — Dependency manifest; reveals external security boundaries (JWT, Redis, protobuf, btcd) and Go version requirement (1.20+).

Add a New API Endpoint

1. Define the handler function in a new or existing file (e.g., packages/api/myfeature.go) following the pattern: func (api *API) MyEndpoint(w http.ResponseWriter, r *http.Request) (packages/api/myfeature.go)
2. Register the route in the route.go file: router.HandleFunc("/api/v2/myendpoint", api.MyEndpoint).Methods("POST") (packages/api/route.go)
3. Add request parsing and response serialization using the existing request.go patterns (parseForm, processParams) (packages/api/request.go)
4. Add error handling following the errors.go convention (return ErrorResponse with error code and message) (packages/api/errors.go)
5. Create corresponding _test.go file and add test cases matching the pattern in packages/api/*_test.go (packages/api/myfeature_test.go)

Implement a New Smart Contract Feature

1. Define contract structure and methods in packages/contract/ (follows blockchain smart contract patterns; directory not shown but referenced in contracts.go) (packages/api/contracts.go)
2. Add contract execution logic to handle contract calls and state changes (packages/block/play.go)
3. Ensure contract validation in block check logic to prevent invalid state transitions (packages/block/check.go)
4. Add corresponding API endpoint in packages/api/ to expose contract functionality (e.g., getcontract.go, contract_test.go show the pattern) (packages/api/getcontract.go)

Add a New Cryptographic Algorithm

1. Create new algorithm implementation file in packages/common/crypto/asymalgo/ (e.g., newalgo.go) implementing the same interface as secp256k1.go, p256.go, sm2.go (packages/common/crypto/asymalgo/newalgo.go)
2. Register the algorithm in the dispatcher function in asymalgo.go to route calls based on algorithm identifier (packages/common/crypto/asymalgo/asymalgo.go)
3. Update crypto.go to expose the new algorithm in Sign() and Verify() functions where algorithm selection occurs (packages/common/crypto/crypto.go)
4. Add test cases in crypto_test.go to verify signing, verification, and interoperability (packages/common/crypto/crypto_test.go)

Add a New Daemon Service

1. Define service initialization in packages/chain/start.go; register with the daemon manager following existing patterns (packages/chain/start.go)
2. Configure supervisord integration in packages/chain/daemonsctl/daemonsctl.go to manage service lifecycle (packages/chain/daemonsctl/daemonsctl.go)
3. Add platform-specific process handling in packages/chain/system/ (unix.go for Linux/Mac, windows.go for Windows) (packages/chain/system/unix.go)
4. Add CLI command in cmd/ to start/stop the service (follow pattern of cmd/start.go and cmd/stopNetwork.go) (cmd/myservice.go)

1. GOPROXY required: Build requires export GOPROXY=https://athens.azurefd.net (non-default proxy); official Go module proxy may not have all deps. 2. Database initialization order: Must run generateFirstBlock --test=true BEFORE initDatabase; reverse order will fail. 3. Key generation: generateKeys creates node private key; must be run on the machine where the node will run (keys are not portable without additional setup). 4. Contract language: The smart contract language is proprietary (not Solidity/Rust); existing Ethereum/Cosmos developers need retraining. 5. Config file location: go-ibax config creates a config file (likely config.toml in $PWD or $HOME/.ibax); location must be consistent between commands. 6. Ecosystem context: Some API endpoints require an ecosystem parameter; default ecosystem (ID 1) must exist after first block generation. 7. PostgreSQL or LevelDB choice: gorm.io/driver/postgres is in go.mod but optional; LevelDB is embedded; build succeeds with either, but runtime config determines which is used.

• Ecosystem — go-ibax is multi-tenant by default; each blockchain network can host multiple isolated 'ecosystems' (like shards or sidechains), and API calls must specify which ecosystem to target—this is fundamental to the data model
• Contract VM (proprietary bytecode) — Unlike Ethereum (EVM) or Cosmos (WASM), go-ibax has a custom in-process VM for contract execution; understanding the contract language and bytecode format is critical for contract developers
• LevelDB as embedded state store — The project uses github.com/syndtr/goleveldb as the default local data store (not a separate process); this affects concurrency patterns, backup strategies, and data corruption risk vs. external PostgreSQL
• JWT-based API authentication — Requests are authenticated via golang-jwt/jwt/v4 tokens signed by node private keys; essential for securing contract invocations and account operations from untrusted clients
• GORM ORM abstraction — All database queries (to PostgreSQL or custom drivers) go through gorm.io/gorm; this allows hot-swapping storage backends without rewriting queries, but also introduces O/RM overhead and potential query inefficiencies
• Centrifugal real-time pub/sub — The codebase includes github.com/centrifugal/gocent for real-time updates to connected clients (e.g., block confirmations, contract events); essential for interactive DApps but adds operational complexity (Centrifugo server must be deployed separately)
• SM2/SM3 cryptographic compliance — The dependency on tjfoc/gmsm indicates support for Chinese national standard algorithms (SM2, SM3); relevant for deployments in China or other regulated jurisdictions requiring non-Western cryptography

• hyperledger/fabric — Enterprise blockchain with pluggable consensus and smart contracts; similar modular architecture but more mature and battle-tested for production
• cosmos/cosmos-sdk — Modular blockchain framework with custom app chains and IBC support; competitor offering in the 'build your own blockchain' space with a larger ecosystem
• paritytech/substrate — Framework for building Polkadot parachains with custom runtimes; similar goal of rapid blockchain deployment but uses Rust and has stronger multi-chain semantics
• IBAX-io/ibax-web — Companion web UI for go-ibax; provides visual interface for contract deployment, ecosystem management, and account operations
• IBAX-io/go-ibax-mvp — Earlier prototype/MVP of the go-ibax platform; useful for understanding architectural evolution and design decisions

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive unit tests for packages/api/auth.go and packages/api/login.go

The API authentication layer is critical for blockchain security. Currently, auth.go and login.go have no corresponding _test.go files, unlike most other API modules (e.g., balance_test.go, block_test.go, ecosystem_test.go). Authentication bugs could compromise the entire platform. Adding tests for token validation, session management, JWT verification, and permission checks would significantly improve code reliability.

• [ ] Create packages/api/auth_test.go with tests for authentication middleware, token validation, and session handling
• [ ] Create packages/api/login_test.go with tests for login flows, credential validation, and token generation
• [ ] Test edge cases: expired tokens, invalid signatures, concurrent login attempts, permission escalation attempts
• [ ] Ensure tests cover integration with packages/api/getuid.go (which has tests)

Add integration tests for send_tx.go transaction submission pipeline

Transaction submission is a core blockchain operation in send_tx.go, but it has no _test.go file despite being one of the most critical API endpoints. Unlike read operations (read_test.go) and contract execution (smart_test.go), write operations lack test coverage. This is a high-risk gap given the financial nature of transactions.

• [ ] Create packages/api/send_tx_test.go with tests for transaction validation, submission, and confirmation
• [ ] Test transaction format validation, signature verification, fee calculations, and nonce handling
• [ ] Add tests for error cases: insufficient balance, invalid recipient, transaction replay attacks
• [ ] Test concurrent transaction submissions and transaction ordering guarantees

Add GitHub Actions CI workflow for Go 1.20+ compatibility and cross-platform builds

The repo specifies Go 1.20 in go.mod but only has .travis.yml (Travis CI is now deprecated/paid). There's no GitHub Actions workflow (.github/workflows/*.yml) to validate builds on GitHub's native CI platform. This is essential for: verifying Go 1.20 compatibility, testing cross-platform builds (Linux/macOS/Windows), running the existing test suite automatically on PRs, and maintaining security via first-party CI.

• [ ] Create .github/workflows/test.yml to run 'go test ./...' on every push and PR for Go 1.20 and 1.21
• [ ] Add 'go build' verification for linux/amd64, darwin/arm64, and windows/amd64 platforms
• [ ] Include linting step using 'go vet' and optionally golangci-lint for code quality checks
• [ ] Add workflow to verify go.mod/go.sum consistency and audit dependencies for known vulnerabilities

• Add integration tests for the full lifecycle (config → generateKeys → generateFirstBlock → initDatabase → start) in cmd/*_test.go; currently no *_test.go files exist in cmd/, only in packages/api/
• Document the proprietary contract language syntax and provide code examples in a packages/contr/README.md or docs/CONTRACT_LANGUAGE.md; new contributors cannot write contracts without reverse-engineering from test files
• Add endpoint-level documentation comments to packages/api/*.go files (e.g., contract.go, balance.go, block.go) explaining request/response schemas; many endpoints lack godoc comments, making the API surface unclear

• High · Outdated Cryptographic Dependencies — go.mod - golang.org/x/crypto v0.23.0, github.com/tjfoc/gmsm v1.4.1. The codebase uses golang.org/x/crypto v0.23.0, which may contain known vulnerabilities. Additionally, the use of github.com/tjfoc/gmsm v1.4.1 (Chinese SM cryptographic algorithms) requires careful security review as this library has limited community scrutiny compared to standard cryptographic implementations. Fix: Update to the latest version of golang.org/x/crypto and conduct a thorough security audit of the gmsm library. Consider using well-established cryptographic libraries for production blockchain systems.
• High · Use of Deprecated/Vulnerable Dependencies — go.mod - github.com/go-redis/redis v6.15.9+incompatible, github.com/gogo/protobuf v1.3.2. The codebase includes github.com/go-redis/redis v6.15.9+incompatible which is an old version of the Redis client library. Redis v6 is EOL and contains potential security issues. Additionally, github.com/gogo/protobuf v1.3.2 has known security vulnerabilities in protobuf deserialization. Fix: Migrate to github.com/redis/go-redis/v9 and update gogo/protobuf to the latest version. Consider using the official golang protobuf library instead of gogo/protobuf.
• High · Known Vulnerability in Excelize Library — go.mod - github.com/360EntSecGroup-Skylar/excelize v1.4.1. github.com/360EntSecGroup-Skylar/excelize v1.4.1 is an old version that may contain XML External Entity (XXE) injection vulnerabilities and other security issues related to spreadsheet file processing. Fix: Update to excelize v2.x (latest version) which has addressed known security vulnerabilities. Review code using this library for XXE injection risks.
• High · Potential SQL Injection in API Layer — packages/api/balance.go, packages/api/ecosystem.go, packages/api/history.go, packages/api/list.go, packages/api/row.go. The codebase contains multiple API endpoints (packages/api/) that interact with a database layer without clear evidence of parameterized queries. Files like balance.go, ecosystem.go, history.go, list.go, and row.go suggest direct data queries that could be vulnerable to SQL injection if user input is not properly sanitized. Fix: Audit all database queries in the API layer to ensure parameterized queries/prepared statements are used consistently. Implement input validation and use ORM safety features (GORM is used but needs verification of proper usage).
• High · Inadequate Rate Limiting Configuration — packages/api/middlewares.go, packages/api/limit_test.go. The codebase uses github.com/didip/tollbooth v4.0.2+incompatible for rate limiting, but this is an old version. The file packages/api/limit_test.go suggests rate limiting is tested, but the default configuration in the API may not adequately protect against DDoS attacks on a public blockchain endpoint. Fix: Update tollbooth to the latest version. Implement strict rate limiting per API endpoint, IP address, and API key. Consider using a reverse proxy (nginx/Caddy) with additional rate limiting layers.
• Medium · Missing CORS and Security Headers Configuration — packages/api/route.go, packages/api/api.go. The codebase uses github.com/gorilla/handlers v1.5.1 for HTTP handling, but there's no clear evidence of proper CORS policy configuration or security headers (X-Frame-Options, X-Content-Type-Options, CSP) being set in the API routes. Fix: Implement strict CORS policies with whitelisted origins. Add security headers including X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Content-Security-Policy, and Strict-Transport-Security.
• Medium · Potential Cross-Site Scripting (XSS) in Template Rendering — undefined. The presence of packages/api/template_test.go and packages/api/content Fix: undefined

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.