Managed precompilation

Managed precompilation on institutional subnets addresses compliance challenges by enforcing regulatory requirements through precompilers, enhancing scalability and extensibility, and improving gas efficiency in blockchain networks.

JP2026515770APending Publication Date: 2026-05-19AVA LABS INC
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
AVA LABS INC
Filing Date
2024-04-11
Publication Date
2026-05-19

AI Technical Summary

Technical Problem

Institutional subnets face challenges in interacting with decentralized applications due to fluctuating KYC/AML obligations, making it difficult to comply with regulatory requirements and maintain scalability and extensibility in blockchain networks.

Method used

Implementing managed precompilation on institutional subnets, which includes generating a set of managed precompilers to enforce security regulations, verifying user authorization, and modifying precompilers based on risk scores to ensure compliance and adaptability.

Benefits of technology

This approach reduces operational burden, enhances scalability and extensibility, and improves gas efficiency by managing regulatory compliance through managed precompilation, allowing institutions to interact seamlessly with decentralized applications.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2026515770000001_ABST
    Figure 2026515770000001_ABST
Patent Text Reader

Abstract

A method and system are provided for generating asset versions containing various levels of detail. The method includes generating an institutional subnet having one or more blockchains. The method further includes enabling a set of managed precompiles for one or more blockchains and verifying whether users of the institutional subnet are authorized to interact with one or more blockchains. The method further includes generating a risk score associated with the user and, based on the risk score, modifying at least one managed precompile in the set of managed precompiles for the above blockchains based on the risk score requirements of each of the one or more blockchains.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] Cross - reference to Related Applications This disclosure is related to U.S. Patent Application No. 18 / 491,019, titled ADMINISTRATIVE PRECOMPILES, filed on October 20, 2023, to Aaron Buchwald, and U.S. Patent Application No. 63 / 495,735, titled AUTHORIZING USERS IN INSTITUTIONAL SUBNETS, filed on April 12, 2023, to Aaron Buchwald, claims priority to each of them, and the content of each of them is incorporated herein by reference in its entirety for all purposes.

[0002] This disclosure generally relates to institutional subnets included in blockchain implementations. More specifically, it uses administrative precompiles that indicate whether a given address is approved to determine whether a counterparty is authorized to perform operations within an institutional subnet.

Background Art

[0003] A blockchain is a database that maintains records of transactions and asset tracking in blocks and / or tokens. Blocks are the native assets of a blockchain, while tokens are assets created as part of a platform built on an existing blockchain. A blockchain network includes nodes, such as validator nodes, that participate in consensus. Validator nodes can verify, vote, stake, and / or maintain records of transactions on the blockchain network, as well as store copies of the blockchain. Validators are also responsible for generating and / or proposing blocks to be added to the blockchain network. Validators can participate in consensus voting protocols for implementing blockchain deployments or building on subnets. A subnet is a dynamic set of validators that work together to achieve consensus on the state of a set of blockchains. Each blockchain is validated by only one subnet. A subnet can validate many blockchains. A node can be a member of many subnets. A subnet can manage its own membership and may require its constitutive validators to meet certain requirements. Because requirements fluctuate in institutions, it is difficult for them to interact with decentralized applications. [Brief explanation of the drawing]

[0004] To provide a further understanding, the accompanying drawings, which are included and incorporated herein and constitute part of this specification, illustrate the disclosed embodiments and, together with the specification, help to illustrate the principles of the disclosed embodiments.

[0005] [Figure 1] A block diagram of a device operating environment capable of implementing the embodiments of this disclosure. [Figure 2] This document illustrates a system for implementing managed pre-compilation on institutional subnets using one or more implementation methods. [Figure 3]An illustrative flowchart illustrating blocks in one or more implementations for implementing managed precompilation on an institutional subnet. [Figure 4] An illustrative flowchart illustrating the process for enabling managed precompilation within a blockchain using one or more implementations. [Figure 5] A block diagram illustrating an exemplary computer system capable of implementing aspects of the subject technology.

[0006] In one or more implementations, not all components depicted in each figure are necessarily required, and one or more implementations may include additional components not shown in the figures. Variations may be made in the arrangement and type of components without departing from the scope of this disclosure. Additional components, different components, or fewer components may be used within the scope of the disclosure. [Overview of the project]

[0007] This disclosure provides a system and method for implementing managed precompilers in an institutional subnet. In one aspect of this disclosure, the method includes generating an institutional subnet having one or more blockchains; enabling a set of managed precompilers for one or more blockchains; verifying whether users of the institutional subnet are authorized to interact with one or more blockchains; generating a risk score associated with the user based on the verification; and modifying at least one managed precompiler in the set of managed precompilers for one or more blockchains based on the risk score requirements for each of the one or more blockchains, based on the risk score.

[0008] Another aspect of this disclosure relates to a system configured to implement managed precompilers on an institutional subnet. The system includes one or more processors and memory storing instructions, the instructions, when executed by one or more processors, cause the system to perform an operation. The operation includes generating an institutional subnet having one or more blockchains; enabling a set of managed precompilers for one or more blockchains, which includes parameters used to enforce security regulations in the institutional subnet; verifying whether users of the institutional subnet are authorized to interact with one or more blockchains; generating a risk score associated with the user based on the verification; and modifying at least one managed precompiler in the set of managed precompilers for one or more blockchains based on the risk score requirements for each of the one or more blockchains, based on the risk score.

[0009] A further aspect of the present disclosure relates to a non-temporary computer-readable storage medium having instructions embodied thereon, wherein the instructions are executable by one or more processors to carry out one or more of the methods according to one or more embodiments described herein. For example, a method comprising: generating an institutional subnet having one or more blockchains; enabling a set of managed precompiles for one or more blockchains, the set of managed precompiles including parameters used to enforce security regulations in the institutional subnet; verifying whether a user of the institutional subnet is authorized to interact with one or more blockchains; generating a risk score associated with the user based on the verification; and modifying, based on the risk score, at least one managed precompile in the set of managed precompiles for one or more blockchains based on the risk score requirements of each of the one or more blockchains.

[0010] These and other embodiments will be apparent from this disclosure. Other configurations of the subject art will be readily apparent to those skilled in the art from the following detailed description, and it will be understood that various configurations of the subject art are shown and illustrated by example. As realized, other different configurations of the subject art are possible, and some of its details can be modified in various other ways without departing from the scope of the subject art. Accordingly, the drawings and detailed description should be considered as illustrative and not restrictive in nature. [Modes for carrying out the invention]

[0011] The following detailed description includes many specific details in order to provide a complete understanding of the disclosure. However, it will be apparent to those skilled in the art that embodiments of the disclosure may be carried out without some of these specific details. In other examples, well-known structures and techniques are not shown in detail so as not to obscure the disclosure.

