CROSS-REFERENCE TO RELATED APPLICATIONS

[1] This application claims the benefit of U.S. Provisional Patent Application No. 63/417,596, filed on October 19, 2022, entitled “SYSTEMS AND METHODS FOR AUTOMATING THE DEVELOPMENT OF LIFECYCLE OF SMART CONTRACTS”, which is incorporated herein by reference in its entirety.

BACKGROUND

[2] In the field of blockchain technology, there are existing practices followed by developers in the development of smart contracts. These include the following: developers identify the business logic for the smart contract; they write the code for the smart contract using an IDE (for example - VS code) by defining the variables, creating the logic for each function and essentially writing the entire code from scratch; they compile the code; they write test cases for testing the business logic of the code; they run the test cases; for each resulting error, fix the business logic; they get the contract audited by an audit firm for security vulnerabilities; they remediate each vulnerabilities by fixing the appropriate code; and they deploy it on the blockchain of their choice. Every step mentioned above is manually done today.

[3] It is desirable to improve the processes for developing smart contracts so that they can be developed faster and with more security. BRIEF DESCRIPTION OF THE DRAWINGS

[4] Features of the present disclosure may be illustrated by way of example and not limited in the following figure(s), in which like numerals indicate like elements, in which:

[5] FIG. 1 shows an example interface of how to start designing a smart contract quickly using the interface in the platform of the present disclosure;

[6] FIG. 2 shows an illustration of how the user may also have the ability to see search results after typing in a query term expressing a type of smart contract the user wants to create;

[7] FIG. 3 shows another example of results based on a user’s search query, according to some embodiments;

[8] FIG. 4 is an illustration showing multiple search results shown in FIG. 3 that may be selected at the same time, in the event that the user may opt to generate multiple smart contracts;

[9] FIG. 5 is an illustration showing a feature to compare the different templates in the search results;

[10] FIG. 6 is an illustration showing how the interface may then provide the ability for the user to select the most relevant smart contract template as a starting point;

[11] FIG. 7 is an illustration showing how the interface also allows for modifications to view and select any module from the list of relevant modules from the palette on the right side that can be dragged and dropped to the design canvas;

[12] FIG. 8 is an illustration of the graphical canvas showing the auto-remediation feature to fix syntax errors; [13] FIG. 9 is an illustration showing three modules with different resources and relevance to resolve errors by giving the user the option to examine alternate modules;

[14] FIG. 10 is an illustration showing how the platform may allow through the design canvas the feature to auto-fix any compatibility issue;

[15] FIG. 1 1 is an illustration showing that the user may be able to build the logic into the smart contract and can then select one of the suggestions offered by the platform to satisfy the latest syntax rules;

[16] FIG. 12 is an illustration showing an example display of the smart contract validation phase where the user can choose to generate functional test cases for the business logic;

[17] FIG. 13 is an illustration showing an example set of test cases that present different scenarios to see how the smart contract may perform;

[18] FIG. 14 is an illustration showing an example of how running the test cases helps to validate the business the logic automatically of the smart contract by revealing errors that occurred during the test cases;

[19] FIG. 15 is an illustration showing an example display of the logic of the smart contract that brings the user to the source of the errors from the test cases;

[20] FIG. 16 shows an example display of the user being able to deploy the smart contract to one or more different blockchains;

[21] FIGS. 17A and 17B is an example methodology in two halves, performed by a smart contract generation platform to design smart contracts quickly and optimally, according to some embodiments; [22] FIG. 18 is a flowchart of an example methodology for fixing incompatibility errors between different versions, according to some embodiments; and

DETAILED DESCRIPTION

[23] Aspects of the disclosure include a development platform in the field of blockchain technology. The developer platform described herein may be used to help blockchain developers create, validate, audit and deploy smart contracts. Smart contracts are the core building blocks of any blockchain/web 3 application. They define the backend logic of these applications. Although blockchain and web 3 are getting more widely adopted, several barriers still exist. For example:

[24] Designing smart contracts takes too long. Creating a smart contract is a time intensive process. This is because usually developers create smart contracts from scratch and there is no reusability.

[25] It is difficult to design an optimal contract. Expertise is required to adopt the right checks and balances for optimal and efficient contract design.

[26] Versions of programming languages change too frequently. Solidity and other major smart contract development languages are constantly evolving and a new version is released every few months to a year. When a major version gets released, syntax usage is changed and is not backward compatible.

