Blockchain-Backed Risk Pooling and Self-Regulation Protocol for Alternative Payment Providers (DeMI)
draft-shubralov-demi-sro-payment-security-00

Network Working Group                                    E. A. Shubralov
Internet-Draft                       AI Cybersecurity LLC / IP Shubralov
Intended status: Informational                              28 July 2026
Expires: 29 January 2027

    Blockchain-Backed Risk Pooling and Self-Regulation Protocol for
                  Alternative Payment Providers (DeMI)
              draft-shubralov-demi-sro-payment-security-00

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.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Shubralov                Expires 29 January 2027                [Page 1]
Internet-Draft          DeMI SRO Payment Security              July 2026

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Protocol Mechanics and Smart Contract Architecture  . . . . .   4
     3.1.  Transaction Batching Pipeline . . . . . . . . . . . . . .   4
     3.2.  Dynamic Algorithmic Underwriting  . . . . . . . . . . . .   4
     3.3.  Core Solidity Implementation Reference  . . . . . . . . .   5
   4.  Regional Resiliency and Network Topology  . . . . . . . . . .   9
     4.1.  Regional Embassy Node Topology  . . . . . . . . . . . . .   9
     4.2.  Isolated MPLS and Satellite Network Mesh  . . . . . . . .   9
     4.3.  Capacity-Aware Round-Robin Load Balancing . . . . . . . .  10
   5.  API Specifications  . . . . . . . . . . . . . . . . . . . . .  10
     5.1.  POST /api/v1/epoch/submit . . . . . . . . . . . . . . . .  10
       5.1.1.  Request Format  . . . . . . . . . . . . . . . . . . .  10
       5.1.2.  Response Format . . . . . . . . . . . . . . . . . . .  10
     5.2.  POST /api/v1/claims/request . . . . . . . . . . . . . . .  10
       5.2.1.  Request Format  . . . . . . . . . . . . . . . . . . .  11
       5.2.2.  Response Format . . . . . . . . . . . . . . . . . . .  11
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
     6.1.  Validator Key Isolation and Remote Signing  . . . . . . .  11
     6.2.  Local Slashing Protection Synchronizer  . . . . . . . . .  11
     6.3.  Mempool Shielding and Front-Running Mitigation  . . . . .  12
   7.  Embassy Node Validator Implementation and Institutional
           Guidelines  . . . . . . . . . . . . . . . . . . . . . . .  12
     7.1.  Vertical Validator-API Integration Architecture . . . . .  12
     7.2.  Institutional Staking and Compliance Standards  . . . . .  13
     7.3.  Automated GAS Fee Rebate Loop . . . . . . . . . . . . . .  14
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .  14
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  14

Shubralov                Expires 29 January 2027                [Page 2]
Internet-Draft          DeMI SRO Payment Security              July 2026

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.

      *Alternative Payment Provider (APP):* A non-bank financial
      intermediary aggregating local payment methods.

      *DeMI SRO:* Decentralized Mutual Insurance Self-Regulated
      Organization.

Shubralov                Expires 29 January 2027                [Page 3]
Internet-Draft          DeMI SRO Payment Security              July 2026

      *Embassy Node:* A regional server infrastructure combining an
      Ethereum L1 full node, validator client, and private RPC gateway.

      *Epoch Batch:* A packed cryptographic structure containing a fixed
      interval of localized transaction states.

      *Base Fee and Priority Fee:* Ethereum gas mechanics as defined in
      EIP-1559.

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.

Shubralov                Expires 29 January 2027                [Page 4]
Internet-Draft          DeMI SRO Payment Security              July 2026

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 totalVolume;
           uint256 totalChargebacks;
           uint256 activeRiskTier;
           uint256 dynamicRate;
           uint256 totalContributed;
           uint256 claimsPaidThisYear;
       }

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

       uint256 public constant BASE_RATE = 30;
       uint256 public constant MAX_CLAIM_LIMIT = 500 * 10**6;
       uint256 public constant SYSTEM_STOP_LOSS_PCT = 40;

       IERC20 public immutable settlementToken;
       uint256 public totalPoolReserves;
       uint256 public monthlyClaimsPaid;
       uint256 public lastResetTimestamp;