[0012] Blockchain platforms, such as smart contracts, may require a consensus protocol as a fundamental building block for constructing decentralized systems. For example, a blockchain platform may include multiple blockchains, such as a component exchange blockchain for creating and trading digital smart assets, a metadata blockchain for coordinating validators and tracking and creating subnets, and a contract blockchain for creating smart contracts. As used herein, a subnet or subnetwork has a dynamic set of validators that attempt to achieve consensus on the state of a set of blockchains, where one blockchain is validated by one subnet, but one subnet can validate multiple blockchains. Validator nodes may also be members of multiple subnets and may be subject to requirements such as security, licensing, and hardware. In a non-limiting example, a subnet may require validators to comply with customer verification / business verification / anti-money laundering (KYC / KYB / AML) obligations. The blockchains validated by validators may be blockchain networks with application-level logic defined by multiple virtual machines (VMs), enabling a more decentralized network. Specifically, a blockchain can be an instance of a VM that specifies the blockchain's state, state transitions, transactions, and application programming interfaces (APIs) for user interaction.

[0013] The VM can unpack the bytecode of a smart contract. Implementing instructions on the VM for specific actions can be costly. Precompilation saves system costs because it is designed to perform functions implemented by the VM rather than the actual contract. By non-limiting examples, precompilation may be used to perform cryptographic operations, add functions, remove functions, etc. Precompilation is associated with a fixed address defined in the VM. There is no bytecode associated with a fixed address. When precompilation is invoked (for example, by performing an invocation operation that invokes a specific address), the VM checks whether the input address is a precompiled address. Multiple addresses, including precompilation, may be hardcoded within the VM. If the invocation operation is for a precompiled address, the VM performs precompilation and performs some actions. Otherwise (i.e., if the invocation operation is not for a precompiled address), the smart contract is loaded into the input address and executed on the VM interpreter with the specified input data. Precompilation can be restricted in several ways. For example, pre-compilation does not authorize state access to VMs, making it difficult for users to build their own pre-compilations, add new functionality to the system, and / or update subnet configurations from their initially defined state.

[0014] The disclosure of this subject overcomes the shortcomings described above by providing a system and method for performing operations within a VM using managed precompiled data from an institutional subnet. According to the embodiment, a set of managed precompiled data may be provided to the platform layer of the blockchain (i.e., the platform chain (P chain)) to perform various operations and / or implement functions. The managed precompiled data enables a network operator (e.g., a management controller) to direct how users interact with the VM.

[0015] According to the embodiment, managed precompilation includes state access and can therefore be used to modify aspects of the blockchain's state machine by issuing transactions to the network. Thus, the blockchain does not need to coordinate network upgrades based on counterparties or fluctuating KYC / AML obligations. Aspects of the blockchain's state machine can be modified via designated managed addresses that may be controlled by externally owned accounts (EOAs), multi-party computation (MPC) blockchain wallets, smart contract wallets, decentralized autonomous organizations (DAOs), or other governance smart contracts. Changes to the state machine itself can be used to modify network parameters. As a non-limiting example, network parameters may include, but are not limited to, addresses enabled to submit transactions to the network, addresses enabled to deploy contracts to the network, addresses enabled to mint the network's native tokens, network fee parameterization, protocol parameters specifying gas fees, and other network parameters. This can be used to significantly reduce the operational burden on the network and to add new functionality at the protocol level (such as transaction allowlists and contract deployer allowlists).

[0016] According to one embodiment, managed precompilation allows writing to the VM beyond simply performing operations. For example, managed precompilation may be configured to store functions (or data) in a permanent state on the VM. In this way, the stored functions can be continuously invoked, for example, to add new functions, and built upon themselves or other existing functions of the VM.

[0017] According to the embodiment, administrative precompilation may be used to generate subnets in which only specific addresses are permitted to interact with the blockchain. Subnets may be generated by submitting transactions or deploying contracts based on contracts that are updated to register KYC addresses and update corresponding risk scores to determine which counterparties should be allowed to interact with the blockchain. This significantly reduces the operational burden on administrators and allows for improved adaptability to the operational capabilities of the blockchain. The embodiment may be implemented to provide KYC / AML credentials for cryptographic abstractions that protect the identity of transaction originators. For example, commitments to a set of addresses may be authenticated by a KYC provider instead of individual addresses, which allows for greater flexibility for users in how assets can be moved (e.g., across chains of the blockchain network).

[0018] The disclosed system addresses traditional blockchain problems tied to computer technology, namely the technical problem of bringing scalability and extensibility to the blockchain. The disclosed system solves this technical problem by providing a solution that is also rooted in computer technology, namely by providing managed pre-compilation that enables management control over the blockchain infrastructure and the buildable functions within the blockchain. The disclosed system also improves the capabilities of the computer itself in order to reduce the cost of system resources and improve data processing.

[0019] Groups / institutions have fluctuating KYC / KYB / AML obligations (hereinafter also simply referred to as "obligations"). Therefore, they find it difficult to interact with decentralized applications (such as, but not limited to, decentralized finance (DeFi) primitives). Thus, there is a need to enable institutional access to decentralized networks and blockchain applications. DeFi primitives allow individuals to conduct financial transactions without direct counterparties. For example, when placing an order on a decentralized exchange, a user trades with a decentralized and anonymous user pool that has provided liquidity to the pool. This presents a challenge for institutions that need to comply with KYC / AML obligations involving different counterparties. Since numerous anonymous counterparties can exist, and this does not enable them to fulfill their KYC / AML obligations, it would be advantageous and a technical improvement for blockchain platforms to include third-party applications, such as one providing non-transferable tokens (NTT) from an NTT provider, which would verify the KYC / AML status of a given address associated with the counterparty. Next, each application needs to query NTT to determine whether the address should be allowed to interact with the application. This beneficially reduces the load on validators and makes the blockchain platform more gas-efficient by placing the burden of querying a third-party NTT on the application developers before allowing interaction.

[0020] The disclosed system addresses traditional blockchain problems linked to computer technology, namely the technical issues of institutional compliance in blockchain technology. The disclosed system solves this technical problem by providing a solution that is also rooted in computer technology, namely by providing a system, method, and machine-readable medium for enforcing regulatory compliance to interactions through the use of a management precompiler that includes parameters such as management. The disclosed system also improves the capabilities of the computer itself in order to reduce the cost of system resources and improve data processing.

[0021] As used herein, the term “blockchain” generally refers to an open, distributed, public ledger containing a growing list of records linked using cryptography. By design, blockchains are resistant to data alteration. A blockchain may include an auditable database providing a distributed, replicated ledger of cryptographically authenticated artifacts, the contents of which are extremely difficult to tamper with without detection and therefore highly likely to be true copies of the intended content, and whose contents are open for inspection via a suitable query interface.

[0022] As used herein, the term “block” generally refers to a record held within a blockchain. For example, each block contains the cryptographic hash of the previous block, a timestamp, and transaction data that can generally be represented as a Merkle tree root hash.