[27] Business logic validation is very complex. Validation suite and test cases are currently manually written using available frameworks. This is not only time-consuming but also leaves a lot of room for missed coverage and errors in the test cases. [28] Smart contracts lack security. Smart contracts have been frequently exploited for monetary reasons through their security loopholes. This is because the contracts do not go through the required audits since such audits are very expensive and take a long time to be completed.

[29] There is no existing solution that solves these problems effectively, either singularly or in combination. The present disclosures address these problems through a platform that automates the end-to-end lifecycle of smart contracts including their creation, validation, deployment, upgradation and termination.

[30] In particular, the aspects of the present disclosure include a platform for developing smart contracts in an efficient and secure manner. The functionality provided by the platform also makes development more robust and capable of handling multiple blockchains and evolving versions. For example, aspects of the present disclosure allow for the following features:

[31] Design smart contracts more quickly. Creating smart contracts may be about 8-10 times faster using aspects of the present disclosure compared to traditional approaches. Using hundreds of templates designed and available for users to start customizing, the users never have to create any smart contract from scratch. The solution of the present disclosure provides the users with an excellent user interface to either (i) use the contract from the templates as it is, (ii) use the template and add additional functionality by dragging/dropping more pre-canned functions, or (iii) customize the precanned functions to add/modify logic as per the user’s requirements.

[32] Design optimal smart contracts. Users can leverage the platform's capabilities to apply the right checks and balances for an optimal contract design. Examples include checking for invalid conditions that might lead to loss of assets and providing auto-fixes for version incompatibilities, etc. A user of the platform according to the present disclosures will typically leverage the platform's capabilities to apply the right checks and balances for an optimal contract design. For example, the platform may automatically add checks for invalid conditions that might lead to loss of assets such as an invalid wallet, insufficient funds, etc. This allows for the development of the smart contract to not rely on the user’s expertise to add these critical checks. The platform also flags inefficiencies in the contract that can increase the gas consumption.

[33] Auto-remediation of syntax errors resulting from version incompatibility. The platform auto-remediates syntax errors that might result from version incompatibilities when the user decides to update the version of the code or copies/pastes code from different versions.

[34] Automate business logic validation. Test cases for business logic validation may get auto-generated by the platform that can be later executed. Resulting errors can be auto-fixed wherever possible.

[35] Make smart contracts secure. The platform according to aspects of the present disclosure performs autonomous security audits of smart contracts and auto-fixes of resulting vulnerabilities. It conducts a thorough analysis of the smart contract and identifies occurrences of patterns that might result in a vulnerability through advanced machine learning techniques. It then flags those vulnerabilities to the user and suggests fixes to resolve them, which the user can simply choose to apply.

[36] The platform of the present disclosure presents an end-to-end solution that is a combination of (i) different inventive algorithms and (ii) internally developed data. Embodiments of the present disclosure may be in the form of a platform that can include functionality of any one of the aforementioned solutions or a combination of more than one, as well as the individual methods to perform these solutions or combinations of these methods.

[37] The platform of the present disclosure may be manifested in different modalities. For example, the platform may be practiced through an NPM (Noble Programming Mantra) package and through a Web interface.

[38] NPM package - In this example, the platform of the present disclosures is available in the form of an NPM package that can be installed and accessed through any integrated development environment (IDE) such as Visual Studio (VS) code.

[39] Upon installing the NPM package, the user will be able to do the following from within their IDE:

[40] Rapidly design an optimal and efficient smart contract

[41] The user may be able to search for the appropriate smart contract template by running the search command and providing keywords to search against as the argument. The user may be able to compare the relevant smart contract templates using the following example parameters - gas burn rate, relevance to the current requirement, and security rating, among others. The user may also be able to select the most relevant smart contract template as a starting point. Upon selection of the smart contract template, the template files will get created. The user may also be able to view and select a module from the list of relevant modules that can be pulled up and searched for using keyword actions. Upon selecting the module, the module code will be created in the current file. In addition, the incompatibility errors and checks and balances will be listed next to the appropriate lines of code. The user can also invoke the alternate modules list and compare them wherever applicable through keyboard actions. Also, the user can run a command to fix errors and automatically add the checks wherever possible.

[42] Validate and deploy the designed smart contract

