Internet-Draft DeMI SRO Payment Security July 2026
Shubralov Expires 29 January 2027 [Page]
Workgroup:
Independent
Internet-Draft:
draft-shubralov-demi-sro-payment-security-01
Published:
Intended Status:
Informational
Expires:
Author:
E. A. Shubralov
AI Cybersecurity LLC / IP Shubralov

Blockchain-Backed Risk Pooling and Self-Regulation Protocol for Alternative Payment Providers (DeMI)

Abstract

This document specifies a Best Current Practice (BCP) for risk management, automated self-regulation, and transaction settlement integrity among alternative payment service providers (APPs) operating in emerging markets without formal ISO/PCI-DSS coverage. It defines an architectural specification for a decentralized self-regulated organization (SRO) compensation pool deployed on the Ethereum Layer 1 blockchain. The protocol mitigates time-delayed fraud vectors, liquidity mismatches, and cross-border settlement frictions through cryptographic batching, zero-trust geo-distributed validator networks over private MPLS/satellite topologies, and automated algorithmic underwriting.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 29 January 2027.

Table of Contents

1. Introduction

Alternative Payment Providers (APPs) including payment aggregators, QR-code networks, and mobile wallet ecosystems handle substantial transaction volumes in South and Southeast Asia (e.g., India, Pakistan, Bangladesh, Vietnam, Cambodia). Due to their structural separation from legacy clearinghouses, these entities lack specialized international standards (ISO) or rigid frameworks (PCI-DSS) tailored to their operational risks.

The primary operational vulnerability is time-delayed fraud ("hit-and-run" exploits). In these scenarios, a customer authorizes a payment, the APP receives a temporary confirmation or clearing registry, and immediately credits the merchant. Days later, the clearing bank issues a chargeback due to card theft or friendly fraud. If the merchant has already withdrawn the funds, the APP incurs a capital loss.

This document outlines a standardized, extraterritorial approach to mitigate this risk by establishing a Self-Regulated Organization (SRO) backed by an automated, blockchain-hosted compensation pool. This protocol eliminates capital stagnation caused by fixed rolling reserves while providing immutable mathematical guarantees to financial regulators.

To ensure absolute resilience and eliminate any Single Point of Failure (SPOF), the underlying governance of the protocol completely rejects single-administrator control vectors. The operational and emergency management layers are hardcoded into an autonomous M-of-N consensus matrix distributed cryptographically among the National Embassy Nodes, guaranteeing system survivability and continuous recovery even in the event of partial cryptographic key compromise.

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. Protocol Mechanics and Smart Contract Architecture

The DeMI protocol shifts the risk management layer from private, auditable Web2 databases to an autonomous, public smart contract acting as a decentralized escrow and risk underwriter.

3.1. Transaction Batching Pipeline

To minimize Ethereum L1 gas expenditures, APPs MUST NOT execute on-chain transactions for individual payment actions.

  1. The local APP payment engine logs transactions in real-time.

  2. Every 10 minutes (the standard Epoch interval), the APP compiles all transaction metadata into a Merkle Tree.

  3. The root hash of the Merkle Tree, along with total volume and net risk metrics, is packaged into an on-chain batch submission.

3.2. Dynamic Algorithmic Underwriting

The DeMI contract maintains an on-chain ledger of merchant risk coefficients. Instead of static 10% rolling reserves, the contract dynamically evaluates the required fee contribution based on the formula:

Contribution Rate = Base_Rate * (1 + (Chargebacks / Total_Volume))

If a merchant's historical fraud rate spikes, the smart contract automatically increases their on-chain collateral requirement for subsequent epochs.

3.3. Core Solidity Implementation Reference

The compensation pool and risk management ledger MUST implement a decentralized, multi-governor smart contract architecture that rejects centralized ownership. Administrative functions such as regional node authorization and emergency fund restoration MUST require an on-chain M-of-N threshold consensus executed directly by the authenticated governance entities.

The core contract implementation is specified as follows:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

interface IERC20 {
    function transferFrom(
        address from,
        address to,
        uint256 amount
    ) external returns (bool);

    function transfer(
        address to,
        uint256 amount
    ) external returns (bool);

    function balanceOf(
        address account
    ) external view returns (uint256);

    function allowance(
        address owner,
        address spender
    ) external view returns (uint256);
}