[0023] As used herein, the term "token" can be created as part of a platform built on an existing blockchain. Tokens on a blockchain can be transferred between chains within a blockchain network. An address can be generated for each transaction when sending (or receiving) a transaction over the network (e.g., within a blockchain wallet). NTT is a non - transferable token that functions as an identity symbol in a decentralized network. Thus, while tokens (e.g., non - fungible tokens (NFTs)) can be transferred, NTTs cannot be transferred. NTT can be associated with a blockchain or a blockchain network.

[0024] As used herein, the term "subnet" or "subnetwork" generally refers to a dynamic set of validators that collaborate to achieve consensus on the state of a set of blockchains. For example, each blockchain is verified by exactly one subnet. A subnet can optionally verify any number of blockchains. Validator nodes can optionally be members of any number of subnets. A subnet can manage its own membership and may require that its constituent validators have certain properties.

[0025] As used herein, the term "primary network" generally refers to a special subnet that verifies an embedded blockchain. Members of a subnet can be members of the primary network. In some embodiments, a subject that is a member of the primary network stakes (e.g., acquires or "buys") one or more tokens from the primary network. As a result, blockchain validators can verify the embedded blockchain on the primary network and can have staked primary network tokens.

[0026] Exemplary system architecture Figure 1 is a block diagram of a device operating environment that can implement aspects of the present disclosure. Figure 1 illustrates an exemplary network architecture 100 for providing a blockchain platform (e.g., a blockchain network implementation / deployment platform) for managing proposed blocks to be added to a blockchain, according to several embodiments. A blockchain can be a linear chain of blocks of the same dimensions, e.g., the same height, size, length, etc. Blocks in a blockchain may contain or store data or organized information (e.g., a record of information), e.g., a cryptographic hash, timestamp, and transaction data of a previous block. The network architecture 100 of Figure 1 includes one or more participants 110 and one or more participants 130, which are communicably connected via a network 150. The blockchain architecture of network architecture 100 can be a distributed database that maintains a continuously growing list of records ordered as blocks. The blockchain architecture can implement methods and systems according to one or more embodiments. It will be understood that participants 130 may also include participants 110, as participants 110 are peers.

[0027] For example, participants 110 / 130 may be clients of a blockchain platform for creating, expanding, or otherwise modifying customized blockchain networks and / or private or public subnets. For example, participant 110 may be a different computer linked by network 150 within the blockchain network having the same database. For example, participant 110 may function as a validator or proposer for proposing or adding blocks to an existing blockchain. For example, participant 110 may be a virtual machine (VM) forming a node in blockchain network architecture 100. As a node, participant 110 can run software to validate block and transaction data for an existing blockchain, store data, verify its validity, and respond to network requests for data. The VM may be a computer running on the blockchain that allows smart contracts from multiple sources to interact with each other. Participant 110 may generate blocks at a request by participant 130, for example, via participant 130's consensus engine or module, at a specific time, such as during a specific time submission window. Blocks that are generated and proposed for addition to an existing blockchain may be validated to ensure they are valid blocks before being added.

[0028] Network 150 may include wired networks (e.g., via optical fiber or copper wire, telephone lines, etc.) or wireless networks (e.g., cellular networks, radio frequency (RF) networks, Wi-Fi, Bluetooth, etc.). Participant 110 may be any one of the following: mobile devices, laptops, desktops, tablet (e.g., palm or pad) devices, televisions, display devices, etc. Participant 110 may be controlled by the user as a set of validator nodes for making tandem decisions, such as to facilitate the operation or design of the blockchain implementation of the blockchain platform.

[0029] As discussed herein, blockchain network architecture 100 can incorporate the application of a consensus protocol that is high-throughput, fully ordered, and valid for smart contracts. A smart contract may refer to a self-executing computer program, application, or contract for executing transactions, such as financial transactions involving cryptocurrencies. Blockchain network architecture 100 can be used for creating custom blockchains (including private blockchains) and decentralized applications (dApps). The consensus protocol may be for agreement on the validity of user transactions, adding blocks to existing blockchains, and interacting with external resources (e.g., off-chain). The consensus protocol implemented by blockchain network architecture 100 may be a decentralized, leaderless block proposal mechanism that processes multiple valid block proposals in parallel and restricts the submission of proposals to existing blockchains. As an example, blockchain network architecture 100 may use iterative subsample voting, where validators can provide strong probabilistic guarantees of correctness (e.g., security and validity) without communicating with other validators.

[0030] Furthermore, the blockchain network architecture 100 can improve block proposals by reducing the processing load / cost associated with processing multiple block proposals in parallel and selecting one proposal from multiple parallel proposals. Multiple participants 110 may have access to the blockchain platform hosted by participant 130 via online or offline connections such as wireless, wired, ad-hoc, mobile, or satellite connections. Each participant 130 may be a computing device such as one or more desktop computers or part of a cloud computing server, including a panel mounted on a rack. The panel may include a processing board, and also a switchboard, router, and other network devices. The blockchain network architecture 100 enables participants 110 / 130 to seamlessly transfer assets between chains.

[0031] Participant 130 may store data from existing blockchains in a peer-to-peer (P2P) and / or distributed ledger format. In particular, Participant 130 may function in conjunction to autonomously manage a decentralized database of existing blockchains via a P2P network and Participant 130's distributed timestamp server. Participant 130 may be configured to implement multiple chains of the blockchain network architecture 100. For example, Participant 130 may implement multiple chains of the blockchain network architecture 100, such as an asset blockchain (e.g., for creating new assets, asset exchange, and cross-subnet transfers), a metadata blockchain (e.g., for validator coordination, tracking active subnets, and creating new subnets), and a smart contract blockchain (e.g., for creating smart contracts and applications that require full ordering). The multiple chains can be validated by the primary network of the blockchain network architecture 100, which includes all existing subnets.

[0032] Blockchain Network Architecture 100 can have the following three embedded blockchain layers: the exchange chain (X-chain), the platform chain (P-chain), and the contract chain (C-chain). All three blockchain layers can be verified and protected by the primary network of Blockchain Network Architecture 100.

[0033] The servers of participant 110 and one or more participants 130 in the computing network may access each other and other devices within the network 150 via corresponding communication modules. Each communication module may include radio hardware and software such as RF antennas, analog circuits, digital-to-analog converters, and digital signal processing circuits. Generally, participants 110 and 130 have computing devices that include at least a memory for storing instructions and a processor configured to execute instructions for at least partially performing one or more steps described in the methods disclosed herein. For example, the memory 220a of participant 110 may be used to perform functions associated with a blockchain platform hosted by participant 130. The processor may be used to operate participant 110, such as executing applications and their functions rendered on participant 110. The techniques described herein may be implemented as a method implemented by a physical computing device, as one or more non-temporary computer-readable storage media that store instructions causing the method to be implemented when executed by the computing device, or as a physical computing device specifically configured with a combination of hardware and software causing the method to be implemented.