[43] The user may choose to generate functional test cases for the business logic by running a command. When they run this command, the NPM package will analyze the business logic and design the functional test cases. The user may also choose to execute the generated test cases. The resulting errors upon the execution of functional test cases will be listed next to the code as appropriate. Wherever possible, the user can auto-fix the errors by running a command. The user can also choose to run the security audit of the smart contract by running a command. The resulting vulnerabilities upon the execution of security audits will be listed next to the code as appropriate. Wherever possible, the user can also auto-fix the vulnerabilities by running a command. In addition, users can connect with the appropriate wallet for gas (for example - metamask). Moreover, a user can choose a specific network (e.g., local, testnet and mainnet) on any blockchain (EVM & non-EVM based) and deploy smart contracts on that network.

[44] Web interface - The web interface may be available as a stand-alone full-fledged no code platform. This may be used by developers and business analysts. Developers and business analysts will be able to design, validate and deploy smart contracts across blockchains using this edition of the platform without having to write a single line of code.

[45] The web interface may also support the same features as mentioned above, just in the web interface format rather than in a command line interface. The following may be two additional components of the web interface. [46] A dashboard may be present in the web interface that allows the user to 1 ) view all created smart contracts; 2) click on any smart contract to view the detailed end-end workflow on the designer studio; and 3) enter the intention of the smart contract in a search-bar that opens the closest smart contract template on the designer studio.

[47] Furthermore, the web interface may include a designer studio that can be used by the user to modify the smart contract template and save it as a new contract or design a completely new smart contract.

[48] The designer studio feature includes three components: smart contract design canvas, ribbon and data binding palette.

[49] In the smart contract design canvas component, the user may be allowed to view and design the workflow of the smart contract. Workflow includes functional blocks, their interconnectivity and business login within each functional block.

[50] The ribbon component includes a toolbar containing elements that can be dragged and dropped to create functional blocks and business logic. For example, the user may drag and drop a decision block, data provider block, async message block, etc.

[51] The data binding palette component represents a palette for binding/linking data received from data providers to variables and function parameters.

[52] Whether utilizing the platform through an IDE or a web interface or any other kind of interactive medium, aspects of the present disclosure may provide any or all of the five following solutions: 1 ) designing smart contracts quickly; 2) designing optimal smart contracts; 3) auto-remediation of syntax errors resulting from version incompatibility; 4) automating business logic validation; and 5) making smart contracts secure. [53] Designing smart contracts quickly and optimally

[54] In some embodiments, aspects of the present disclosure include features in the platform to design smart contracts quickly and efficiently with optimal resources. For example, the platform may allow for searching for the appropriate smart contract template by typing in keywords in a search bar. The platform according to aspects of the present disclosure may utilize templates of different types of smart contracts as starting positions to help users develop the smart contracts more quickly. The interface may allow for the user to be able to see various features about each template so that the user can make informed decisions about how to use the templates. FIG. 1 shows an example interface of how to start designing a smart contract quickly using the interface in the platform of the present disclosure. Here, the interface begins with a series of questions to help the user specify what kind of smart contract they want to make. In this example, they are asked to choose the business domain that the user is creating for this smart contract. The options include decentralized finance (Defi), Gaming, and a non-fungible token (NFT).

[55] Referring to FIG. 2, the user may also have the ability to see search results after typing in a query term expressing a type of smart contract the user wants to create. In this example, the search term “ICO” was entered, and two options that may satisfy that query are presented on the left. The options show a potential cost for generating these smart contracts, as judged by gas rate. In the right panel, there are several options shown for types of tokens, such as Crowdsale and DappToken that may be relevant to the user’s query.

[56] Referring to FIG. 3, another example of results is shown based on a user’s search query. Here, the user has entered “Crowdsale” and has received several module suggestions related to the query on the left. A description of the first suggestion, “Token Vesting Crowdsale,” is shown on the right. Some vital statistics are shown, such as the number of parameters that are taken in for the smart contract, the number of libraries it uses to create the example smart contract, and how many transactions are involved. Referring to FIG. 4, multiple search results shown in FIG. 3 may be selected at the same time, in the event that the user may opt to generate multiple smart contracts.

[57] Referring to FIG. 5, according to some embodiments, a feature is available to compare the different templates in the search results, as shown in this illustration. To the right of each search result are shown various descriptions, including a summary description of the module, the gas burn rate, the calculated relevance of the search result, any perceived security vulnerabilities, a number of transactions inputs, and a number of transactions outputs. The user may then be able to make more informed decisions on what modules to utilize.