contract DeMISROConsensusPool {
    struct MerchantProfile {
        uint256 totalVol;
        uint256 totalChb;
        uint256 riskTier;
        uint256 dynRate;
        uint256 totalContributed;
        uint256 claimsPaid;
    }

    struct EmergencyProposal {
        bytes32 targetMid;
        uint256 voteCnt;
        uint256 timestamp;
        bool executed;
        mapping(address => bool) hasVoted;
    }

    uint256 public constant BASE_RATE = 30;
    uint256 public constant MAX_CLAIM =
        500 * 10**6;
    uint256 public constant STOP_LOSS = 40;

    IERC20 public immutable token;
    uint256 public totalReserves;
    uint256 public monthlyClaims;
    uint256 public lastReset;
    bool public frozen;

    address[] public governors;
    mapping(address => bool) public isGov;
    uint256 public immutable threshold;

    mapping(address => bool) public embassies;
    mapping(bytes32 => MerchantProfile)
        public merchants;
    mapping(bytes32 => bool) public batches;
    mapping(uint256 => EmergencyProposal)
        public proposals;
    uint256 public propCnt;

    event EmbAuth(address indexed emb, bool st);
    event BatchProc(
        bytes32 indexed mid,
        bytes32 indexed root,
        uint256 contrib
    );
    event ClaimSettled(
        bytes32 indexed mid,
        uint256 amt,
        address indexed rec
    );
    event Rebate(
        address indexed val,
        uint256 amt
    );
    event Emergency(string reason);
    event Resume(
        uint256 indexed pid,
        uint256 votes
    );
    event PropInit(
        uint256 indexed pid,
        bytes32 indexed mid
    );

    modifier onlyGov() {
        require(isGov[msg.sender], "!gov");
        _;
    }

    modifier onlyNode() {
        require(
            embassies[msg.sender]
            || isGov[msg.sender],
            "!node"
        );
        _;
    }

    modifier whenNotFrozen() {
        require(!frozen, "frozen");
        _;
    }

    constructor(
        address _tok,
        address[] memory _govs,
        uint256 _thr
    ) {
        require(_tok != address(0), "!tok");
        require(_govs.length >= _thr, "!len");
        require(_thr > 0, "!thr");
        token = IERC20(_tok);
        threshold = _thr;
        lastReset = block.timestamp;
        for (uint256 i = 0;
             i < _govs.length;
             i++) {
            address g = _govs[i];
            require(g != address(0), "!adr");
            require(!isGov[g], "dup");
            isGov[g] = true;
            governors.push(g);
        }
    }

    function setEmbassy(
        address _emb,
        bool _st
    ) external onlyGov {
        require(_emb != address(0), "!emb");
        embassies[_emb] = _st;
        emit EmbAuth(_emb, _st);
    }

    function initiateRescue(
        bytes32 _mid
    ) external onlyNode returns (uint256) {
        require(frozen, "!frozen");
        propCnt++;
        EmergencyProposal storage p =
            proposals[propCnt];
        p.targetMid = _mid;
        p.voteCnt = 1;
        p.timestamp = block.timestamp;
        p.hasVoted[msg.sender] = true;
        emit PropInit(propCnt, _mid);
        return propCnt;
    }

    function voteRescue(
        uint256 _pid
    ) external onlyNode {
        require(frozen, "!frozen");
        EmergencyProposal storage p =
            proposals[_pid];
        require(!p.executed, "done");
        require(!p.hasVoted[msg.sender], "vtd");
        require(
            block.timestamp
            <= p.timestamp + 7 days,
            "exp"
        );
        p.hasVoted[msg.sender] = true;
        p.voteCnt++;
        if (p.voteCnt >= threshold) {
            p.executed = true;
            frozen = false;
            monthlyClaims = 0;
            lastReset = block.timestamp;
            emit Resume(_pid, p.voteCnt);
        }
    }

    function processBatch(
        bytes32 _mid,
        bytes32 _root,
        uint256 _vol,
        uint256 _chb
    ) external onlyNode whenNotFrozen {
        require(!batches[_root], "dup");
        require(_mid != bytes32(0), "!mid");
        MerchantProfile storage m =
            merchants[_mid];
        m.totalVol += _vol;
        m.totalChb += _chb;
        if (m.totalVol > 0) {
            uint256 r =
                (m.totalChb * 10000)
                / m.totalVol;
            if (r > 100) {
                m.riskTier = 3;
                m.dynRate = BASE_RATE * 3;
            } else if (r > 20) {
                m.riskTier = 2;
                m.dynRate = BASE_RATE * 2;
            } else {
                m.riskTier = 1;
                m.dynRate = BASE_RATE;
            }
        } else {
            m.dynRate = BASE_RATE;
        }
        uint256 contrib =
            (_vol * m.dynRate) / 10000;
        batches[_root] = true;
        if (contrib > 0) {
            uint256 alw =
                token.allowance(
                    msg.sender, address(this));
            require(alw >= contrib, "!alw");
            m.totalContributed += contrib;
            totalReserves += contrib;
            require(
                token.transferFrom(
                    msg.sender,
                    address(this),
                    contrib
                ),
                "!tf"
            );
        }
        emit BatchProc(_mid, _root, contrib);
    }

    function claim(
        bytes32 _mid,
        uint256 _amt,
        address _rec
    ) external onlyNode whenNotFrozen {
        require(_amt <= MAX_CLAIM, "!cap");
        require(_rec != address(0), "!rec");
        if (block.timestamp
            >= lastReset + 30 days) {
            monthlyClaims = 0;
            lastReset = block.timestamp;
        }
        MerchantProfile storage m =
            merchants[_mid];
        uint256 lim = m.totalContributed * 2;
        require(
            m.claimsPaid + _amt <= lim,
            "!lim"
        );
        uint256 stop =
            (totalReserves * STOP_LOSS) / 100;
        if (monthlyClaims + _amt > stop) {
            frozen = true;
            emit Emergency("stop-loss");
            revert("!stop");
        }
        m.claimsPaid += _amt;
        monthlyClaims += _amt;
        require(totalReserves >= _amt, "!res");
        totalReserves -= _amt;
        require(
            token.transfer(_rec, _amt),
            "!pay"
        );
        emit ClaimSettled(_mid, _amt, _rec);
    }

    function depositRebate(
        uint256 _amt
    ) external whenNotFrozen {
        require(_amt > 0, "!amt");
        totalReserves += _amt;
        require(
            token.transferFrom(
                msg.sender,
                address(this),
                _amt
            ),
            "!reb"
        );
        emit Rebate(msg.sender, _amt);
    }
}