[0034] Figure 2 illustrates a system 200 configured to implement managed precompilation on an institutional subnet, in one or more implementation forms. In some implementation forms, system 200 may include one or more computing platforms 202. Computing platform 202 can be configured to communicate with one or more remote platforms 204 according to a client / server architecture, a peer-to-peer architecture, and / or other architecture. Remote platform 204 can be configured to communicate with other remote platforms via computing platform 202 and / or according to a client / server architecture, a peer-to-peer architecture, and / or other architecture. Users may access system 200 via remote platform 204.

[0035] The computing platform 202 may consist of machine-readable instructions 206. The machine-readable instructions 206 include one or more instruction modules 208. An instruction module may include a computer program module. An instruction module may include one or more of the following: a generation module 208, a first pre-compilation module 210, a second pre-compilation module 212, a third pre-compilation module 214, a fourth pre-compilation module 216, a fifth pre-compilation module 218, and / or a verification module 220.

[0036] According to one embodiment, an administrator (also referred to as the "admin controller") can perform operations within the VM using administrative precompilation or "admin precompilation." Admin precompilation is used to inject new functions or otherwise modify the VM. Admin precompilation provides plug-and-play functionality to the administrative controller through user interaction within the VM. According to one embodiment, administrative precompilation is provided to user space (e.g., a user portal) by the system 200.

[0037] The generation module 208 can be configured to generate a platform blockchain. The generation module 208 can also be configured to launch at least one institutional subnet, partially based on the platform blockchain. For example, a subnet may contain one or more blockchains (N blockchains) having VMs. The VMs may contain a set of managed precompiles enabled therein, which can be used to modify different aspects of the VM and gain access to various individual functions. In aspects of the embodiment, managed precompiles include, but are not limited to, transaction permission precompiles, contract deployer precompiles, native minter precompiles, fee configuration precompiles, and reward manager precompiles.

[0038] In some embodiments, the set of managed precompiles may be updated, for example, via a network upgrade after the subnet has already been created. The upgrade may be implemented at a specified block timestamp. In some implementations, the system may activate new managed precompiles based on the initial configuration. For example, after the subnet has been started, the transaction level may not be enabled at a first timestamp. Therefore, new precompiles may be activated after the first timestamp, based on the start state.

[0039] Each managed precompile within a set of managed precompiles includes a list of addresses. The addresses in the list may include, but are not limited to, contract addresses, externally owned account (EOA) addresses controlled by public / private key pairs, etc. The list of addresses may include managed operators, managed users, and / or approved addresses. Each managed operator may correspond to one or more addresses in the list of addresses. In some implementations, the blockchain can only be modified by managed operators. The system may have write access to the list of addresses while a managed precompile is running. Therefore, a managed operator can modify the list of addresses at any time (e.g., by adding an address to the list of approved addresses). The list of addresses can also be read at any point in the platform blockchain's codebase. In some implementations, an approved address in the list of addresses can perform a call operation to a managed precompile, which may perform an action based on the managed precompile or implement a function (e.g., issue a transaction, deploy a contract, etc.) and add a new address to the list of approved addresses. Similarly, an approved address in the list of addresses can perform a call operation to remove an existing address from the list of addresses. Each managed precompile can be associated with a unique list of addresses. In some implementations, one or more addresses in the one or more address lists associated with each managed precompile are the same.

[0040] The first pre-compilation module 210 may enable transaction-permitted pre-compilation, which maintains a list of addresses that are permitted to modify the blockchain configuration. When enabled, transaction-permitted pre-compilation permits transactions in the blockchain based on the list of addresses. For example, an address on the list of addresses may submit a transaction to the blockchain.

[0041] The second pre-compile module 212 may enable the operation of the contract deployer pre-compiler, which maintains a list of addresses that are permitted to deploy the contract on the blockchain. When enabled, the contract deployer pre-compiler enables contract deployment on the blockchain based on the list of addresses.

[0042] The third pre-compilation module 214 may enable native minter pre-compilation behavior, which maintains a list of addresses that are permitted to mint any amount of a subnet's native token. Native minter pre-compilation provides users with a simple way to mint new funds, for example, when the system has consumed all its funds. Native minter pre-compilation also enables fund creation while maintaining finer-grained control over the rules and policies associated with each token and subnet setting on the blockchain.

[0043] The fourth pre-compilation module 216 may enable the operation of a pricing configuration pre-compilation, which maintains a list of addresses that allows calls to arbitrarily update the pricing configuration of a subnet. The pricing configuration pre-compilation acts as a pricing configuration manager within the VM. Pricing is generally associated with the processing of each transaction in the blockchain. Pricing may be determined based on a dynamic pricing algorithm using various parameters. Pricing configuration pre-compilation provides support for the management controller to update the pricing configuration of a subnet at any time. For example, if the initial pricing configuration falls outside of optimal time, the management controller may update the pricing configuration on the fly via pricing configuration pre-compilation. In some implementation forms, any of the management operators associated with the list of addresses may be authorized to update the pricing configuration via pricing configuration pre-compilation.

[0044] A fifth precompile module 218 may enable the operation of the reward manager precompile, which maintains a list of addresses authorized to update the award manager in the VM and update how rewards are distributed within the platform blockchain or blockchain network. Rewards are sent to a designated address, which may be set, for example, by a block producer. In some implementations, the block producer has no control over the designated address; therefore, all fees are burned or sent to an invalid address. In some implementations, rewards must be sent to a specific address that has control over all funds within the platform blockchain or blockchain network. In some implementations, rewards are sent to a smart contract configured to distribute funds across the entire platform blockchain or blockchain network. Embodiments are not limited to these implementations and may include other implementations that would be considered within the scope of those skilled in the art.

[0045] The embodiments may include multiple managed precompiled and similar precompiled modules that are implemented at the system level and enabled in a virtual machine (e.g., a Proof-of-Stake (PoS) blockchain and / or a Proof-of-Authority (PoA) blockchain).

[0046] The verification module 220 may be configured to verify an address based on one or more managed precompiles from precompile modules 210, 212, 214, 216, and / or 218. For example, the verification module 220 can determine whether a list of addresses associated with one or more of the managed precompiles is activated, and can further determine whether the requested address is authorized to perform an action within the blockchain (e.g., issuing a transaction, deploying a contract, managing reward distribution, etc.). That is, the verification module 220 determines whether the requested address is an authorized address in the list of addresses defined by the set of managed precompiles. If the requested address is an authorized address, the action is submitted. Otherwise, the action is immediately rejected and is not valid for execution within the VM.

[0047] In some implementations, the computing platform 202, the remote platform 204, and / or the external resources 226 may be operationally linked via one or more electronic communication links. For example, such electronic communication links may be established at least in part via a network such as the Internet and / or other networks. This is not intended to limit the scope of the disclosure, and it will be understood that the scope of this disclosure includes implementations in which the computing platform 202, the remote platform 204, and / or the external resources 226 may be operationally linked via some other medium of communication.