Shubralov                Expires 29 January 2027                [Page 5]
Internet-Draft          DeMI SRO Payment Security              July 2026

       bool public isSystemFrozen;

       address[] public sroGovernors;
       mapping(address => bool) public isGovernor;
       uint256 public immutable requiredConsensusThreshold;

       mapping(address => bool) public authorizedEmbassies;
       mapping(bytes32 => MerchantProfile) public merchants;
       mapping(bytes32 => bool) public processedBatches;

       mapping(uint256 => EmergencyProposal) public emergencyProposals;
       uint256 public proposalCounter;

       event EmbassyAuthorized(address indexed embassy, bool status);
       event BatchProcessed(bytes32 indexed merchantId, bytes32 indexed batchRoot, uint256 contribution);
       event ClaimSettled(bytes32 indexed merchantId, uint256 amount, address indexed recipient);
       event ValidatorRebateReceived(address indexed validator, uint256 amount);
       event SystemEmergencyTriggered(string reason);
       event SystemConsensusResumed(uint256 indexed proposalId, uint256 totalVotes);
       event ProposalInitiated(uint256 indexed proposalId, bytes32 indexed merchantId);

       modifier onlyGovernor() {
           require(isGovernor[msg.sender], "Auth: Caller is not an authorized SRO Governor");
           _;
       }

       modifier onlyAuthorizedNode() {
           require(authorizedEmbassies[msg.sender] || isGovernor[msg.sender], "Auth: Node unauthorized");
           _;
       }

       modifier whenNotFrozen() {
           require(!isSystemFrozen, "Emergency: Pool is frozen due to Stop-Loss breach");
           _;
       }

       constructor(address _settlementToken, address[] memory _initialGovernors, uint256 _threshold) {
           require(_settlementToken != address(0), "Config: Invalid token address");
           require(_initialGovernors.length >= _threshold, "Config: Threshold exceeds governors count");
           require(_threshold > 0, "Config: Invalid threshold");
           settlementToken = IERC20(_settlementToken);
           requiredConsensusThreshold = _threshold;
           lastResetTimestamp = block.timestamp;
           for (uint256 i = 0; i < _initialGovernors.length; i++)
           {
             address gov = _initialGovernors[i];
             require(gov != address(0), "Config: Invalid governor address");
             require(!isGovernor[gov], "Config: Duplicate governor");

Shubralov                Expires 29 January 2027                [Page 6]
Internet-Draft          DeMI SRO Payment Security              July 2026

             isGovernor[gov] = true;
             sroGovernors.push(gov);
           }
       }

       function setEmbassyAuthorization(address _embassy, bool _status) external onlyGovernor {
           require(_embassy != address(0), "Config: Invalid embassy address");
           authorizedEmbassies[_embassy] = _status;
           emit EmbassyAuthorized(_embassy, _status);
       }

       function initiateConsensusRescue(bytes32 _targetMerchantId) external onlyAuthorizedNode returns (uint256)
       {
           require(isSystemFrozen, "Recovery: System is running in normal mode");
           proposalCounter++;
           EmergencyProposal storage p = emergencyProposals[proposalCounter];
           p.targetMerchantId = _targetMerchantId;
           p.voteCount = 1;
           p.timestamp = block.timestamp;
           p.hasVoted[msg.sender] = true;
           emit ProposalInitiated(proposalCounter, _targetMerchantId);
           return proposalCounter;
       }

       function voteForConsensusRescue(uint256 _proposalId) external onlyAuthorizedNode {
           require(isSystemFrozen, "Recovery: System is not frozen");
           EmergencyProposal storage p = emergencyProposals[_proposalId];
           require(!p.executed, "Recovery: Proposal already executed");
           require(!p.hasVoted[msg.sender], "Recovery: Duplicate vote from this node");
           require(block.timestamp <= p.timestamp + 7 days, "Recovery: Proposal expired");
           p.hasVoted[msg.sender] = true;
           p.voteCount++;
           if (p.voteCount >= requiredConsensusThreshold)
           {
             p.executed = true;
             isSystemFrozen = false;
             monthlyClaimsPaid = 0;
             lastResetTimestamp = block.timestamp;
             emit SystemConsensusResumed(_proposalId, p.voteCount);
           }
       }

       function processEpochBatch(bytes32 _merchantId,bytes32 _batchRoot,uint256 _epochVolume,uint256 _epochChargebacks) external onlyAuthorizedNode whenNotFrozen
       {
           require(!processedBatches[_batchRoot], "Pool: Batch Merkle Root already processed");
           require(_merchantId != bytes32(0), "Pool: Invalid merchant ID");
           MerchantProfile storage merchant = merchants[_merchantId];
           merchant.totalVolume += _epochVolume;

Shubralov                Expires 29 January 2027                [Page 7]
Internet-Draft          DeMI SRO Payment Security              July 2026

           merchant.totalChargebacks += _epochChargebacks;
           if (merchant.totalVolume > 0)
           {
             uint256 fraudRatio = (merchant.totalChargebacks * 10000) / merchant.totalVolume;
             if (fraudRatio > 100)
             {
               merchant.activeRiskTier = 3;
               merchant.dynamicRate = BASE_RATE * 3;
             } else if (fraudRatio > 20)
             {
               merchant.activeRiskTier = 2;
               merchant.dynamicRate = BASE_RATE * 2;
             } else
             {
               merchant.activeRiskTier = 1;
               merchant.dynamicRate = BASE_RATE;
             }
           } else
           {
             merchant.dynamicRate = BASE_RATE;
           }
           uint256 contributionAmount = (_epochVolume * merchant.dynamicRate) / 10000;
           processedBatches[_batchRoot] = true;
           if (contributionAmount > 0)
           {
             uint256 currentAllowance = settlementToken.allowance(msg.sender, address(this));
             require(currentAllowance >= contributionAmount, "Pool: Insufficient ERC20 allowance");
             merchant.totalContributed += contributionAmount;
             totalPoolReserves += contributionAmount;
             require(settlementToken.transferFrom(msg.sender, address(this), contributionAmount), "Pool: Transfer failed");
           }
           emit BatchProcessed(_merchantId, _batchRoot, contributionAmount);
         }

         function claimCompensation(bytes32 _merchantId,uint256 _claimAmount,address _recipient) external onlyAuthorizedNode whenNotFrozen
         {
           require(_claimAmount <= MAX_CLAIM_LIMIT, "RiskCap: Exceeds Maximum Claim Limit ($500)");
           require(_recipient != address(0), "Pool: Invalid recipient wallet");
           if (block.timestamp >= lastResetTimestamp + 30 days)
           {
             monthlyClaimsPaid = 0;
             lastResetTimestamp = block.timestamp;
           }
           MerchantProfile storage merchant = merchants[_merchantId];
           uint256 merchantYearlyLimit = merchant.totalContributed * 2;
           require(merchant.claimsPaidThisYear + _claimAmount <= merchantYearlyLimit, "RiskCap: Exceeds annual aggregate limit");
           uint256 dynamicStopLossTrigger = (totalPoolReserves * SYSTEM_STOP_LOSS_PCT) / 100;
           if (monthlyClaimsPaid + _claimAmount > dynamicStopLossTrigger)

Shubralov                Expires 29 January 2027                [Page 8]
Internet-Draft          DeMI SRO Payment Security              July 2026

           {
             isSystemFrozen = true;
             emit SystemEmergencyTriggered("System Stop-Loss breached. Structural fraud attack suspected.");
             revert("Emergency: System stop-loss activated. Payout blocked.");
           }
           merchant.claimsPaidThisYear += _claimAmount;
           monthlyClaimsPaid += _claimAmount;
           require(totalPoolReserves >= _claimAmount, "Pool: Insufficient reserves");
           totalPoolReserves -= _claimAmount;
           require(settlementToken.transfer(_recipient, _claimAmount), "Pool: Payout failed");
           emit ClaimSettled(_merchantId, _claimAmount, _recipient);
         }

         function depositValidatorRebate(uint256 _amount) external whenNotFrozen
         {
           require(_amount > 0, "Pool: Rebate must be > 0");
           totalPoolReserves += _amount;
           require(settlementToken.transferFrom(msg.sender, address(this), _amount), "Pool: Rebate transfer failed");
           emit ValidatorRebateReceived(msg.sender, _amount);
         }
     }

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.

