From b9a30873c14f40a43fe5ec4ab1a8242d93c905ca Mon Sep 17 00:00:00 2001 From: Elias Rad <146735585+nnsW3@users.noreply.github.com> Date: Sun, 10 Dec 2023 22:08:25 +0200 Subject: [PATCH 01/13] fix typos erc-1046.md --- ERCS/erc-1046.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ERCS/erc-1046.md b/ERCS/erc-1046.md index 82907d56cbe..5de793fe5ad 100644 --- a/ERCS/erc-1046.md +++ b/ERCS/erc-1046.md @@ -97,7 +97,7 @@ The resolved JSON of the `tokenURI` described in the ERC-20 Interface Extension */ interface ERC20TokenMetadata { /** - * Interoperabiliy, to differentiate between different types of tokens and their corresponding URIs. + * Interoperability, to differentiate between different types of tokens and their corresponding URIs. **/ interop: InteroperabilityMetadata; @@ -157,7 +157,7 @@ Contracts that implement ERC-721 and use its token metadata URI SHOULD to use th ```typescript interface ERC721TokenMetadataInterop extends ERC721TokenMetadata { /** - * Interoperabiliy, to avoid confusion between different token URIs + * Interoperability, to avoid confusion between different token URIs **/ interop: InteroperabilityMetadata; } From 1f589453d7c8d778446b21d686156354b17fa136 Mon Sep 17 00:00:00 2001 From: Elias Rad <146735585+nnsW3@users.noreply.github.com> Date: Sun, 10 Dec 2023 22:11:08 +0200 Subject: [PATCH 02/13] fix typos erc-1062.md --- ERCS/erc-1062.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ERCS/erc-1062.md b/ERCS/erc-1062.md index 0f304b6cb2c..b84af6517cd 100644 --- a/ERCS/erc-1062.md +++ b/ERCS/erc-1062.md @@ -74,7 +74,7 @@ export const toBase58 = function(contentHash) { ``` ## Implementation -The use case can be implemented as browser extension. Users can easily download the extension, and easily get decentralized resources by just typing the ENS just like we normally type the DNS to browser the website. Solve the current pain for normal people can not easily visit the total decentralized website. +The use case can be implemented as browser extension. Users can easily download the extension, and easily get decentralized resources by just typing the ENS just like we normally type the DNS to browser the website. Solve the current pain for normal people who can not easily visit the total decentralized website. The workable implementation repository : [https://github.com/PortalNetwork/portal-network-browser-extension](https://github.com/PortalNetwork/portal-network-browser-extension) From b5dccad2911805b47ac4a0298ee17d2a89f52cb5 Mon Sep 17 00:00:00 2001 From: Elias Rad <146735585+nnsW3@users.noreply.github.com> Date: Sun, 10 Dec 2023 22:16:05 +0200 Subject: [PATCH 03/13] fix typos erc-1078.md --- ERCS/erc-1078.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ERCS/erc-1078.md b/ERCS/erc-1078.md index 7990475fbcd..4aabbb72cfb 100644 --- a/ERCS/erc-1078.md +++ b/ERCS/erc-1078.md @@ -43,7 +43,7 @@ If the user doesn’t have an identity, the app should provide the option to cre All those steps can be designed to be set up in a single ethereum transaction. Since this step is not free, the app reserves the right to charge for registering users, or require the user to be verified in a sybil resistant manner of the app’s choosing (captcha, device ID registration, proof of work, etc) -The user shouldn’t be forced to wait for transaction confirmation times. Instead, have an indicator somewhere on the app the shows the progress and then allow the user to interact with your app normally. It’s unlikely that they’ll need the identity in the first few minutes and if something goes wrong (username gets registered at the same time), you can then ask the user for an action. +The user shouldn’t be forced to wait for transaction confirmation times. Instead, have an indicator somewhere on the app that shows the progress and then allow the user to interact with your app normally. It’s unlikely that they’ll need the identity in the first few minutes and if something goes wrong (username gets registered at the same time), you can then ask the user for an action. **Implementation note:** in order to save gas, some of these steps can be done in advance. The app can automatically deploy a small number of contracts when the gas price is low, and set up all their main variables to be 0xFFFFFF...FFFFF. These should be considered ‘vacant’ and when the user registers one, they will get a gas discount for freeing up space on the chain. This has the added benefit of allowing the user a choice in contract address/icon. From 612848a690d879ab241d5e7b5439220216014db9 Mon Sep 17 00:00:00 2001 From: Elias Rad <146735585+nnsW3@users.noreply.github.com> Date: Sun, 10 Dec 2023 22:17:47 +0200 Subject: [PATCH 04/13] fix typos erc-1081.md --- ERCS/erc-1081.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ERCS/erc-1081.md b/ERCS/erc-1081.md index f73b2c70114..bbb330361f8 100644 --- a/ERCS/erc-1081.md +++ b/ERCS/erc-1081.md @@ -28,7 +28,7 @@ After studying bounties as they've existed for thousands of years (and after imp To implement these steps, a number of functions are needed: - `initializeBounty(address _issuer, address _arbiter, string _data, uint _deadline)`: This is used when deploying a new StandardBounty contract, and is particularly useful when applying the proxy design pattern, whereby bounties cannot be initialized in their constructors. Here, the data string should represent an IPFS hash, corresponding to a JSON object which conforms to the schema (described below). - `fulfillBounty(address[] _fulfillers, uint[] _numerators, uint _denomenator, string _data)`: This is called to submit a fulfillment, submitting a string representing an IPFS hash which contains the deliverable for the bounty. Initially fulfillments could only be submitted by one individual at a time, however users consistently told us they desired to be able to collaborate on fulfillments, thereby allowing the credit for submissions to be shared by several parties. The lines along which eventual payouts are split are determined by the fractions of the submission credited to each fulfiller (using the array of numerators and single denominator). Here, a bounty platform may also include themselves as a collaborator to collect a small fee for matching the bounty with fulfillers. -- `acceptFulfillment(uint _fulfillmentId, StandardToken[] _payoutTokens, uint[] _tokenAmounts)`: This is called by the `issuer` or the `arbiter` to pay out a given fulfillment, using an array of tokens, and an array of amounts of each token to be split among the contributors. This allows for the bounty payout amount to move as it needs to based on incoming contributions (which may be transferred directly to the contract address). It also allows for the easy splitting of a given bounty's balance among several fulfillments, if the need should arise. +- `acceptFulfillment(uint _fulfillmentId, StandardToken[] _payoutTokens, uint[] _tokenAmounts)`: This is called by the `issuer` or the `arbiter` to pay out a given fulfillment, using an array of tokens, and an array of amounts of each token to be split among the contributors. This allows for the bounty payout amount to move as it needs to be based on incoming contributions (which may be transferred directly to the contract address). It also allows for the easy splitting of a given bounty's balance among several fulfillments, if the need should arise. - `drainBounty(StandardToken[] _payoutTokens)`: This may be called by the `issuer` to drain a bounty of it's funds, if the need should arise. - `changeBounty(address _issuer, address _arbiter, string _data, uint _deadline)`: This may be called by the `issuer` to change the `issuer`, `arbiter`, `data`, and `deadline` fields of their bounty. - `changeIssuer(address _issuer)`: This may be called by the `issuer` to change to a new `issuer` if need be From ce4ee5690aee82633fab5c1cb7055e8ece631661 Mon Sep 17 00:00:00 2001 From: Elias Rad <146735585+nnsW3@users.noreply.github.com> Date: Sun, 10 Dec 2023 22:21:48 +0200 Subject: [PATCH 05/13] fix typos erc-1123.md --- ERCS/erc-1123.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ERCS/erc-1123.md b/ERCS/erc-1123.md index 06ca527c46d..77e3ef10699 100644 --- a/ERCS/erc-1123.md +++ b/ERCS/erc-1123.md @@ -1593,7 +1593,7 @@ A URI in the format `blockchain:///block/` - `block_hash` is the unprefixed hexadecimal representation of the hash of a block on the chain. -A chain is considered to match a chain definition if the the genesis +A chain is considered to match a chain definition if the genesis block hash matches the `chain_id` and the block defined by `block_hash` can be found on that chain. It is possible for multiple chains to match a single URI, in which case all chains are considered valid matches From 5b71474ff49a80c0e88abaa05ccd6b0b04ff9671 Mon Sep 17 00:00:00 2001 From: Elias Rad <146735585+nnsW3@users.noreply.github.com> Date: Sun, 10 Dec 2023 22:23:32 +0200 Subject: [PATCH 06/13] fix typos erc-1129.md --- ERCS/erc-1129.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ERCS/erc-1129.md b/ERCS/erc-1129.md index ca6acdcd754..b4ccaa98ef5 100644 --- a/ERCS/erc-1129.md +++ b/ERCS/erc-1129.md @@ -49,7 +49,7 @@ struct Announcement{ ### Methods -#### the number of ammouncements +#### the number of announcements Returns the number of announcement currently active. @@ -80,7 +80,7 @@ function givePostingPermission(address _newAnnouncer, bool _postingPrivileges, s #### can post -Checks if the entity that wants to post an announcement has the posting privilieges. +Checks if the entity that wants to post an announcement has the posting privileges. ``` js modifier canPost{ From 222c59f1b3c4c8d6974e2c5318c3f2da0323319f Mon Sep 17 00:00:00 2001 From: Elias Rad <146735585+nnsW3@users.noreply.github.com> Date: Sun, 10 Dec 2023 22:24:28 +0200 Subject: [PATCH 07/13] fix typos erc-1132.md --- ERCS/erc-1132.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ERCS/erc-1132.md b/ERCS/erc-1132.md index 373a0dd4c3f..0a6a3880733 100644 --- a/ERCS/erc-1132.md +++ b/ERCS/erc-1132.md @@ -111,7 +111,7 @@ function totalBalanceOf(address _of) view returns (uint256 amount) ```solidity /** * @dev Returns unlockable tokens for a specified address for a specified reason - * @param _of The address to query the the unlockable token count of + * @param _of The address to query the unlockable token count of * @param _reason The reason to query the unlockable tokens for */ function tokensUnlockable(address _of, bytes32 _reason) public view returns (uint256 amount) @@ -120,7 +120,7 @@ function totalBalanceOf(address _of) view returns (uint256 amount) ```solidity /** * @dev Gets the unlockable tokens of a specified address - * @param _of The address to query the the unlockable token count of + * @param _of The address to query the unlockable token count of */ function getUnlockableTokens(address _of) public view returns (uint256 unlockableTokens) ``` From 0170304887f43197c0b731de50ae2cc2274b7911 Mon Sep 17 00:00:00 2001 From: Elias Rad <146735585+nnsW3@users.noreply.github.com> Date: Sun, 10 Dec 2023 22:31:05 +0200 Subject: [PATCH 08/13] fix typos erc-1178.md --- ERCS/erc-1178.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ERCS/erc-1178.md b/ERCS/erc-1178.md index 06a740ce42c..03accc01850 100644 --- a/ERCS/erc-1178.md +++ b/ERCS/erc-1178.md @@ -45,7 +45,7 @@ Returns the name of the class of MCFT managed by this contract. - e.g. `"My Comp function symbol() constant returns (string symbol) ``` -*OPTIONAL - It is recommend that this method is implemented for enhanced usability with wallets and exchanges, but interfaces and other contracts MUST NOT depend on the existence of this method.* +*OPTIONAL - It is recommended that this method is implemented for enhanced usability with wallets and exchanges, but interfaces and other contracts MUST NOT depend on the existence of this method.* Returns a short string symbol referencing the entire collection of MCFT managed in this contract. e.g. "MUL". This symbol SHOULD be short (3-8 characters is recommended), with no whitespace characters or new-lines and SHOULD be limited to the uppercase latin alphabet (i.e. the 26 letters used in English). From b5b7f23e88e724dbebdc8b6c0a2cc13bf4b45aea Mon Sep 17 00:00:00 2001 From: Elias Rad <146735585+nnsW3@users.noreply.github.com> Date: Sun, 10 Dec 2023 22:32:31 +0200 Subject: [PATCH 09/13] fix typos erc-1185.md --- ERCS/erc-1185.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ERCS/erc-1185.md b/ERCS/erc-1185.md index 77964d90c4e..6dcee14cde8 100644 --- a/ERCS/erc-1185.md +++ b/ERCS/erc-1185.md @@ -265,7 +265,7 @@ abstract contract DNSResolver is ResolverBase { ## Security Considerations -Security of this solution would be dependent on security of the records within the ENS domain. This degenenrates to the security of the key(s) which have authority over that domain. +Security of this solution would be dependent on security of the records within the ENS domain. This degenerates to the security of the key(s) which have authority over that domain. ## Copyright From 00ca27a2019828786debd5e04e9c1c76f43a02b7 Mon Sep 17 00:00:00 2001 From: Elias Rad <146735585+nnsW3@users.noreply.github.com> Date: Sun, 10 Dec 2023 22:33:08 +0200 Subject: [PATCH 10/13] fix typos erc-1191.md --- ERCS/erc-1191.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ERCS/erc-1191.md b/ERCS/erc-1191.md index 55a744f9fb0..0f83d1aad43 100644 --- a/ERCS/erc-1191.md +++ b/ERCS/erc-1191.md @@ -17,7 +17,7 @@ This EIP extends [EIP-55](./eip-55.md) by optionally adding a chain id defined b ## Abstract -The [EIP-55](./eip-55.md) was created to prevent users from losing funds by sending them to invalid addresses. This EIP extends [EIP-55](./eip-55.md) to protect users from losing funds by sending them to addresses that are valid but that where obtained from a client of another network.For example, if this EIP is implemented, a wallet can alert the user that is trying to send funds to an Ethereum Testnet address from an Ethereum Mainnet wallet. +The [EIP-55](./eip-55.md) was created to prevent users from losing funds by sending them to invalid addresses. This EIP extends [EIP-55](./eip-55.md) to protect users from losing funds by sending them to addresses that are valid but that were obtained from a client of another network.For example, if this EIP is implemented, a wallet can alert the user that is trying to send funds to an Ethereum Testnet address from an Ethereum Mainnet wallet. ## Motivation From 8be724d66ec0671ee150098b9cc79ab5c4a0659b Mon Sep 17 00:00:00 2001 From: Elias Rad <146735585+nnsW3@users.noreply.github.com> Date: Sun, 10 Dec 2023 22:35:52 +0200 Subject: [PATCH 11/13] fix typos erc-1207.md --- ERCS/erc-1207.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ERCS/erc-1207.md b/ERCS/erc-1207.md index 9b9fb0ca34b..db3c2018060 100644 --- a/ERCS/erc-1207.md +++ b/ERCS/erc-1207.md @@ -144,7 +144,7 @@ function _approve(address sender, address _spender, uint256 _value) internal ret **Current Limitations** -The current design of many smart contracts only considers the user invokes the smart contract functions by themselves using the private key. However, in some case, the user wants to delegate other client smart contracts to access and operate their data or assets in the resource smart contract. There isn’t a common protocol to provide a standard delegation approach. +The current design of many smart contracts only considers the user invokes the smart contract functions by themselves using the private key. However, in some cases, the user wants to delegate other client smart contracts to access and operate their data or assets in the resource smart contract. There isn’t a common protocol to provide a standard delegation approach. **Rationale** From 2582fe1cbe65595330b781e1c7667d733a6a2121 Mon Sep 17 00:00:00 2001 From: Elias Rad <146735585+nnsW3@users.noreply.github.com> Date: Sun, 10 Dec 2023 22:38:14 +0200 Subject: [PATCH 12/13] fix typos erc-1261.md --- ERCS/erc-1261.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ERCS/erc-1261.md b/ERCS/erc-1261.md index e2bf12a7cd9..9870b749284 100644 --- a/ERCS/erc-1261.md +++ b/ERCS/erc-1261.md @@ -23,7 +23,7 @@ We considered use cases of MVTs being assigned to individuals which are non-tran - Voting: Voting is inherently supposed to be a permissioned activity. So far, onchain voting systems are only able to carry out voting with coin balance based polls. This can now change and take various shapes and forms. - Passport issuance, social benefit distribution, Travel permit issuance, Drivers licence issuance are all applications which can be abstracted into membership, that is belonging of an individual to a small set, recognized by some authority as having certain entitlements, without needing any individual specific information(right to welfare, freedom of movement, authorization to operate vehicles, immigration) - Investor permissioning: Making regulatory compliance a simple on chain process. Tokenization of securities, that are streamlined to flow only to accredited addresses, tracing and certifying on chain addresses for AML purposes. -- Software licencing: Software companies like game developers can use the protocol to authorize certain hardware units(consoles) to download and use specific software(games) +- Software licensing: Software companies like game developers can use the protocol to authorize certain hardware units(consoles) to download and use specific software(games) In general, an individual can have different memberships in their day to day life. The protocol allows for the creation of software that puts everything all at one place. Their identity can be verified instantly. Imagine a world where you don't need to carry a wallet full of identity cards (Passport, gym membership, SSN, Company ID etc) and organizations can easily keep track of all its members. Organizations can easily identify and disallow fake identities. @@ -53,7 +53,7 @@ Imagine that SafeEmploy™, a background checking company, issues a claim about **Trade-off between trustlessness and usability:** To truly understand the value of the protocol, it is important to understand the trade-off we are treading on. The MVT contract allows the creator to revoke the token, and essentially confiscate the membership of the member in question. To some, this might seem like an unacceptable flaw, however this is a design choice, and not a flaw. -The choice may seem to place a great amount of trust in the individuals who are managing the entity contract(entity owners). If the interests of the entity owner conflict with the interests of the members, the owner may resort to addition of fake addresses(to dominate consensus) or evicting members(to censor unfavourable decisions). At first glance this appears to be a major shortcomings, because the blockchain space is used to absolute removal of authority in most cases. Even the official definition of a dapp requires the absence of any party that manages the services provided by the application. However, the trust in entity owners is not misplaced, if it can be ensured that the interests of entity owners are aligned with the interests of members. +The choice may seem to place a great amount of trust in the individuals who are managing the entity contract(entity owners). If the interests of the entity owner conflict with the interests of the members, the owner may resort to addition of fake addresses(to dominate consensus) or evicting members(to censor unfavorable decisions). At first glance this appears to be a major shortcomings, because the blockchain space is used to absolute removal of authority in most cases. Even the official definition of a dapp requires the absence of any party that manages the services provided by the application. However, the trust in entity owners is not misplaced, if it can be ensured that the interests of entity owners are aligned with the interests of members. Another criticism of such a system would be that the standard edge of blockchain intermediation - “you cannot bribe the system if you don’t know who to bribe” - no longer holds. It is possible to bribe an entity owner into submission, and get them to censor or fake votes. There are several ways to respond to this argument. First of all, all activities, such as addition of members, and removal of members can be tracked on the blockchain and traces of such activity cannot be removed. It is not difficult to build analytics tools to detect malicious activity(adding 100 fake members suddenly who vote in the direction/sudden removal of a number of members voting in a certain direction). Secondly, the entity owners’ power is limited to the addition and removal of members. This means that they cannot tamper any votes. They can only alter the counting system to include fake voters or remove real voters. Any sensible auditor can identify the malicious/victim addresses and create an open source audit tool to find out the correct results. The biggest loser in this attack will be the entity owner, who has a reputation to lose. Finally, one must understand why we are taking a step away from trustlessness in this trade-off. The answer is usability. Introducing a permissioning system expands the scope of products and services that can be delivered through the blockchain, while leveraging other aspects of the blockchain(cheap, immutable, no red-tape, secure). Consider the example of the driver licence issuing agency using the ERC-1300 standard. This is a service that simply cannot be deployed in a completely trustless environment. The introduction of permissioned systems expanded the scope of services on the blockchain to cover this particular service. Sure, they have the power to revoke a person’s licence for no reason. But will they? Who stands to lose the most, if the agency acts erratically? The agency itself. Now consider the alternative, the way licences(not necessarily only drivers licence, but say shareholder certificates and so on) are issued, the amount of time consumed, the complete lack of transparency. One could argue that if the legacy systems providing these services really wanted to carry out corruption and nepotism in the execution of these services, the present systems make it much easier to do so. Also, they are not transparent, meaning that there is no way to even detect if they act maliciously. All that being said, we are very excited to share our proposal with the community and open up to suggestions in this space. From f95ae172d9eba60845ac43f11b64697e63d5067a Mon Sep 17 00:00:00 2001 From: Sam Wilson <57262657+SamWilsn@users.noreply.github.com> Date: Wed, 13 Dec 2023 11:34:31 -0500 Subject: [PATCH 13/13] Update ERCS/erc-1261.md --- ERCS/erc-1261.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ERCS/erc-1261.md b/ERCS/erc-1261.md index 9870b749284..8615a3aaa8a 100644 --- a/ERCS/erc-1261.md +++ b/ERCS/erc-1261.md @@ -53,7 +53,7 @@ Imagine that SafeEmploy™, a background checking company, issues a claim about **Trade-off between trustlessness and usability:** To truly understand the value of the protocol, it is important to understand the trade-off we are treading on. The MVT contract allows the creator to revoke the token, and essentially confiscate the membership of the member in question. To some, this might seem like an unacceptable flaw, however this is a design choice, and not a flaw. -The choice may seem to place a great amount of trust in the individuals who are managing the entity contract(entity owners). If the interests of the entity owner conflict with the interests of the members, the owner may resort to addition of fake addresses(to dominate consensus) or evicting members(to censor unfavorable decisions). At first glance this appears to be a major shortcomings, because the blockchain space is used to absolute removal of authority in most cases. Even the official definition of a dapp requires the absence of any party that manages the services provided by the application. However, the trust in entity owners is not misplaced, if it can be ensured that the interests of entity owners are aligned with the interests of members. +The choice may seem to place a great amount of trust in the individuals who are managing the entity contract(entity owners). If the interests of the entity owner conflict with the interests of the members, the owner may resort to addition of fake addresses(to dominate consensus) or evicting members(to censor unfavourable decisions). At first glance this appears to be a major shortcomings, because the blockchain space is used to absolute removal of authority in most cases. Even the official definition of a dapp requires the absence of any party that manages the services provided by the application. However, the trust in entity owners is not misplaced, if it can be ensured that the interests of entity owners are aligned with the interests of members. Another criticism of such a system would be that the standard edge of blockchain intermediation - “you cannot bribe the system if you don’t know who to bribe” - no longer holds. It is possible to bribe an entity owner into submission, and get them to censor or fake votes. There are several ways to respond to this argument. First of all, all activities, such as addition of members, and removal of members can be tracked on the blockchain and traces of such activity cannot be removed. It is not difficult to build analytics tools to detect malicious activity(adding 100 fake members suddenly who vote in the direction/sudden removal of a number of members voting in a certain direction). Secondly, the entity owners’ power is limited to the addition and removal of members. This means that they cannot tamper any votes. They can only alter the counting system to include fake voters or remove real voters. Any sensible auditor can identify the malicious/victim addresses and create an open source audit tool to find out the correct results. The biggest loser in this attack will be the entity owner, who has a reputation to lose. Finally, one must understand why we are taking a step away from trustlessness in this trade-off. The answer is usability. Introducing a permissioning system expands the scope of products and services that can be delivered through the blockchain, while leveraging other aspects of the blockchain(cheap, immutable, no red-tape, secure). Consider the example of the driver licence issuing agency using the ERC-1300 standard. This is a service that simply cannot be deployed in a completely trustless environment. The introduction of permissioned systems expanded the scope of services on the blockchain to cover this particular service. Sure, they have the power to revoke a person’s licence for no reason. But will they? Who stands to lose the most, if the agency acts erratically? The agency itself. Now consider the alternative, the way licences(not necessarily only drivers licence, but say shareholder certificates and so on) are issued, the amount of time consumed, the complete lack of transparency. One could argue that if the legacy systems providing these services really wanted to carry out corruption and nepotism in the execution of these services, the present systems make it much easier to do so. Also, they are not transparent, meaning that there is no way to even detect if they act maliciously. All that being said, we are very excited to share our proposal with the community and open up to suggestions in this space.