[0048] A given remote platform 204 may include one or more processors configured to run a computer program module. The computer program module may be configured to enable an expert or user associated with the given remote platform 204 to interface with system 200 and / or external resources 226, and / or to provide the remote platform 204 with other functions as provided herein. As a non-limiting example, a given remote platform 204 and / or a given computing platform 202 may include one or more of the following: a server, a desktop computer, a laptop computer, a handheld computer, a tablet computing platform, a netbook, a smartphone, a game console, and / or other computing platforms.

[0049] External resources 226 may include information sources outside of system 200, external entities participating in system 200, and / or other resources. In some implementations, some or all of the functions attributed to external resources 226 herein may be provided by resources included in system 200.

[0050] Computing platform 202 may include electronic storage 228, one or more processors 230, and / or other components. Computing platform 202 may include communication lines or ports that enable the exchange of information with a network and / or other computing platforms. The illustrative solution of computing platform 202 in Figure 2 is not intended to limit it. Computing platform 202 may include multiple hardware, software, and / or firmware components that work together to provide the functions attributed to computing platform 202 herein. For example, computing platform 202 may be implemented by a cloud of computing platforms working together as computing platform 202.

[0051] The electronic storage 228 may include non-temporary storage media for electronically storing information. The electronic storage media of the electronic storage 228 may include, for example, one or both of the system storage provided integrally (i.e., substantially inremovable) with removable storage that is removablely connectable to the computing platform 202 and / or the computing platform 202 via a port (e.g., a USB port, a FireWire port, etc.) or a drive (e.g., a disk drive, etc.). The electronic storage 228 may include one or more of the following: optically readable storage media (e.g., optical discs, etc.), magnetically readable storage media (e.g., magnetic tape, magnetic hard drives, floppy drives, etc.), charge-based storage media (e.g., EEPROM, RAM, etc.), solid-state storage media (e.g., flash drives, etc.), and / or other electronically readable storage media. The electronic storage 228 may include one or more virtual storage resources (e.g., cloud storage, a virtual private network, and / or other virtual storage resources). The electronic storage 228 may store software algorithms, information determined by the processor 230, information received from the computing platform 202, information received from the remote platform 204, and / or other information that enables the computing platform 202 to function as described herein.

[0052] The processor 230 may be configured to provide information processing capabilities in the computing platform 202. Therefore, the processor 230 may include one or more of the following: a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and / or other mechanisms for electronically processing information. Although the processor 230 is shown as a single entity in Figure 2, this is for illustrative purposes only. In some implementations, the processor 230 may include multiple processing units. These processing units may be physically located within the same device, or the processor 230 may represent the processing capabilities of multiple devices working together. The processor 230 may be configured to perform one or more modules (may be configured to perform one or more steps / operations as described herein). The processor 230 may be configured to perform modules by software, hardware, firmware, any combination of software, hardware, and / or firmware, and / or other mechanisms for constituting processing capabilities on the processor 230. As used herein, the term “module” may refer to any component or set of components that perform the functions resulting from the module. This may include one or more physical processors executing processor-readable instructions, circuits, hardware, storage media, or any other components.

[0053] Modules 208, 210, 212, 214, 216, 218, and / or 220 are illustrated as being implemented within a single processing unit, but it should be understood that one or more of these modules may be implemented by multiple processing units. In some implementations, one or more of these modules may be implemented remotely from other modules. The descriptions of the functions provided by the different modules 208, 210, 212, 214, 216, 218, and / or 220 described below are for illustrative purposes only and are not intended to be limiting, and any of modules 208, 210, 212, 214, 216, 218, and / or 220 may provide more or less functionality than described. For example, one or more of modules 208, 210, 212, 214, 216, 218, and / or 220 can be excluded, and some or all of their functions can be provided by other modules among modules 208, 210, 212, 214, 216, 218, and / or 220. As another example, processor 230 can be configured to run one or more additional modules that can perform some or all of the following functions that belong to one of modules 208, 210, 212, 214, 216, 218, and / or 220.

[0054] The techniques described herein can be implemented as a method performed by a physical computing device, as one or more non-temporary computer-readable storage media that store instructions causing the method to be performed when performed by a computing device, or as a physical computing device specially configured with a combination of hardware and software that causes the method to be performed.

[0055] Figure 3 is a flowchart illustrating the blocks in Method 300 for Implementing Management Precompiled on an Organizational Subnet, according to several embodiments.

[0056] The exemplary method 300 described herein may be implemented by one or more modules of system 200. For example, at least one or more steps of method 300 may be implemented by a computer platform including electronic storage and one or more processors, the one or more processors which execute machine-readable instructions and are coupled to communicate with remote platforms and external resources via a network (see computing platform 202, processor 230, machine-readable instructions 206, remote platform 204, external resource 226, and network 150). In addition, the machine-readable instructions may be part of a generation module, a management precompile module, and a verification module, as disclosed herein (see generation module 208, first precompile module 210, second precompile module 212, third precompile module 214, fourth precompile module 216, fifth precompile module 218, and / or verification module 220). For illustrative purposes, the steps of the exemplary method 300 are described herein as occurring sequentially or linearly. However, multiple instances of exemplary method 300 may occur in parallel. Furthermore, in embodiments consistent with the present disclosure, at least one or more steps of method 300 may be performed in different orders, simultaneously, quasi-simultaneously, or in overlapping time.

[0057] In step 302, method 300 may include launching an institutional subnet having one or more blockchains. One or more blockchains may have a VM that enables administrative precompilation. Administrative precompilation may include one or more arbitrary parameters of the state machine. In some implementations, administrative precompilation may include parameters such as administration used to enforce KYC / KYB compliance for interactions conducted on the blockchain.

[0058] In step 304, method 300 may include enabling a set of managed precompiles for each of one or more blockchains. The set of managed precompiles may include a transaction permission precompiler, a contract deployer precompiler, a native minter precompiler, a fee structure precompiler, and a reward manager precompiler. The precompiles included in the set of managed precompiles may only be modified by a set of managed addresses.

[0059] In step 306, method 300 may include implementing a KYC (Know Your Customer) process to authenticate the user. In some embodiments, the method may include registering the authenticated user and authorizing the registered user to interact with one or more blockchains.

[0060] Users may register their addresses through a KYC process. Embodiments are not limited to KYC and may include, but may include, KYB and / or AML compliance regulatory processes. All interactions with one or more blockchains require completion of a KYC (regulatory) process. A parameter such as "administration" may indicate (e.g., as a flag or status indicator) whether a user has gone through the KYC process. Thus, an address may be permitted to interact with a blockchain based on the value of a parameter such as "administration". In this way, for an address to be listed in one or more precompiles within a set of management precompiles, the address must have already been identified as a compliant address through the KYC process. Thus, a user deploying an application or attempting to interact with a blockchain can be seen as a trusted / authorized user.

[0061] For example, in order to be included in the list of addresses included in the transaction-enabled precompiler that is authorized to issue transactions, a user must go through the KYC process. As another non-exclusive example, in order to deploy a contract, a user must go through the KYB process.