Shubralov                Expires 29 January 2027                [Page 9]
Internet-Draft          DeMI SRO Payment Security              July 2026

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": "0x7465737400000000000000000000000000000000000000000000000000000000",
     "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.

Shubralov                Expires 29 January 2027               [Page 10]
Internet-Draft          DeMI SRO Payment Security              July 2026

5.2.1.  Request Format

   {
     "merchant_id": "0x7465737400000000000000000000000000000000000000000000000000000000",
     "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.

Shubralov                Expires 29 January 2027               [Page 11]
Internet-Draft          DeMI SRO Payment Security              July 2026

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 and Institutional Guidelines

   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 Perimeter [Embassy Node Secure Perimeter]
           PE[Payment Engine] -- mTLS --> RPC[Private RPC / API Gate]
           RPC -->|Internal Interlock| EE[Execution Engine Geth/Nethermind]
           EE <--> CL[Consensus Layer Lighthouse]

           CL --> ETH[Ethereum L1 Public Network]
           EE --- ETH
       end

       style Perimeter fill:#161b22,stroke:#444c56,stroke-width:2px,color:#ffffff
       style PE fill:#21262d,stroke:#f0f6fc,stroke-width:1.5px,color:#ffffff
       style RPC fill:#1c2128,stroke:#58a6ff,stroke-width:2px,color:#58a6ff
       style EE fill:#21262d,stroke:#f0f6fc,stroke-width:1.5px,color:#ffffff
       style CL fill:#21262d,stroke:#f0f6fc,stroke-width:1.5px,color:#ffffff
       style ETH fill:#0d1117,stroke:#34d399,stroke-width:2.5px,color:#34d399

       linkStyle default stroke:#adbac7,stroke-width:2px;
       linkStyle 0 stroke:#58a6ff,stroke-width:2px;
       linkStyle 3 stroke:#34d399,stroke-width:2px;
       linkStyle 4 stroke:#161b22,stroke-width:0px,opacity:0;

Shubralov                Expires 29 January 2027               [Page 12]
Internet-Draft          DeMI SRO Payment Security              July 2026

   *  *Direct Execution Interlock:* When the Web2 API gateway receives
      an Epoch Batch via POST /api/v1/epoch/submit, it MUST sign the
      transaction using the APP's institutional hot wallet and broadcast
      it directly to the node's local Execution Engine (Geth or
      Nethermind) via an internal IPC socket, completely bypassing the
      public internet.

   *  *Validator Priority Injection:* The local Consensus Client
      (Lighthouse or Prysm) MUST be configured to prioritize blocks
      containing transactions originated from the node's own private RPC
      endpoint.  When the Embassy Node's validator is selected as the
      slot proposer on Ethereum L1, it MUST inject the queued DeMI SRO
      transactions at the top of the block execution payload, reducing
      inclusion latency to zero.