4. Regional Resiliency and Network Topology

To guarantee zero-trust operations across jurisdictions with volatile internet backbones, the infrastructure MUST separate on-chain block execution from public-facing internet routing.

4.1. Regional Embassy Node Topology

Each participating country (India, Pakistan, Bangladesh, Vietnam, Cambodia) SHALL host an autonomous, isolated data center stack ("Embassy Node"). Each node consists of an Ethereum execution client (e.g., Geth or Nethermind), a consensus client (e.g., Lighthouse), and a secure regional API gate.

4.2. Isolated MPLS and Satellite Network Mesh

All peer-to-peer (P2P) traffic dedicated to node replication, synchronization, and local RPC query forwarding MUST be encapsulated within a private Multi-Protocol Label Switching (MPLS) VPN network mesh.

To protect against physical cable severing or local state-level network censorship, every Embassy Node MUST deploy a secondary satellite uplink (e.g., Low Earth Orbit satellite terminal). The edge router MUST automatically failover to the satellite channel within 500 milliseconds if the primary MPLS connection is dropped.

4.3. Capacity-Aware Round-Robin Load Balancing

Regional applications interact with nodes via local private RPC endpoints. Traffic load balancing across international node boundaries MUST use a Weighted Round-Robin (WRR) algorithm. The weights MUST dynamically adjust based on real-time node resource telemetry (CPU load, network throughput, and mTLS connection latency). If Node A (e.g., Bangladesh) experiences hardware saturation, traffic MUST be progressively offloaded to Node B (e.g., India) proportionate to Node B's remaining system capacity.

5. API Specifications

Embassy Nodes MUST expose a standardized, authenticated REST API for Web2 payment processing engines. All endpoints MUST require authentication via TLS client certificates (mTLS).

5.1. POST /api/v1/epoch/submit

Invoked by the APP backend at the end of each 10-minute epoch.

5.1.1. Request Format

{
  "merchant_id":
    "0x7465737400000000
     0000000000000000
     0000000000000000
     0000000000000000",
  "epoch_id": 10842,
  "batch_root":
    "0x3a4f8e...b2c1",
  "metrics": {
    "total_volume_usd":
      154250.00,
    "total_chargebacks_usd":
      420.00,
    "transaction_count": 3120
  }
}