[0062] In step 308, method 300 may include verifying that the user has gone through the KYC process. Based on the verification that the user has completed the KYC process, the user is authorized to interact with the block user chain of the institutional subnet. In some implementations, method 300 may further include generating and tracking each risk score (e.g., AML risk score) for each of the (one or more) users based on the verification (i.e., the KYC process).

[0063] In some implementations, the NTT application may be deployed on one or more blockchains or third-party blockchains to manage managed precompilation. In some embodiments, the NTT application may be deployed on the C chain of the blockchain. In some embodiments, the NTT application is deployed on the blockchain of the primary network to maximize the visibility of the NTT application. According to some embodiments, method 300 may further include creating a portal for users to go through the KYC process in the NTT application. In some implementations, the NTT provider is the administrator of precompilation. The NTT provider of the NTT application provides periodic risk checks to update the risk score associated with the user.

[0064] According to the embodiment, an institution may not know who its counterparties are, but it will know that its counterparties have fulfilled the institution's KYC obligations, for example, through a third-party provider like NTT. The institution can determine which counterparties it has interacted with through the NTT provider. A record of all blockchain transactions can be maintained on the chain. Therefore, even if an institution cannot identify its counterparties, it can track them through the records as required by regulations.

[0065] In some implementations, an address associated with a counterparty may only include functionality if the counterparty has an NTT indicating that it has gone through an approval process and is authorized to perform the transaction. Within a subnet (or institutional subnet), governance determines who issued / revoked the NTT. A VM may require address registration before it can send (or receive) funds or transactions. This prevents the loss of funds. Depending on the embodiment, the approval process may include checking the subnet to determine whether the user (or counterparty) is authorized to perform the transaction. In some implementations, the approval process may start with a trusted central KYC provider and then move toward a DAO-based approach for performing the approval process.

[0066] In step 310, method 300 may include modifying a set of precompiles for one or more blockchains on the institutional subnet based on the risk score requirements of each blockchain. Modifying a set of precompiles may include adding addresses to an approved list of addresses associated with one or more of the managed precompiles. The risk score requirements may include a KYC / AML risk score indicating what a user is required to interact with the blockchain, a threshold or range of KYC / AML risk scores.

[0067] In some implementations, the set of precompiled items may be modified by adding (and similarly removing) one or more managed precompiled items to the set of managed precompiled items.

[0068] According to several embodiments, Method 300 may further include creating a set of blockchains, each conforming to KYC / AML risk score requirements. According to one embodiment, Method 300 may include defining a set of rules outlining the conditions for transferring funds; that is, the set of rules defines the conditions under which funds are permitted to move between blockchains. Institutional subnets may define their own sets of rules.

[0069] Figure 3 shows an exemplary block of Method 300, but in some implementations, Method 300 may include additional blocks, fewer blocks, different blocks, or blocks in different arrangements than those depicted in Figure 3. In some embodiments, a Method consistent with the Disclosure may include at least one operation, such as in Method 300, performed in a different order, simultaneously, quasi-simultaneously, or temporally overlapping. Additionally or alternatively, two or more blocks of the Method may be performed in parallel.

[0070] Figure 4 illustrates an exemplary flowchart of a process 400 for enabling managed precompilation in a blockchain according to a particular aspect of the present disclosure. For example, at least one step of process 400 may be performed by a computer platform including electronic storage and one or more processors, the one or more processors which execute machine-readable instructions and are coupled to communicate with remote platforms and external resources via a network (see computing platform 202, processor 230, machine-readable instructions 206, remote platform 204, external resource 226, and network 150). In addition, the machine-readable instructions may be part of a generation module, a managed precompilation module, and a verification module, as disclosed herein (see generation module 208, first precompilation module 210, second precompilation module 212, third precompilation module 214, fourth precompilation module 216, fifth precompilation module 218, and / or verification module 220). Furthermore, for illustrative purposes, the steps of the exemplary process 400 are described herein as occurring sequentially or linearly. However, multiple instances of the exemplary process 400 may occur in parallel. Furthermore, in embodiments consistent with the present disclosure, at least one or more steps of method 400 may be performed in different orders, simultaneously, quasi-simultaneously, or in overlapping time.

[0071] Step 402 involves receiving an invocation request from a client device to invoke an input address to perform a specified precompiler on the blockchain initiated by the VM. In some implementations, the specified precompiler may be a managed precompiler or one of several other precompilers available to the VM. In some implementations, the input address may correspond to a precompiler. Alternatively, the input address may not coincide with the address of a VM precompiler.

[0072] Step 404 includes determining that the input address from the call request corresponds to a managed precompiled address; that is, determining that the input address matches a managed precompiled address.

[0073] Step 406 involves verifying that the client device (or the user of the client device) is authorized. For example, it identifies whether the client device is authorized to perform a deployment (e.g., deploying a contract) within the VM. In some implementations, for the deployer (e.g., the client device) to interact with the VM or the application within the VM, the deployer must go through a KYC / KYB compliance process before making any interaction. Therefore, anyone deploying an application or interacting with the VM may be considered an authorized user.

[0074] Step 408 involves identifying the respective operations of the managed precompile.

[0075] Step 410 includes enabling managed precompilation on the client device and performing the identified actions.

[0076] Figure 4 shows exemplary steps of process 400, but in some implementations, process 400 may include additional steps, fewer steps, different steps, or steps in different arrangements than those depicted in Figure 4. In some embodiments, a process consistent with this disclosure may include at least one or more steps, as in process 400, performed simultaneously, quasi-simultaneously, or in overlapping time. Additionally or alternatively, two or more steps of the process may be performed in parallel.

[0077] Hardware Overview Figure 5 is a block diagram illustrating an exemplary computer system 500 in which embodiments of the subject technology may be implemented. In certain embodiments, the computer system 500 may be implemented using hardware, or a combination of software and hardware, either as a dedicated server, integrated into another entity, or distributed across multiple entities. The computer system 500 may include a desktop computer, a laptop computer, a tablet, a phablet, a smartphone, a feature phone, a server computer, or something else. The server computer may be located remotely within a data center or stored locally.

[0078] A computer system 500 (e.g., a server and / or client) includes a bus 508 or other communication mechanism for communicating information and a processor 502 coupled to the bus 508 for processing information. For example, a computer system 500 may be implemented by one or more processors 502. Each of the one or more processors 502 may be a general-purpose microprocessor, a microcontroller, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a programmable logic device (PLD), a controller, a state machine, gated logic, a discrete hardware component, or any other suitable entity capable of performing computation or other operations on information.

[0079] In addition to the hardware, the computer system 500 may include code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or one or more combinations thereof, stored in the accompanying memory 504, such as code that creates an execution environment for the computer program in question, for example, random access memory (RAM), flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable PROM (EPROM), registers, hard disks, removable disks, CD-ROMs, DVDs, or any other suitable storage devices coupled to the bus 508 for storing information and instructions executed by the processor 502. The processor 502 and memory 504 may be supplemented by or incorporated into a particular-purpose logic circuit.