[58] Referring to FIG. 6, the interface may then provide the ability for the user to select the most relevant smart contract template as a starting point. Here, upon selection of the smart contract template, the template will get loaded on the design canvas and then get displayed along with its modules. The interface at the top provides a roadmap for where the user is at in the generation. In this case, the user is still in the design phase. Three modules are shown in the design canvas: mintable token, deployment, and vesting wallet.

[59] Referring to FIG. 7, the interface also allows for modifications as desired. Here, the user is able to view and select any module from the list of relevant modules from the palette on the right side that can be dragged and dropped to the design canvas. An example of “module 1 ” is shown as being added to the design canvas that came from the drop down menus on the right side. The user can therefore modify a starting template of a smart contract to suit his or her needs.

[60] Auto-remediation of syntax errors resulting from version incompatibility

[61] In some embodiments, aspects of the present disclosure include the capability to automatically resolve errors resulting from new versions the smart contracts are written on that would be normally incompatible with older versions.

[62] Referring to FIG. 8, in continuing with the graphical canvas for creating the smart contract as shown in the previous figures, the auto-remediation feature to fix syntax errors may be included as part of the design phase. In this example, the incompatibility errors and checks and balances will be listed against the module, as shown in the pop-up display to module 1. The type of error may be explained in the top of the pop-up display, and there may be one or more options for how to resolve the error. Machine learning may be utilized to train the interface to the platform for how to spot the different kinds of errors as new versions become available. The platform may be trained to learn the differences in the latest versions in order to identify errors in the syntax.

[63] Referring to FIG. 9, to resolve the errors, the user may also be given the option to examine alternate modules and invoke them as needed in the event they do not have the same errors. As shown in FIG. 9, three modules are shown in the right side of the screen with different resources and relevance. The user may have the option to select another one of these modules in order to overcome the syntax issues of a previous module.

[64] Referring to FIG. 10, in some embodiments, the platform may allow through the design canvas the feature to auto-fix any compatibility issue, as shown in the example illustration. A pop-up display may be shown to explain the problem and then explain that the issue has already been resolved. The display may explain how the issue was fixed. The user can then acknowledge the changes by selecting the button on the bottom right of the display.

[65] Referring to FIG. 11 , in some embodiments, the platform of the present disclosures may also allow the user the ability to choose to manually fix any incompatibilities and add checks based on suggestions. As an example, shown in the illustration of FIG. 1 1 , the user may be able to build the logic into the smart contract and can then select one of the suggestions offered by the platform to satisfy the latest syntax rules. In this way, the exact syntax required can be offered by the platform so that the user can be aided in generating the smart contract according to the latest syntax rules.

[66] Validate and deploy the designed smart contract

[67] Once the user has designed the smart contract as intended, by employing the templates feature and/or employing the feature to auto-remediate any syntax errors of older versions, the user can then proceed to the validation phase of the smart contract generation process. In this phase, the aspects of the present disclosure include an additional inventive feature of automating business logic validation.

[68] Automating business logic validation

[69] Referring to FIG. 12, shown is an example display of the smart contract validation phase where the user can choose to generate functional test cases for the business logic. The left side of the screen presents a number of options for several types of test cases that the user may select to validate the smart contract. In this example screen, the test cases are being generated. The user can choose to execute the generated test cases to ensure the smart contract validates as desired. [70] Referring to FIG. 13, shown is an example set of test cases that present different scenarios to see how the smart contract may perform. The test cases have been generated successfully, and the user may then select any or all of the test cases.

[71] Referring to FIG. 14, shown is an example of how running the test cases helps to validate the business the logic automatically of the smart contract by revealing errors that occurred during the test cases. Here, two of the four test cases resulted in failing outcomes, meaning the smart contract did not work as intended under those conditions specified in the test cases. The user will then have the option to fix the failed results and modify the smart contract as needed. This is different than validating the syntax in that this phase examines more of the logic of the smart contract.

[72] Referring to FIG. 15, shown is a display of the logic of the smart contract that brings the user to the source of the errors from the test cases. This example display provides the user the opportunity to automatically fix the errors revealed by the test cases. At the bottom of the screen is a display to give the user the option to auto-fix the error revealed by a test case, and of course an opportunity to manually fix the error as well. The highlighted logic block for returning the total allocation * (timestamp - start) I duration was flagged as containing an error, which the validation phase of the present disclosure may be able to resolve automatically.

[73] Making smart contracts secure

