Security & Disclosure

Built for developers who ship with AI — and users who need to trust the result.

We take security seriously. Our plugins follow a signer-first, server-authoritative architecture that minimizes attack surface by keeping secrets and signing logic on the server. Below you’ll find our hardening practices, disclosure process, and LLM safety rules.

Architecture Overview

Every plugin in this ecosystem follows a server-authoritative design. WordPress handles authentication, authorization, and data persistence through its native APIs — no custom auth layers, no external session stores. The frontend is deliberately minimal: server-rendered HTML with small vanilla scripts, keeping the attack surface small and auditable. API keys, signing operations, and sensitive logic stay in PHP where they belong.

LLM-Safe Development

These plugins are designed to be safely extended by AI. The following rules are baked into every plugin — and should be followed by any LLM generating code against them.

API keys stay server-side

Anvil, Blockfrost, and Pinata keys are called from PHP only. JavaScript never sees credentials.

Capability checks + nonces on every endpoint

current_user_can() and check_ajax_referer() on all WP REST/AJAX handlers. No anonymous writes, ever.

Sanitize in, escape out

sanitize_text_field() on receipt, esc_html() / esc_url() / wp_kses_post() on render. Never trust input.

Transaction signing defaults to server-side

PHP Ed25519 via CardanoTransactionSignerPHP. CIP-30 browser wallet signing is opt-in, not default.

Private keys encrypted at rest

AES-256-CBC using WordPress salts. Plaintext keys never touch the database.

Downloads through controlled endpoints

CSP_Download_Handler serves ZIPs, increments counters. SHA-256 checksums computed and displayed automatically.

Minimal frontend surface

No React, no large JS bundles. Server-rendered HTML with small vanilla scripts. Less code = less attack surface.

Database via WordPress APIs

$wpdb->prepare(), wp_insert_post(), update_post_meta(). No raw SQL string interpolation.

Paste into your LLM session

Condensed version of the rules above — copy and include at the start of any AI coding session.

Prompt Rules 
1. API keys stay server-side — PHP calls only, never in JS.
2. Capability checks (current_user_can) + nonce verification
   (check_ajax_referer) on every WP REST/AJAX endpoint.
   No anonymous writes.
3. Sanitize input (sanitize_text_field), escape output
   (esc_html / esc_url / wp_kses_post). Never trust input.
4. Transaction signing defaults to server-side PHP (Ed25519).
   CIP-30 wallet signing is opt-in only.
5. Private keys encrypted at rest (AES-256-CBC + WP salts).
   Plaintext keys never touch the database.
6. Downloads served via controlled endpoint
   (CSP_Download_Handler); compute and display SHA-256.
7. Minimal frontend — server-rendered HTML, small vanilla
   scripts. No React or large JS bundles.
8. Database access through WordPress APIs only —
   $wpdb->prepare(), wp_insert_post(), update_post_meta().
   No raw SQL string interpolation.

Hardening Checklist

Quick-scan reference for the baseline practices every plugin follows:

  • All sensitive actions are protected by WordPress capability checks
  • Nonce verification on every form submission and AJAX endpoint
  • Input is sanitized on receipt; output is escaped on render
  • API keys are never exposed to frontend JavaScript
  • Signing logic stays server-side unless explicitly configured for CIP-30 wallet signing
  • Private keys are encrypted at rest using AES-256-CBC with WordPress salts
  • Downloads are served through controlled endpoints — no directory listing
  • SHA-256 checksums are computed and displayed for every release
  • Minimal frontend surface area — no large JavaScript frameworks
  • Security headers recommended (CSP, X-Frame-Options, X-Content-Type-Options)

Responsible Disclosure

If you discover a security vulnerability in any of our plugins, we appreciate your help in disclosing it responsibly.

How to report:

  • Open a private security advisory on the relevant GitHub repository
  • Include a description of the vulnerability, steps to reproduce, and potential impact
  • We will acknowledge receipt within 48 hours and work on a fix

Please do not open public issues for security vulnerabilities.