GenkiPool

Overview

GenkiPool is a Radix validator and community-tooling effort run by Luis Alberto Reoyo Bolaños (genkipool on GitHub). Beyond operating the GENKI validator node, the project ships an ecosystem education/onboarding web app and a native Rust SDK for Radix.

Community App & Developer Console

The Radix Community portal began as an onboarding web app – wallet connection, staking guidance, batched staking, unstaking, and claiming across multiple validators in a single transaction, and an Alchemy Pay "Quick Buy with Card" onramp so users can purchase XRD directly with a card – and has since grown into a browser-based developer console.

The console bundles roughly twenty tools that run against Radix mainnet from the browser through the connected Radix Wallet, including an MCP server for AI agents, transaction manifest building and sending, package deployment, token creation, a component dashboard, metadata configuration, an SBOR encoder/decoder, a test faucet, a wallet playground, royalty claiming for Scrypto packages, an address book, and Olympia→Babylon address conversion.

MCP server

The console is addressable by machine as well as by browser. radix-community.genkipool.com/api/mcp is a public Model Context Protocol endpoint over streamable HTTP – stateless, unauthenticated, and open to any MCP client. Read on 18 August 2026, initialize returns protocol revision 2025-06-18 and identifies itself as radix-community 1.0.0; a plain GET is refused with 405 and the message that JSON-RPC belongs in a POST, which is the spec-correct answer rather than a broken route.

tools/list returns 34 tools in a single page, and every one of them carries the readOnlyHint annotation – the server proposes, it never disposes. They fall into five groups: three that search and read the site’s curated documentation; thirteen that read the ledger through the Gateway (entity lookup, balances, transactions, validators, network status, XRD price, NFT data, resource holders, component state, key-value stores, blueprint interfaces); ten that build, validate, preview and explain transaction manifests, including manifests for token creation, NFT collections, the Stokenet faucet and package deployment; five address and SBOR utilities; and three covering Radix Seal signature verification and local wallet-connector setup.

The server also publishes an Agent Skill at /api/mcp/skills: a 26 KB markdown usage guide a client can load before its first call, so the agent arrives knowing what the tools are for rather than inferring it from schemas. It is a second, distinct MCP surface from the SDK’s local radixdlt-connector-mcp described below – that one runs on the developer’s machine and drives the mobile wallet over Radix Connect; this one is hosted and custodies nothing. Both are indexed on Radix for AI Agents.

Rust SDK

GenkiPool publishes radixdlt-rust-sdk, a set of native Rust building blocks for Radix that were previously available mainly in JavaScript/TypeScript. It is dual-licensed Apache-2.0/MIT and includes crates such as radixdlt-rola (ROLA authentication), radixdlt-address, radixdlt-keystore (Ed25519), radixdlt-gateway-tx, radixdlt-connect (WebRTC), and radixdlt-connector-mcp – an MCP server that lets AI agents build transactions and push them to the Radix mobile wallet.

Radix Seal

Radix Seal is a self-custodial cryptography suite inside the Community portal that uses ROLA (Radix Off-Ledger Authentication) to turn the Radix Wallet into a passkey. It provides three operations: document signing (a file is hashed locally and only the hash is signed, proving integrity, timestamp, and control of the account key), file encryption (the AES-256 key is derived from a deterministic ROLA signature over a per-file challenge, so only the encrypting account can re-derive it, and content never leaves the browser), and end-to-end encrypted chat where both parties prove identity by signing with their wallets. All cryptography runs client-side – no servers ever store files, messages, or keys – and signatures or encryption records can optionally be anchored as soulbound NFTs on the Radix Ledger for permanent, verifiable proof. Available at radix-community.genkipool.com/seal.

Validator directory pages

On 8 August 2026 the project announced in the Radix DLT Telegram that every validator in the portal now has a shareable, search-indexable page of its own, reachable by link or through WhatsApp and Telegram share buttons. Checked the same day, a validator page serves a canonical URL, an Open Graph and Twitter summary_large_image card, and a generated 1200×630 preview image rendered per validator; the site's sitemap lists 158 such URLs (79 validators across the English and Spanish locales) out of 242 entries, under a robots.txt that allows every crawler.

The effect is that individual validators become addressable outside a wallet or an explorer – a link that previews when posted, and a page a search engine or an AI crawler can read. The project gives the latter as an explicit motivation. Validator identity on Radix otherwise lives in on-ledger metadata and in the wallet's staking screen, neither of which is a web page; the third-party dashboards that filled that gap have been thinning out – RadixCharts closed, and radixdashboard.com is now a parking page.

Governance front end

Since 26 September 2026 the portal has carried a governance section that lists and casts votes for the two governance systems running on Radix mainnet, announced by its operator in the Radix DLT Telegram. One is the Radix DAO's governance component, whose official front end is vote.radixdao.org; the other is Radix Consultation's component, whose front end is consultation.mountain-top.live. The site reads each component's temperature checks and proposals from its ledger state, so a new vote appears without a code change, and takes the weighted tallies from each system's own vote collector (systems.ts). Read on 27 September, it listed 13 votes, 2 of them open: the ballot to ratify the Radix DAO Charter and its governance framework, and the Consultation's temperature check on how to allocate the USDC left behind by the Hyperlane asset drain.

Votes are signed in the Radix Wallet, and one transaction can cast the same vote from several accounts, an option the operator added the same evening. The transaction manifest the site builds calls the component's vote method once per selected account and then calls deposit_batch on each of those accounts. The second call is what makes the wallet ask every account to sign: the component checks each account's owner rule, and the wallet signs only for accounts whose owner-protected methods the manifest calls (voteManifest.ts).

Each vote also has a Comparison tab that recounts the same ballots under other rules. Radix governance counts each XRD of voting power as one vote; the tab keeps every voter's choice and balance and changes only how much the vote weighs. It applies 23 rules in four groups: by holdings (capped, square root, logarithmic, tiered), by address (one vote per account, with minimum-balance and anti-sybil variants), by account age, and hybrids such as a double majority of XRD and headcount. For each rule it shows the result and how concentrated the voting power is (votingMethods.ts). How the Radix DAO itself decides is set out on Radix Governance.

The whole portal, governance section included, is public on GitHub as genkipool/Radix_Community, licensed AGPL-3.0.

External Links

• Radix Community – GenkiPool
• GENKI Validator
• Radix_Community (portal source) – GitHub
• radixdlt-rust-sdk – GitHub
• GenkiPool – X (Twitter)
• GenkiPool – Telegram