[74] Aspects of the present disclosure also may include features to make the smart contract secure. In some embodiments, after the validation phase, the platform may include a security phase that enables the user to add one or more layers of security to the smart contract. For example, the user can choose to run the security audit of the smart contract. The platform of the present disclosures may then employ internal test cases to test the robustness of the smart contract in order to expose any security vulnerabilities. The resulting vulnerabilities upon the execution of security audits will be listed in a display, and in some cases will provide explanations of the types of vulnerabilities. Wherever possible, the user can auto-fix the vulnerabilities using tools provided in the security phase. In some embodiments, the platform provides suggestions and modules for increasing security of the smart contract. The test cases may be run again to examine how the modifications have improved the robustness of the smart contract.

[75] In addition, in some embodiments, once the smart contract has passed through the design, validation, and security phases, the user can choose a specific network (e.g., local, testnet and mainnet, etc.) on EVM-based and Solana blockchains and deploy smart contracts on that network in the deployment phase. FIG. 16 shows an example display of the user being able to deploy the smart contract to one or more different blockchains. Shown here is the smart contract being deployed on blockchain type RSK on the network RSK_TESTNET. Also shown is the Ethereum account from which the smart contract will be deployed.

[76] Referring to FIGS. 17A and 17B, shown is an example methodology in two halves, flowchart 1700 and 1750, performed by a smart contract generation platform to design smart contracts quickly and optimally, according to some embodiments. The example method provided may be consistent with the descriptions above and FIGS. 1 -16. At 1702, the platform of the present disclosure may cause display of a dashboard for the user to view which lists all of the available smart contract templates. This may represent the start of how to develop smart contracts in a way that is easier and still optimal for newer users. [77] At 1706, the user may be presented in the dashboard with a query of whether to modify an existing smart contract, based on one or more templates stored in the system. At 1704, if the user chooses to, the platform may receive an input from the user to select a smart contract template that they want to modify, which the platform may then cause to open in the design canvas dashboard. On the other hand, at 1708, the user may opt to create their own smart contract from scratch. This may cause the platform to display a series of prompts to help provide more relevant modules for the user. The platform may receive an input from the user describing the user’s intention of the smart contract in a search bar. This may generate a search for relevant smart contract modules. At 1712, the platform may analyze the input and provide a series of smart contract templates that lack any specific variables. At 1716, after the user sees the available templates of options, the user may select one to start generating a new smart contract. From 1704 and 1716, if the user has selected a smart contract to work from, the platform may proceed to 1710, where the platform may display in the design canvas the smart contract logic modules and other parameters. The platform will allow the user to see the workflow of the smart contract so they can visualize the corresponding logic in the flow diagram. Alternatively, at 1724, if the user does not find a preferred template to start a smart contract, the platform is configured to provide a blank smart contract in the design canvas where the user can start designing from scratch.

[78] At 1714, in the situation where the platform has provided at least a base template for the smart contract from 1710, the platform provides the interactive interface in the design canvas to allow the user to tweak the flow diagram of the chosen smart contract by dragging and dropping new modules or deleting existing modules. At 1718, the platform has programming logic running behind the scenes such that when the user adds a new module to the contract in the canvas, the platform is configured to compose the smart contract code by merging source code of each module such that only the unique functions, unique variables and libraries are available to the merged contract. This ensures that there is no compile time errors and the code is optimized for gas. This is achieved by comparing the abstract syntax trees of each module and identifying the repetitive sub-tree structures across the modules. Wherever the sub-tree structures are exactly the same across modules for the same sub-tree identifier (function signature), it knows the functions implementations are the same between modules. The approach is similar for variables and library imports. The canvas is configured to allow the user to add these new modules by moving graphical representations of the modules in a drag and drop fashion. The user may perform these actions starting from a blank canvas or from a new template as well, referring back to 1724. See FIGS. 7, 8, and 1 1 as some examples.

[79] At 1720, the user may also create a brand new module or customize an existing pre-canned module through the canvas of the platform, according to some embodiments. When the user creates or customizes a module, the user can drag and drop building block functions to compose the module. When the user does this, the platform is configured to invoke the appropriate code from each building block function and merge this with the code for the other blocks. The module can be compiled by itself, and the platform may be configured to merge the code such that the module can be compiled together with the other modules. See FIGS. 7, 8, and 11 as some examples.