5.1.2. Response Format

{
  "status": "QUEUED",
  "batch_root":
    "0x3a4f8e...b2c1",
  "calculated_premium_usd":
    462.75,
  "risk_tier": 2,
  "estimated_gas_eth":
    "0.0042"
}

5.2. POST /api/v1/claims/request

Invoked to pull settlement funds when a time-delayed clearing chargeback is validated.

5.2.1. Request Format

{
  "merchant_id":
    "0x7465737400000000
     0000000000000000
     0000000000000000
     0000000000000000",
  "claim_id": "99214-X",
  "amount_usd": 350.00,
  "evidence_hash":
    "0x88f2...99aa",
  "destination_wallet":
    "0x9E7D...421B"
}

5.2.2. Response Format

{
  "status": "SETTLED",
  "transaction_hash":
    "0xbc55...0112",
  "amount_paid_usd": 350.00
}

6. Security Considerations

Operating an SRO compensation pool over a public L1 blockchain requires stringent defense-in-depth measures to counter Advanced Persistent Threats (APTs) and consensus level exploits.

6.1. Validator Key Isolation and Remote Signing

Embassy Nodes hosting Ethereum validators MUST NOT store consensus signing keys (BLS12-381 keys) on the same virtual instance as the network-exposed execution or consensus clients. Validators MUST utilize a dedicated, air-gapped Remote Signer sub-network or a Hardware Security Module (HSM) implementing EIP-3044 standards. The node requests signatures via encrypted RPC, preventing key exfiltration if the public endpoint is compromised via an unpatched zero-day.

6.2. Local Slashing Protection Synchronizer

To eliminate the risk of a "slashing event" (accidental double-signing of blocks which results in the destruction of staked Ethereum), a localized anti-slashing database MUST be replicated over the MPLS VPN mesh. Before an Embassy Node signs a block proposal on behalf of the pool's validator array, it MUST query the distributed database to confirm no other node has signed a conflicting block hash at that specific blockchain slot.

6.3. Mempool Shielding and Front-Running Mitigation

Public mempools expose institutional transactions to MEV bots that execute front-running or sandwich attacks, causing slippage and artificial cost hikes. Embassy Nodes MUST route all transaction blocks through private block production relays (e.g., Flashbots MEV-Boost) rather than standard public broadcasting. This ensures that data updates and settlement allocations pass directly to trusted mining pools, remaining invisible until they are mined into an immutable block.

7. Embassy Node Validator Implementation

To ensure deterministic transaction inclusion, maximum protocol uptime, and absolute isolation from public network vulnerabilities, Embassy Nodes SHOULD implement a unified, vertically integrated validation and API routing stack.

7.1. Vertical Validator-API Integration Architecture

Traditional blockchain interactions rely on third-party RPC providers (e.g., Infura, Alchemy), which introduces latency and vector risks such as man-in-the-middle (MITM) attacks and MEV front-running. Each DeMI SRO National Embassy Node MUST operate its own execution client, consensus client, and an attached internal validator infrastructure.

graph TD
    subgraph P [Embassy Node]
        PE[Payment_Engine]
        RPC[Private_RPC]
        EE[Execution_Engine]
        CL[Consensus_Layer]
        ETH[Ethereum_L1]
    end
    PE -- mTLS --> RPC
    RPC --> EE
    EE <--> CL
    CL --> ETH
    EE --- ETH

7.2. Institutional Staking and Compliance

Operating public-facing validators within an enterprise financial contour requires strict compliance with recent institutional blockchain frameworks. Embassy Nodes SHOULD adhere to the guidelines established by major institutional Ethereum initiatives and working groups focused on corporate node validation:

7.3. Automated GAS Fee Rebate Loop

As specified in the protocol economics, all gas rewards earned by the validator (specifically the Priority Fee and block tips via MEV-Boost) for processing DeMI batches MUST be programmatically funneled back to the smart contract's treasury.

The node handler script MUST monitor on-chain events and execute a quarterly rebalancing transaction, moving accumulated validation rewards from the validator's withdrawal address back into the DeMISROCompensationPool balance, thereby lowering the net operational costs of the alternative providers to near-zero levels.

8. IANA Considerations

This document requires no registry assignments or interventions from IANA.

9. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, , <https://www.rfc-editor.org/rfc/rfc8174>.

Author's Address

Evgeny A. Shubralov
AI Cybersecurity LLC / IP Shubralov