Technical architecture of the RUBT protocol and Managed Wallet technology
Preamble
RUBT circulates globally as a standard ERC-20 token. Settlement of the Monetary Claim of 1 RUB per 1 RUBT is possible on selected Execution Platforms via a request to the Settlement Agent. The key technical task is to connect free on-chain circulation with a controlled settlement perimeter so that operations transferring Claim rights remain synchronized with the partner Execution Platform register/accounting and cannot diverge.
The solution is a two-layer architecture “public blockchain + Execution Platforms” and Managed Wallet technology developed by Tetris as an integration layer for connecting a wide range of partner Execution Platforms.
4.1. Two-layer model: public blockchains + Execution Platforms
The RUBT architecture links two logically separated layers.
Global crypto layer (Ethereum and compatible networks) RUBT is an ERC-20-compatible token freely circulating in crypto markets and compatible with DeFi protocols (DEX, lending, derivatives, etc.). RUBT can be held on ordinary EOA addresses and on EIP-4337 smart accounts (Managed Wallets).
Regulated layer (Execution Platforms) An Execution Platform is partner infrastructure legally entitled to work with Digital Rights with fiat-RUB settlements and provides (i) admission of the Digital Right, (ii) a legally significant register/accounting, and (iii) submission and execution of requests, including buyback 1 RUBT = 1 RUB through the Agent acting in the Issuer’s name and at the Issuer’s expense.
When RUBT is placed within the perimeter of a specific Execution Platform, a Monetary Claim against the Issuer of 1 RUB per 1 RUBT arises, settleable exclusively in rubles and exclusively via a request to the Settlement Agent on that Execution Platform.
Managed Wallet as the technical gateway A Managed Wallet cryptographically links the on-chain RUBT balance and the Execution Platform record, enforcing the Mirror Invariants for operations affecting the Monetary Claim.
4.2. RUBT smart contract
The RUBT contract is implemented as an ERC-20-compatible token with an extended role model and standard functions for infrastructure compatibility.
Base functions and extensions
standard ERC-20 operations: transfer, transferFrom, approve;
support for EIP-2612 (Permit) and EIP-3009 (off-chain authorizations) for secure off-chain authorization flows.
Governance roles
Owner — top-level token contract administrator controlled at the DAO layer;
Master Minter — appoints/removes minters and sets mint limits;
Minter — performs minting and burning within established limits;
Pauser — pauses transfers in emergencies under the security policy.
Compliance boundary The RUBT contract does not include on-chain address blocking (blacklist). Compliance and checks are implemented on the Execution Platform side via appropriate procedures, not via censorship inside the token contract.
4.3. Managed Wallets as an integration technology for partner Execution Platforms
Managed Wallets are the integration layer developed by Tetris to connect partner Execution Platforms to the RUBT protocol without violating the Mirror Invariants “on-chain ↔ Execution Platform register/accounting.”
Technical form: EIP-4337 (Account Abstraction) A user’s Managed Wallet is an Ethereum smart account operating via EIP-4337 and infrastructure contracts (including a WhitelistRelayer contract). Tetris provides the technical implementation and contractual wrapper for integration; the specific Execution Platform embeds it into its own perimeter of checks and request execution under its rules and applicable law.
Required properties
Key generation and a unified identity of actions: the Execution Platform provides a way to generate keys used to sign the Managed Wallet in Ethereum.
Dual signature and whitelisting of operations: any action with RUBT affecting the amount/status of the Monetary Claim inside the Execution Platform perimeter requires:
the user’s signature; and
the Execution Platform’s technical signature (authorization). WhitelistRelayer verifies that the operation matches a specific request/event on the Execution Platform and rejects unverified transactions.
Mirror Invariants (“Execution Platform accounting ↔ on-chain”): the smart account and relayer block operations that cause desynchronization; transactions not confirmed by the Execution Platform are not executed. This technically excludes scenarios where:
the Execution Platform record shows RUBT without an equal on-chain balance on the Managed Wallet; or
an on-chain operation happens without a corresponding operation in the Execution Platform perimeter.
4.4. Interaction with Execution Platforms: deposit, withdrawal, and operations with RUBT
Execution Platforms implement RUBT operations via standard user flows under the following requirements.
Deposit (placing) RUBT on an Execution Platform A User places RUBT on an Execution Platform under platform rules based on a user request. This triggers an AA operation from the Managed Wallet and creates a synchronized record in the Execution Platform perimeter under its admission rules, KYC/AML, and Digital Right accounting procedure.
Withdrawal of RUBT from the Execution Platform perimeter A User withdraws RUBT under Execution Platform rules based on a request. After that, the Managed Wallet unlocks RUBT for free on-chain circulation.
Operations inside the Execution Platform (trading/transfers within the perimeter) Trades between users and/or the Settlement Agent are reflected both in Execution Platform accounting and on Ethereum on Managed Wallets. The Monetary Claim follows the RUBT token within the perimeter of the chosen Execution Platform and is realized via a request to the Agent under the buyback procedure.
4.5. DAO layer and protocol security
Protocol governance and critical changes are implemented through infrastructure smart contracts and DAO control procedures.
Governance and security components
RUBT and governance infrastructure smart contracts (including WhitelistRelayer, UserWallet, Beacon, EntryPoint);
DAO multisig, timelock, and CRC (Compliance & Risk Committee) controlling critical changes and emergency functions;
voting by veTETRIS holders on upgrades, limits, and architectural parameters.
The purpose is protocol resilience and risk manageability while maintaining the core legal invariants of RUBT and the settlement model via the Settlement Agent and partner Execution Platforms.
Last updated