[0080] Instructions are stored in memory 504 and may be implemented in one or more modules of computer program instructions that are encoded on a computer-readable medium to be executed by one or more computer program products, i.e., computer program instructions encoded on a computer-readable medium to control the operation of computer system 500, in any way well known to those skilled in the art, including but not limited to computer languages ​​such as data-oriented languages ​​(e.g., SQL, dBase), system languages ​​(e.g., C, Objective-C, C++, Assembly), architecture languages ​​(e.g., Java, .NET), and application languages ​​(e.g., PHP, Ruby, Perl, Python). Instructions can also be implemented in computer languages ​​such as array languages, aspect-oriented languages, assembly languages, authoring languages, command-line interface languages, compiled languages, concurrent languages, curly brace languages, data flow languages, data structure languages, declarative languages, esoteric languages, extended languages, fourth-generation languages, functional languages, interactive mode languages, interpreted languages, iterative languages, list-based languages, little languages, logic-based languages, machine languages, macro languages, metaprogramming languages, multi-paradigm languages, numerical analysis, non-English-based languages, object-oriented class-based languages, object-oriented prototype-based languages, offside rule languages, procedural languages, reflexive languages, rule-based languages, scripting languages, stack-based languages, synchronous languages, syntactic processing languages, visual languages, Worth languages, and XML-based languages. Memory 504 can also be used to store temporary variables or other intermediate information during the execution of instructions performed by processor 502.

[0081] Computer programs as considered herein do not necessarily correspond to files in a file system. A program may be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., a file storing one or more modules, subprograms, or portions of code). Computer programs may be deployed to run on one or more computers located at one site or distributed across multiple sites and interconnected by a communication network. The processes and logical flows described herein may be implemented by one or more programmable processors that execute one or more computer programs to perform their functions by manipulating input data and producing outputs.

[0082] The computer system 500 further includes a data storage device 506, such as a magnetic disk or optical disk, coupled to a bus 508 for storing information and instructions. The computer system 500 may be coupled to various devices via an input / output module 510. The input / output module 510 can be any input / output module. An exemplary input / output module 510 includes a data port, such as a USB port. The input / output module 510 is configured to connect to a communication module 512. An exemplary communication module 512 includes a networking interface card, such as an Ethernet card and a modem. In certain embodiments, the input / output module 510 is configured to connect to multiple devices, such as an input device 514 and / or an output device 516. An exemplary input device 514 includes a keyboard and a pointing device, such as a mouse or trackball, through which a user can provide input to the computer system 500. Other types of input devices can also be used to provide user interaction, such as a tactile input device, a visual input device, a voice input device, or a brain-computer interface device. For example, the feedback provided to the user may be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback, and input from the user may be received in any form, including acoustic, voice, tactile, or electroencephalogram (EEG) input. An exemplary output device 516 includes a display device such as an LCD (liquid crystal display) monitor for displaying information to the user.

[0083] According to one aspect of the present disclosure, the system described above can be implemented using a computer system 500 in response to a processor 502 executing one or more sequences of one or more instructions contained in a memory 504. Such instructions may be read into the memory 504 from another machine-readable medium, such as a data storage device 506. Upon executing the sequence of instructions contained in the main memory 504, the processor 502 performs the process steps described herein. One or more processors in a multiprocessing configuration may also be used to execute the sequence of instructions contained in the memory 504. In alternative embodiments, hard-wired circuits may be used instead of or in combination with software instructions to implement various aspects of the present disclosure. Thus, aspects of the present disclosure are not limited to any specific combination of hardware circuits and software.

[0084] Various embodiments of the subject matter described herein can be implemented in a computing system that includes, for example, backend components such as data servers, middleware components such as application servers, or frontend components such as client computers having a graphical user interface or a web browser, and a user can interact with the implementation of the subject matter described herein through the graphical user interface or a web browser, or with any combination of one or more such backend, middleware, or frontend components. The components of the system can be interconnected by any form or medium of digital data communication, such as a communication network. The communication network may include, for example, one or more of LANs, WANs, and the Internet. Furthermore, the communication network may include, but is not limited to, one or more of the following network topologies, such as bus networks, star networks, ring networks, mesh networks, starbus networks, tree or hierarchical networks. The communication module may be, for example, a modem or an Ethernet card.

[0085] The computer system 500 may include a client and a server. The client and server are generally remote from each other and typically interact through a communication network. The client-server relationship is established by computer programs running on each computer that have a client-server relationship with each other. The computer system 500 may be, for example, a desktop computer, a laptop computer, or a tablet computer, for example. The computer system 500 may also be embedded in another device, for example, a mobile phone, a PDA, a mobile audio player, a Global Positioning System (GPS) receiver, a video game console, and / or a television set-top box, for example.

[0086] The terms “machine-readable storage medium” or “computer-readable medium” as used herein refer to any medium or medium involved in providing instructions to the processor 502 for execution. Such mediums can take many forms, including but not limited to non-volatile media, volatile media, and transmission media. Non-volatile media include, for example, optical or magnetic disks such as data storage device 506. Volatile media include dynamic memory such as memory 504. Transmission media include coaxial cables, copper wires, and optical fibers, including wires that constitute bus 508. Common forms of machine-readable media include, for example, floppy disks, flexible disks, hard disks, magnetic tapes, any other magnetic media, CD-ROMs, DVDs, any other optical media, punch cards, paper tapes, any other physical media having a pattern of holes, RAM, PROMs, EPROMs, FLASH EPROMs, any other memory chips or cartridges, or any other media that a computer can read. A machine-readable memory medium can be a machine-readable memory device, a machine-readable memory substrate, a memory device, a composition of a substance that affects machine-readable propagated signals, or a combination of one or more of these.

[0087] The techniques described herein may be implemented as a method performed by a physical computing device, as one or more non-temporary computer-readable storage media that store instructions causing the method to be performed when executed by a computing device, or as a physical computing device specially configured with a combination of hardware and software that causes the method to be performed.

[0088] The phrase “at least one of” preceding a set of items, accompanied by the terms “and” or “or” to separate any of the items, when used herein, qualifies the list as a whole, rather than each member of the list (i.e., each item). The phrase “at least one of” does not require the selection of at least one item; rather, the phrase allows for meanings including at least one of any one of the items, and / or at least one of any combination of items, and / or at least one of each of the items. For example, the phrases “at least one of A, B, or C” or “at least one of A, B, or C” refer to A only, B only, or C only, any combination of A, B, and C, and / or at least one of each of A, B, and C, respectively.

[0089] To the extent that terms such as “include” and “have” are used in the description or claims, such terms are intended to be inclusive in the same manner as the term “comprise” is interpreted as “comprise” when used as a transitional term in a claim. The term “exemplary” is used herein to mean “serving as an example, case, or illustration.” No embodiment described herein as “exemplary” should necessarily be construed as being preferable or advantageous to any other embodiment.

