Gateway Architecture | Noctyra Security Research Inc.

XMR Monero Engine

Privacy is only effective if implementation is flawless. The Noctyra Monero engine completely isolates the RPC daemon from the public web, binding it exclusively to the internal loopback (`127.0.0.1`).

Instead of reusing addresses, the engine asks the `monero-wallet-rpc` to generate a mathematically unique subaddress for every single checkout session. This ensures that even if a blockchain analyst attempts to trace your incoming payments, the transactions cannot be linked together to determine your revenue volume.

Subaddress Isolation Protocol

// Secure cURL to local RPC loopback
$rpcData = json_encode([
    'jsonrpc' => '2.0',
    'id'      => '0',
    'method'  => 'create_address',
    'params'  => ['account_index' => 0]
]);

$ch = curl_init('http://127.0.0.1:18084/json_rpc');
curl_setopt($ch, CURLOPT_POSTFIELDS, $rpcData);
// ... cURL execution ...

// Store the isolated address in the DB
$stmt = $db->prepare('INSERT INTO invoices (address) VALUES (?)');
$stmt->execute([$response['result']['address']]);

Zero-Shell Electrum Execution

// Building args securely without shell strings
$argv = [
    BTC_ELECTRUM_CMD,
    '--dir', BTC_WALLET_DIR,
    '-w',    BTC_WALLET_FILE,
    'createnewaddress'
];

// proc_open bypasses the OS shell entirely
$proc = proc_open($argv, $desc, $pipes);
$address = stream_get_contents($pipes[1]);

if (is_valid_btc_address($address)) {
    // Address generated cleanly from zpub
}

BTC Bitcoin Engine

Traditional Bitcoin gateways require a "hot wallet" on the server, meaning if your VPS is compromised, your funds are stolen. The Noctyra BTC engine uses a strict Watch-Only Architecture via a headless Electrum daemon.

By providing only your Master Public Key (`zpub`/`xpub`) to the server, the gateway uses BIP32/BIP44 to mathematically derive fresh, deterministic Bitcoin addresses for every invoice. The private keys literally never touch the server. Furthermore, we eliminated shell-injection vulnerabilities by executing daemon commands via PHP's `proc_open()`, passing arguments strictly as an array rather than system strings.

The Float-Drift Exploit

Most junior implementations of crypto payments use floating-point arithmetic (e.g., measuring amounts in standard decimal XMR or BTC). Due to IEEE 754 float precision issues, this leaves systems vulnerable to rounding-error exploits.

An attacker can intentionally send a micro-fraction less than the required amount. A poorly coded system will round the float up, marking a partially paid invoice as fully paid.

The Noctyra Solution: We strip floats entirely during blockchain validation. All network math is converted instantly into atomic integer units (1e12 Piconeros for XMR or Satoshis for BTC). If an attacker is short by even one single atomic unit, the system strictly denies fulfillment.

Atomic Verification Source

// Convert float to Satoshis / Piconeros
function crypto_to_atomic($v): int {
    if (is_string($v) && stripos($v, 'e') !== false) {
        $v = sprintf('%.8F', (float)$v);
    }
    // Multiply by 10^8 (BTC) or 10^12 (XMR)
    return (int)round(((float)$v) * ATOMIC_MULTIPLIER);
}

if ($confirmedAtomic >= $expectedAtomic) {
    process_payment();
}

Concurrency Lock Mechanism

$db->beginTransaction();

// State must explicitly NOT be paid already
$sql = 'UPDATE invoices 
        SET status="paid" 
        WHERE id=? AND status != "paid"';

$upd = $db->prepare($sql);
$upd->execute([$id]);

// RowCount dictates webhook execution
$wasFirst = ($upd->rowCount() === 1);
$db->commit();

if ($wasFirst) {
    trigger_webhook(); 
}

Race Conditions & Double-Fires

A fatal flaw in standard gateways is the "Double Webhook" race condition. If a user refreshes the polling page at the exact millisecond the background Sweeper Cron Job runs, the system processes the payment twice—potentially granting double account credits or shipping two products.

The Noctyra Solution: We do not rely on PHP for state checks. We push the locking mechanism down to the SQLite database level using Write-Ahead Logging (WAL) and atomic `UPDATE` constraints. Even if 50 requests hit the system at the exact same millisecond, the database engine mathematically guarantees the fulfillment webhook will only ever fire exactly once.

L7 DDoS & ID Enumeration

Public-facing checkout systems are targets for automated abuse. Hackers will attempt to iterate through invoice IDs (`?id=1`, `?id=2`) to scrape your sales data, or spam checkout creation to bloat your database and crash your daemon.

The Noctyra Solution: The gateway is functionally invisible. Invoice views are protected by dynamically generated, constant-time HMAC view tokens. Attempting to view an invoice without the exact cryptographic token results in an immediate `404 Not Found`.

Furthermore, invoice creation must be signed by your central server's Secret Key. Unauthorized parameters are mathematically rejected before they ever touch the database or wake up the daemons.

Merchant Server generates HMAC SHA256 Signature

↓

User Redirected to Gateway Checkout

↓

Gateway cryptographically validates Signature via hash_equals()

↓

Crypto Engine Generates Address & Encrypted View Token Issued

Ready to own your infrastructure?

Stop paying 5% to middlemen who ban high-risk businesses. Noctyra Gateway gives you absolute control over your revenue routing.

Request Deployment

Architecture of Trust