[80] At 1722, the platform may be configured to also allow the user to connect a new function to a module in the canvas interface. When the user drags a new function to the module, all the required global variables are automatically created. The user can choose to view the resulting solidity code of the module or the contract. The user can choose to customize the logic of the building block functions by dragging and dropping the appropriate constructs. For example, to add an “if-else” logic to the existing function, the user can drag and drop the if-else construct from the palette on the side of the screen onto the function and configure the logic for if-else logic using the configurator. See FIGS. 7, 8, and 11 as some examples. The example methodology continues from 1722 to FIG. 17B at 1726.

[81] Referring to FIG. 17B, flowchart 1750 continues the methodology from FIG. 17A. At 1726, the methodology continues wherein the platform is configured to accept user inputs in that the user can choose to add or delete variables as required. Once the contract is ready, the platform is configured to accept an input from the user so that the user can choose to add web 2 application program interfaces (APIs) to it, such as Oracles. At 1728, the platform may be configured to accept inputs so that the user can describe the kind of data feed/oracle they’re looking for in the search bar and hits search button. The platform may then be configured to generate a list of all matching data feeds with that description.

[82] At 1730, the platform may determine if a data feed is returned. If not, then at 1732, the platform may be configured to accept inputs from the user to create new data feeds and attach an API and any related information to it. The methodology proceeds to 1734 after. Alternatively, if data feeds are returned, then at 1734, the platform may be configured to accept inputs from the user to bind data from a data feed to the smart contract for logical processing. Furthermore, the platform may allow for the user to commit their changes to create a new smart contract version or template during any of the modifications made.

[83] At 1736, the platform may be configured to enable the user to design and run the test harness, which includes the ability to run test cases, for validation of individual functions within the smart contract and end-to-end business logic. Examples include FIGS. 12, 13, 14, and 15.

[84] At 1738, the platform determines if there are any runtime errors. If there are, then at 1740, the platform may be configured to show through the canvas a visualization of the errors to the user. Examples include FIGS. 12, 13, 14, and 15. This leads back to making modifications to the smart contract at 1714 of FIG. 17A. In some embodiments, these errors may be fixed automatically with approval from the user. If there are no runtime errors, then at 1742, the platform may be configured to continue the development process by proceeding to the security audit stage. The user may perform the security audit by running various kinds of programs, such as slither, echidna or manticore.

[85] At 1744, when running the security audit, the platform may determine if there are any runtime errors. If there are, then the process may go back to 1714 of FIG. 17A to allow for more modifications to respond to any errors. In some embodiments, these errors may be fixed automatically with approval from the user. If there are no errors, then at 1746, the platform may be configured to proceed to the deployment phase. The user can choose to deploy the smart contract on a specific network on any blockchain, blockchain type and the network type can be selected through one or more drop down menus. The deployment of the smart contract represents a completed design of the smart contract without any errors. [86] Referring to FIG. 18, shown is a flowchart 1800 of an example methodology for fixing incompatibility errors between different versions, according to some embodiments. Within the development of the smart contract, the platform may be configured to automatically correct syntax errors where modifications may be made between different versions that bring about syntax changes. Examples include the descriptions consistent with FIGS. 8, 9, 10, and 11 .

[87] At 1802, the platform of the present disclosures may be configured to conduct the auto-fix features described herein during the design phase or the validation phase when the user is building a smart contract. The platform may first be configured to compile the smart contract once the user saves the smart contract and/or instructs to compile the saved version. At 1804, the platform may be configured to attempt to compile the smart contract and generate all of the compiler errors at that time. These may be displayed on or next to the design canvas for the user to see.

[88] At 1806, if the user elects to auto-fix the errors, the platform may be configured to parse the text of each of the compiler errors returned by the compiler (i) to get the keywords by applying the pattern match for that specific kind of compiler error (example - (a) if the compiler error says “.value() is deprecated. Refer to documentation to get the appropriate syntax for 0.8 version of solidity”, we are interested in the first word of the error; (b) if the error says “Syntax error: Please replace usage of a(“”,””) in favor of a{}{}”, we are interested in the 8th word of the error) and (ii) search for an appropriate keyword identified in (i), in a rulebook database. The platform knows which word in the error is the keyword based on the information in a database of all kinds of errors and the occurrence of the appropriate keywords in the error. The rulebook database contains the appropriate fix for each kind of error. It may use pattern recognition that may be aided by machine learning that trains the platform to recognize an array of errors. At 1808, the platform may be configured to search for the parsed error in the rulebook collection for the earliest programming language version changes. The platform may rely on the text of the error and match or find a closest match to errors in the rulebook in order to determine where the parsed error may be in the rulebook database.