7.2.  Institutional Staking and Compliance Standards

   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:

   *  *Enterprise Ethereum Alliance (EEA) Standards:* Node operators
      MUST implement the EEA Enterprise Architecture specifications
      regarding node access control, permissioned network routing over
      MPLS, and zero-knowledge evidence auditing for local central
      banks.

   *  *Institutional Liquid Staking and Validator Frameworks:* For
      financial risk mitigation, nodes SHOULD utilize distributed
      validator technology (DVT) frameworks (such as Obol Network or SSV
      Network).  DVT allows an Embassy Node's 32 ETH validation key to
      be split into multi-signature shares distributed securely between
      the sub-nodes of India, Pakistan, and Vietnam.  This guarantees
      that if one physical data center goes offline, the remaining
      "embassies" can cooperatively sign blocks, preventing slashing
      penalties and maintaining continuous transaction ledgering.

   *  *Compliance and Sanction Filtering at the RPC Layer:* While the
      smart contract logic is immutable and extraterritorial ("Code is
      Law"), national Embassy Nodes MAY configure their private RPC
      layer to comply with local financial intelligence regulations
      (e.g., FIU-IND in India) by cross-referencing merchant wallet
      addresses against official local blocklists before broadcast.

Shubralov                Expires 29 January 2027               [Page 13]
Internet-Draft          DeMI SRO Payment Security              July 2026

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, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, May 2017,
              <https://www.rfc-editor.org/rfc/rfc8174>.

Author's Address

   Evgeny A. Shubralov
   AI Cybersecurity LLC / IP Shubralov
   Email: draft-submission@demi-sro.org
   URI:   https://demi-sro.org

Shubralov                Expires 29 January 2027               [Page 14]