The technical question of whether Russia will be able to build a repository of programmable smart contracts without foreign solutions can be considered closed: the core of the digital ruble is already working, and the add-on is being created over it in the same engineering logic. In my opinion, the main fork in the project lies not in the plane of import substitution, but in three areas that have so far been worked out weaker than the kernel itself, namely, in the security of the executable code, the legal significance of contracts and the economy of the participants in the process. To what extent and what is sovereign in this project, where bottlenecks are suspected in the hardware, who is responsible for the error in the template and why it is better to fix the privacy of individuals’ payments before and not after launch, we will discuss in this article.
The reason for the conversation is the mass introduction of the digital ruble scheduled for September 1, 2026 and the collection of comments on the concept of the commercial smart contract platform (PCSC), which the Bank of Russia plans to hold until September 30, 2026. The collection of comments itself takes a few weeks, but the real window is wider: in my opinion, the next year and a half – until the discussed nuances turn into regulations and the first working version of the platform, which will determine the quality of the future financial infrastructure. Therefore, you need to declare your position now, before the discussion ends.
Sovereignty: the issue is closed for software, for hardware – it remains
The digital ruble platform is built as a closed system with elements of a distributed registry under the control of the regulator. On the way from the concept to implementation, its main software stack was built by Russian specialists. According to the Bank of Russia, by June 1, 2026, 15 banks were operating on the platform, about 2,500 corporate wallets were created and 17 basic smart contracts were implemented, for which more than 37 thousand transactions took place. Thus, the question of the fundamental possibility of implementation has been removed: the kernel is already functioning.
PCSC is an add-on over this core. In terms of software, it is created according to the same scheme, without fundamental binding to foreign products. Cryptography is based on the algorithms described in GOSTs, which means that there is no dependence on foreign certification centers. For the sovereign circuit, this is an important detail.
The issue with hardware is more difficult. Servers under high load, specialized crypto modules, high-class network equipment are largely either licensed or imported through parallel imports. This increases the cost of infrastructure and lengthens the delivery time. The task of sovereign implementation of PCSC is solvable: complexity is concentrated in the quality and cost of specific components, and not in the very ability to build such a platform.
Smart contract is executable code, and it also has vulnerabilities
This is an area that I, as a cybersecurity specialist, consider underestimated in the ongoing public discussion. A smart contract for settlements is not a legal abstraction, but a working program. Any program has defects, and in the financial infrastructure, the price of a defect is measured in money and lost trust.
The international history of programmable money and tokens gives a tough lesson: the largest losses of the industry were not due to hacking, but due to errors in the logic of the contracts themselves. The code was executed as written – and sometimes it was written incorrectly. It is impossible to transfer this risk to the level of the national payment infrastructure.
Smart contract template lifecycle
The mechanism for working with smart contract templates should not be described in a framework, but at the procedure level. I want to note three most important ligaments.
- Auditing code before the template is put into circulation: mandatory independent verification of logic, not just formal registration.
- Versioning: each template must have a traceable history of changes so that in a controversial situation it is clear which version was executed.
- Managed update: a regulation according to which a vulnerability in an already working template is closed without stopping settlements without the risk of breaking the data of transactions that depend on it.
A separate layer is the distribution of responsibility in case of incorrect operation. Between the template developer, platform operator, intermediary bank and data provider (oracle), a scheme must be prescribed in advance that determines who is responsible for the error in the code, who is responsible for the false input, who is responsible for the failure in the execution process. Without this, the first controversial transaction will turn into a long and time-consuming trial.
Legal force: which is more important – document or code
The second not fully developed node is legal one. The smart contract fulfills the conditions automatically, but behind it there is a legally significant agreement between the parties. The concept does not yet clearly answer the question of what is considered the main obligation, and what is auxiliary, and how to resolve the dispute if the written contract and the logic of the code suddenly diverged.
This is not just a theoretical problem. As soon as the volume of transactions grows, discrepancies will inevitably appear, especially if the wording in the contract is interpretable, and the code executes a single scenario. It is necessary to decide in advance, where the priority is and in what order the result of automatic execution can be challenged. It is wiser to build a legal framework now, at the stage of discussion, than to complete it later with judicial precedents on the fact of losses incurred.
Privacy of settlements of individuals – a question that needs to be discussed in advance
Programmability of money is useful where transparency is needed. In budget payments and public procurement, such control is reasonable: targeted spending can be tracked at the level of the instrument itself, and not by reporting after the fact. For settlements between legal entities – delivery versus payment, escrow, multilateral transactions – it also automates the routine well and reduces costs.
With the payments of individuals, the situation is much more delicate. Here it is important to outline scenarios immediately and prescribe guarantees where the programmable properties of the digital ruble do not narrow the freedom to manage money at their discretion as simply as with ordinary cash and non-cash forms. I believe that this issue should be brought to the public plane and fixed in advance in the normative layer. Then the discussion will go around specific norms, and not around hypothetical fears – and will reduce the risk of loss of confidence in this tool from a wide range of citizens.
Fees, incentives and banking interest
The federal scale platform, in order not to experience difficulties with scaling and implementation, must cover the cost of its own content. Endlessly financing it from the emission sources of the regulator is a very unstable scheme. The cost recovery principle looks logical: a minimum commission covering operating costs and the development budget, without the task of making a profit.
The concept sets the incentives for the market correctly – template developers and data providers will be able to make money on them, typical templates will become an independent product. However, the interest of intermediary banks has been worked out weaker, this has already been indicated in the sectoral discussion. Banks bear the costs of integration and maintenance, but the source to cover their costs in the above scheme is not obvious. If the economy of all participants is not balanced, then banks will connect reluctantly or only formally – and the whole system will slow down at the last mile stage.
I would solve the issue with the operator in stages. At the stage of formation, the role of the regulator as the system operator is fully justified: the project is infrastructurally complex and requires direct control. However, in the future, it is reasonable to transfer operator functions to a separate legal entity on the model of the National Payment Card System, which was also separated from the Central Bank at one time and develops SQP and universal QR codes independently. This approach separates the roles of regulator and operator, provides the necessary operational flexibility and removes potential conflicts of interest, leaving the state with strategic control over critical infrastructure. Perhaps this is not a question of the first year of operation of the platform, but of the third or fourth year, but one way or another it will arise.
International context: Brazilian Drex experience
The experience of other jurisdictions is worth studying closely. The Brazilian Drex system, ideologically close in programmability, was originally built as a CBDC on a distributed registry using the Hyperledger Besu platform. Faced with the trilemma of simultaneously ensuring confidentiality, scalability and programmability, the project, according to an academic analysis in the World Journal of Advanced Research and Reviews (2026), moved away from the blockchain model and shifted to a centralized permitted architecture under the control of the central bank.
The Russian model is centralized initially – this removes some of the problems that Brazil faced when implementing the pilot. Nevertheless, removing the architectural trilemma does not eliminate engineering challenges: legal aspects, code security issues and the balance of economic interests of participants remain regardless of the chosen platform architecture.
What determines the success of the project
Technically, the platform is realizable by Russian specialists – this is no longer a hypothesis, but a fact. However, the real success of the project depends on three factors:
- how accurately from an engineering point of view the audit, versioning and updating of templates will be prescribed;
- how clearly the legal force and responsibility of the participants will be distributed;
- how well they balance the economy of intermediary banks and provide guarantees of privacy for individuals.
I expect a noticeable economic effect from the introduction of the repository for individual industries in 2027-2028. It will appear not in the statistics of the use of the platform itself, but in the restructuring of the operating models of companies: the transition from manual approvals and reconciliations to automatic triggers, which will accelerate the turnover of capital. The pace will depend on how substantively the controversial points of the concept will be worked out in the next year and a half. Therefore, it makes sense for banks and large corporate players not to wait for the launch, but to participate in the discussion now – with their own scenarios, requirements for the security of templates and questions regarding responsibility. When these points are fixed in the standards, it will be more difficult and more expensive to change them.
By Dmitry Livshin, CEO of Cyber Business Consulting