[89] At 1810, the platform may determine if, for each error, the error is listed in the earliest programming language version change rulebook database. If so, at 1812, the corresponding fix may be listed in the rulebook database and the platform may be configured to retrieve or fetch the corresponding fix from the rulebook database and assign it to the error. At 1814, the platform may then go to the next programming language version change rulebook database. This process may repeat starting at 1808 for the next programming language version change rulebook database. This process repeats from 1808 to 1810, to 1812, to 1814, to 1808 and back to 1810, until it reaches the final programming language version change rulebook database. This process repeats to ensure that a particular fix from the previous version of a programming language is still valid until the latest version. For example, if version 0.5 has a fix for ,value() to value{}; and if version 0.7 has changed value{} to value[][], and if the user wants to migrate from 0.5 to 0.8, then it is necessary to get the latest fix. However, to ensure that the migration from 0.5 to 0.8 occurs safely and completely, it is necessary to account for each syntax change from one incremental version to the next, until the final version is reached. [90] Below is merely one example of the programming language version change rulebook database. The first set of code represents syntax changes from versions 0.4 to 0.5, while the second set of code represents syntax changes from versions 0.5 to 0.6:

0.4-0.5 :

{

0.5-0.6 :

{ [91] At 1816, if the error is not found in the latest programming language version change rulebook database, then the platform may return a description of the error to the display for the user. At 1818, if the error is returned, the platform may create a clone of the current module which has the error that was not found in the rulebook database. At 1818, the platform may be configured to navigate to the particular line of the code that has identified the unknown or unrecognized compiler error. At 1822, on that particular line of code, the platform may be configured to search for the occurrence of the original error using pattern matching. It then identifies the part of the code that needs to be substituted and saves them in local memory. For example, if ".value("name", "age")" changes to value{"name"}{"age"}, then "name" and "age" have to be substituted after replacing ,values() to value{}{}. It replaces the error with the fix and then substitutes back the required code ("name" and "age" in the above example) in the fix. The platform may repeat this process for each error found during compilation by proceeding back to 1806.

[92] Throughout the disclosure, the terms “a” and “an” may be intended to denote at least one of a particular element. As used herein, the term “includes” means includes but not limited to, the term “including” means including but not limited to. The term “based on” means based at least in part on.

[93] The components of the system environment illustrated in FIGS. 7, 8 and 9 may be connected to one another via a communication network (not illustrated), which may include the Internet, an intranet, a PAN (Personal Area Network), a LAN (Local Area Network), a WAN (Wide Area Network), a SAN (Storage Area Network), a MAN (Metropolitan Area Network), a wireless network, a cellular communications network, a Public Switched Telephone Network, and/or other network through which system environment components may communicate.

[94] The systems and processes are not limited to the specific embodiments described herein. In addition, components of each system and each process can be practiced independent and separate from other components and processes described herein. Each component and process also can be used in combination with other assembly packages and processes. The flow charts and descriptions thereof herein should not be understood to prescribe a fixed order of performing the method blocks described therein. Rather, the method blocks may be performed in any order that is practicable including simultaneous performance of at least some method blocks. Furthermore, each of the methods may be performed by one or more of the system components illustrated in the figures.

[95] Having described aspects of the disclosure in detail, it will be apparent that modifications and variations are possible without departing from the scope of aspects of the disclosure as defined in the appended claims. As various changes could be made in the above constructions, products, and methods without departing from the scope of aspects of the disclosure, it is intended that all matter contained in the above description and shown in the accompanying drawings shall be interpreted as illustrative and not in a limiting sense.

[96] As will be appreciated based on the foregoing specification, the above-described embodiments of the disclosure may be implemented using computer programming or engineering techniques including computer software, firmware, hardware or any combination or subset thereof. Any such resulting program, having computer-readable code means, may be embodied or provided within one or more computer-readable media, thereby making a computer program product, i.e., an article of manufacture, according to the discussed embodiments of the disclosure. Example computer-readable media may be, but are not limited to, a flash memory drive, digital versatile disc (DVD), compact disc (CD), fixed (hard) drive, diskette, optical disk, magnetic tape, semiconductor memory such as read-only memory (ROM), and/or any transmitting/receiving medium such as the Internet or other communication network or link. By way of example and not limitation, computer-readable media comprise computer-readable storage media and communication media. Computer-readable storage media are tangible and non-transitory and store information such as computer-readable instructions, data structures, program modules, and other data. Communication media, in contrast, typically embody computer- readable instructions, data structures, program modules, or other data in a transitory modulated signal such as a carrier wave or other transport mechanism and include any information delivery media. Combinations of any of the above are also included in the scope of computer-readable media. The article of manufacture containing the computer code may be made and/or used by executing the code directly from one medium, by copying the code from one medium to another medium, or by transmitting the code over a network.

[97] This written description uses examples to disclose the embodiments, including the best mode, and also to enable any person skilled in the art to practice the embodiments, including making and using any devices or systems and performing any incorporated methods. The patentable scope of the disclosure is defined by the claims, and may include other examples that occur to those skilled in the art. Such other examples are intended to be within the scope of the claims if they have structural elements that do not differ from the literal language of the claims, or if they include equivalent structural elements with insubstantial differences from the literal language of the claims.

[98] The following clauses provide descriptions for some aspects of the present disclosure:

[99] Clause 1 : A method of a smart contract platform for generating a smart contract using a graphical interface of the smart contract platform, the method comprising: providing, by the platform, the graphical interface to a user; receiving a first input through the graphical interface from the user about a purpose of the smart contract; based on the received first input about the purpose of the smart contract, providing in the graphical interface at least one smart contract template that the user can modify; receiving a second input through the graphical interface from the user to modify the smart contract template; based on the received second input, modifying, by the platform, source code of the smart contract to reflect the modification made by the user in the graphical interface; compiling the source code of the smart contract; after the compiling, testing business logic of the smart contract using one or more test cases; adding security to the smart contract; and deploying the smart contract to at least one blockchain. [100]Clause 2. The method of Clause 1 , wherein the second input from the user comprises one or more inputs to revise a pre-canned function to add or modify logic of the smart contract template.

[101] Clause 3. The method of Clause 1 , wherein the second input from the user comprises one or more inputs to add additional functionality to the smart contract template by including into the graphical interface a pre-canned function.

[102] Clause 4. The method of Clause 1 , wherein the smart contract platform is implemented in a noble programming mantra package.

[103] Clause 5. The method of Clause 1 , further comprising evaluating a performance metric of the smart contract template based on at least one of the following parameters: gas burn rate, relevance to a current requirement, and security rating.

[104] Clause 6. The method of Clause 1 , wherein testing business logic of the smart contract comprises generating functional test cases for the business logic by analyzing the business logic of the smart contract and automatically designing the functional test cases by the smart contract platform.

[105] Clause 7. The method of Clause 6, further comprising receiving a third input to automatically fix any errors generated after running the functional test cases.

[106] Clause 8. The method of Clause 1 , wherein adding security to the smart contract comprises running a security audit of the smart contract by the smart contract platform.

[107] Clause 9. The method of Clause 8, wherein adding security further comprises running a command to automatically fix vulnerabilities discovered by the security audit. [108] Clause 10. The method of Clause 1 , wherein the smart contract platform is implemented in a web interface.

[109] Clause 11 . A method of a smart contract platform for generating a smart contract using a graphical interface of the smart contract platform, the method comprising: providing, by the platform, the graphical interface to a user; receiving a first input through the graphical interface from the user about a purpose of the smart contract; based on the received first input about the purpose of the smart contract, searching through a database of smart contract templates for one or more smart contract templates that satisfies the received first input about the purpose of the smart contract; selecting the one or more smart contract templates that satisfies the received first input about the purpose of the smart contract; causing display in the graphical interface the one or more smart contract templates that satisfies the received first input about the purpose of the smart contract; receiving a second input from the user selecting one of the one or more smart contract templates for use in beginning to generate the smart contract.

[110] Clause 12. A method of automatically fixing syntax errors in a smart contract due to version incompatibility, the method comprising: compiling source code of a smart contract; generating one or more compiling errors during the compilation; for each error of the one or more errors: parsing the error; searching in a database of errors for a root cause of the error; and searching in the database for a fix of the error, based on the root cause of the error; and causing display of the fix to a user of the smart contract.

[111] Clause 13. A method of automatically fixing business logic errors in a smart contract, the method comprising: compiling source code of a smart contract; performing a run time test of the smart contract using a test case; generating one or more errors found during the run time test using the test case; for each error of the one or more errors: parsing the error; searching in a database of errors for a root cause of the error; and searching in the database for a fix of the error, based on the root cause of the error; and causing display of the fix to a user of the smart contract.

[112] Clause 14. A system configured to perform any of the methods in clauses 1 -13.