[0090] References to elements in the singular form are intended to mean "one or more" rather than "one and only one" unless specifically stated otherwise. All structural and functional equivalents to elements of the various configurations described throughout this disclosure, whether known to those skilled in the art or subsequently known, are expressly incorporated by reference herein and are intended to be encompassed by the subject art. Furthermore, nothing disclosed herein is intended to be for the public only, whether such disclosure is expressly enumerated in the above specification. Elements of a clause should not be construed under the provisions of Section 112, paragraph 6 of the United States Patent Act unless those elements are expressly enumerated using the phrase "means for" or, in the case of a method clause, unless those elements are enumerated using the phrase "steps for".

[0091] While this specification contains many details, these should not be interpreted as limitations on the scope of claims, but rather as descriptions of specific implementations of the subject matter. Certain features described herein in the context of separate embodiments may be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may be implemented separately in multiple embodiments, or in any preferred partial combination. Furthermore, features described above as acting in a particular combination and initially claimed as such, may, in some cases, be removed from the claimed combination, and the claimed combination may be subject to a partial combination or a variation of a partial combination.

[0092] While the subject matter of this specification is described in terms of specific embodiments, other embodiments may be implemented and are within the scope of the following claims. For example, although the operations are depicted in a specific order in the drawings, this should not be understood as meaning that such operations must be performed in a specific order or sequence shown, or that all illustrated operations must be performed in order to achieve a desired result. The actions enumerated in the claims may be performed in a different order and still achieve the desired result. As an example, the processes depicted in the accompanying drawings do not necessarily require a specific order or sequence shown to achieve a desired result. In certain circumstances, multitasking and parallel processing may be advantageous. Furthermore, the separation of various system components in the embodiments described above should not be understood as meaning that such separation is necessary in all embodiments, and the described program components and systems may generally be integrated together in a single software product or packaged in multiple software products. Other variations are within the scope of the following claims.

Claims

1. A computer implementation method carried out by at least one processor, Creating an institutional subnet that has one or more blockchains, Enable a set of managed precompilers for one or more blockchains, Verification of whether users of the aforementioned institutional subnet are authorized to interact with one or more of the aforementioned blockchains, Based on the above verification, a risk score associated with the user is generated, Based on the risk score, modify at least one managed precompile in the set of managed precompiles for the one or more blockchains based on the risk score requirements for each of the one or more blockchains, A computer implementation method including

2. Receiving an invocation request from an authorized user, which includes the address of at least one managed precompiler within the set of managed precompilers, Based on the aforementioned call request, the at least one managed precompile operation is performed, The computer implementation method according to claim 1, further comprising:

3. Approving users of the aforementioned institutional subnet through the regulatory process, The computer implementation method according to claim 1, further comprising registering authorized users of the institutional subnet in one or more blockchains, wherein the registered users of the one or more blockchains are authorized to interact with the one or more blockchains.

4. The computer implementation method according to claim 1, wherein the set of management precompiles includes parameters for a state machine that manages one or more blockchains.

5. The computer implementation method according to claim 1, wherein the set of managed precompiles includes parameters used to enforce security regulations in a compliance regulatory process.

6. The computer implementation method according to claim 1, wherein the set of managed precompiles is modified by a management user, and the management user is defined within the set of managed precompiles.

7. Deploying a non-transferable token application on one or more of the aforementioned blockchains, The computer implementation method according to claim 1, further comprising generating a user portal with the non-transferable token application, wherein the compliance regulatory process is implemented to authorize users of the institutional subnet through the user portal.

8. The computer implementation method according to claim 1, wherein the set of managed precompilers includes a transaction permission precompiler that maintains a list of addresses that have been enabled to perform transactions on one or more blockchains.

9. The computer implementation method according to claim 1, wherein the set of managed precompilers includes a contract deployer precompiler that maintains a list of addresses that are enabled to deploy a contract on one or more blockchains.

10. The computer implementation method according to claim 1, wherein the set of management precompilers includes a native minter precompiler that maintains a list of addresses that are enabled to mint native tokens of the institutional subnet.

11. The computer implementation method according to claim 1, wherein the set of management precompiles includes a rate configuration precompile that maintains a list of addresses which are enabled to update the rate configuration of the institutional subnet.

12. The computer implementation method according to claim 1, wherein the set of management precompiles includes a reward precompile that maintains a list of addresses that are enabled to update the award managers of one or more blockchains.

13. A system for implementing managed precompilation, One or more processors, The system comprises a memory that stores instructions, and when an instruction is executed by one or more processors, the system... Create an institutional subnet that has one or more blockchains, A set of managed precompilers for one or more blockchains, which includes parameters used to enforce security regulations in the institutional subnet, enabling the set of managed precompilers. Verify whether the users of the aforementioned institutional subnet are authorized to interact with one or more of the aforementioned blockchains. Based on the above verification, generate a risk score associated with the user. A system that modifies at least one managed precompile in the set of managed precompiles for the one or more blockchains based on the risk score requirements of each of the one or more blockchains, based on the risk score requirements of each of the one or more blockchains.

14. The system according to claim 13, wherein the set of managed precompilers includes a transaction permission precompiler that maintains a list of addresses that have been enabled to perform transactions on one or more blockchains.

15. The system according to claim 13, wherein the set of managed precompilers includes a contract deployer precompiler that maintains a list of addresses that enable the deployment of contracts on one or more blockchains.

16. The system according to claim 13, wherein the set of management precompilers includes a native minter precompiler that maintains a list of addresses that are enabled to mint native tokens of the institutional subnet.

17. The system according to claim 13, wherein the set of management precompiles includes a rate configuration precompile that maintains a list of addresses which are enabled to update the rate configuration of the institutional subnet.

18. The system according to claim 13, wherein the set of managed precompilers includes a reward precompiler that maintains a list of addresses that are enabled to update the award managers of one or more blockchains.

19. The one or more processors described above are: Approve users of the said agency subnet through the regulatory process, The system according to claim 13, further executing an instruction to register an authorized user of the institutional subnet in one or more blockchains, wherein the registered user of one or more blockchains is authorized to interact with one or more blockchains.

20. A non-temporary computer-readable storage medium containing stored instructions, wherein, when the instructions are executed by one or more processors, the one or more processors... Creating an institutional subnet that has one or more blockchains, Enable a set of managed precompiles for one or more blockchains, which includes parameters used to enforce security regulations in the institutional subnet. Verification of whether users of the aforementioned institutional subnet are authorized to interact with one or more of the aforementioned blockchains, Based on the above verification, a risk score associated with the user is generated, Based on the risk score, modify at least one managed precompile in the set of managed precompiles for the one or more blockchains based on the risk score requirements for each of the one or more blockchains, A non-temporary computer-readable storage medium that enables the execution of methods including [specific actions].