From 69be9e05e0b4a735d85647a5709c73dedc2ba29d Mon Sep 17 00:00:00 2001 From: lukelee-sl Date: Sun, 25 Feb 2024 21:23:44 -0800 Subject: [PATCH 01/19] initial draft Signed-off-by: lukelee-sl --- hip-0000-template.md | 116 +++++++++++++++++++++++++++++++------------ 1 file changed, 83 insertions(+), 33 deletions(-) diff --git a/hip-0000-template.md b/hip-0000-template.md index 0237d2b5d..beb4bf440 100644 --- a/hip-0000-template.md +++ b/hip-0000-template.md @@ -1,72 +1,122 @@ --- hip: -title: -author: -working-group: a list of the technical and business stakeholders' name(s) and/or username(s), or name(s) and email(s). -requested-by: the name(s) and/or username(s), or name(s) and email(s) of the individual(s) or project(s) requesting the HIP -type: -category: -needs-council-approval: +title: Proxy Redirect Contract for Hbar Allowance and Approval +author: Luke Lee <@lukelee-sl> +working-group: Nana Essilfie-Conduah <@nana-ec> +type: Standards Track +category: Service +needs-council-approval: Yes status: -created: +created: 2024-02-23 discussions-to: -updated: -requires: -replaces: -superseded-by: +updated: +requires: 632 --- ## Abstract -Please provide a short (~200 word) description of the issue being addressed. +The Smart Contract service provides for functionality to grant allowance and approve for tokens from the owner account to a spender account. +However, currently there is no functionality to grant allowance and approve for hbars from an owner account via the Smart Contract service. +This HIP proposes to remedy this omission. ## Motivation -The motivation is critical for HIPs that want to change the Hedera codebase or ecosystem. It should clearly explain why the existing specification is inadequate to address the problem that the HIP solves. HIP submissions without sufficient motivation may be rejected outright. +Smart Contracts developers have obstructions on implementing certain potential use cases for transferring hbar between accounts because there is no way to grant allowance and approve for them from an owner account without using HAPI. +Providing this functionality will remove these obstructions for developers and provide for a better developer experience. ## Rationale -The rationale fleshes out the specification by describing why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. - -The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during the discussion. +This HIP proposes to add the needed functionality via a new interface `IHRC632` which will act on an account address. The account will be the actor in view with respect to the allowance to the `spender` account for the specified amount. +An alternative approach would be to introduce a new interface which a contract can implement. This would necessitate that a contract be deployed which may always be desired. In addition, taking this approach would potentially require violating the +smart contracts security model as the sender of the frame when executing the system contract would be the deployed contract and not the EOA which would not be desire in most cases. ## User stories -Provide a list of "user stories" to express how this feature, functionality, improvement, or tool will be used by the end user. Template for user story: “As (user persona), I want (to perform this action) so that (I can accomplish this goal).” - +1. As a smart contract developer, I want to be able to grant approve an allowance for hbars from an EOA to a spender account or contract. +2. As a smart contract developer, I want to be able to grant approve an allowance for hbars from a contract to a spender account or contract. +3. As a smart contract developer, I want to be able to get the allowance of hbars from an owner account to a spender account or contract. + ## Specification -The technical specification should describe the syntax and semantics of any new features. The specification should be detailed enough to allow competing, interoperable implementations for at least the current Hedera ecosystem. +HIP-632 proposes an introduction of a new system contract for accessing Hedera account functionality (Hedera Account Service - HAS). +This HIP extends the new system contract to another related interface `IHRC632` to support the `hbarAllowance` and `hbarApprove` functions. +The `hbarAllowance` function will be used to retrieve information about allowance granted to a spender and the `hbarApprove` function will allow the sender to grant to the `spender` an allowance of hbars. + + +Similar to the way redirection to a proxy contract during EVM execution for tokens works [see HIP-719](https://github.com/hashgraph/hedera-improvement-proposal/blob/main/HIP/hip-719.md), +this HIP proposes to introduce a new proxy contract for accounts. During EVM execution, if the target of the current frame is an account, a call to a proxy contract will be created and the current calldata will be injected into +the proxy contract for processing by the Hedera Account Service system contract. + +The bytecode for the proxy contract can be created by compiling the following contract: + +```solidity +// SPDX-License-Identifier: Apache-2.0 +pragma solidity ^0.8.0; +contract Assembly { + fallback() external { + address precompileAddress = address(0x167); + assembly { + mstore(0, 0xFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFE) + calldatacopy(32, 0, calldatasize()) + let result := delegatecall(gas(), precompileAddress, 8, add(24, calldatasize()), 0, 0) + let size := returndatasize() + returndatacopy(0, 0, size) + switch result + case 0 { revert(0, size) } + default { return(0, size) } + } + } +} +``` + +The following table describes the function selector for the new `hbarAllownace` and `hbarApprove` functions and the associated function signature and response. + +| Function Selector Hash | Function Signature | Response | +|------------------------|---------------------------------------------|---------------------------------------------------------------------------| +| 0xbbee989e | hbarAllowance(address spender) | (ResponseCode, int256 - amount of hbar allowances granted to the spender) | +| 0x86aff07c | hbarApprove(spender address, amount int256) | ResponseCode | + +The solidity interface for IHRC632 will be the following + +``` +interface IHRC632 { + function hbarAllowance(address spender) external returns (responseCode, int256); + function hbarApprove(spender address, amount int256) external returns (responseCode); +} +``` + +Once the above functionality has been implemented in services, an EOA will be able to call the `hbarAllownace` and `hbarApprove` functions as follows: + +``` +IHRC(accountAddress).hbarAllowance(address spender) +IHRC(accountAddress).hbarApprove(spender address, amount int256) +``` + ## Backwards Compatibility -All HIPs that introduce backward incompatibilities must include a section describing these incompatibilities and their severity. The HIP must explain how the author proposes to deal with these incompatibilities. HIP submissions without a sufficient backward compatibility treatise may be rejected outright. +As this is new functionality there is no concern for backwards compatibility. ## Security Implications -If there are security concerns in relation to the HIP, those concerns should be explicitly addressed to make sure reviewers of the HIP are aware of them. +Granting an allowance to a spender account or contract opens up the owner to possible unwanted loss of hbars and thus security considerations must be paramount +when implementing this functionality. Thorough testing will be required to ensure that only the intended spender account or contract can spend the owners hbars. ## How to Teach This -For a HIP that adds new functionality or changes interface behaviors, it is helpful to include a section on how to teach users, new and experienced, how to apply the HIP to their work. - -## Reference Implementation - -The reference implementation must be complete before any HIP is given the status of “Final”. The final implementation must include test code and documentation. +The `hbarAllowance` and `hbarApprove` functions can be accessed by an EOA or a contract by calling the `IHRC` interface as described above. This enhances the functionality and use cases +available to the smart contract developer. ## Rejected Ideas -Throughout the discussion of a HIP, various ideas will be proposed which are not accepted. Those rejected ideas should be recorded along with the reasoning as to why they were rejected. This both helps record the thought process behind the final version of the HIP as well as preventing people from bringing up the same rejected idea again in subsequent discussions. - -In a way, this section can be thought of as a breakout section of the Rationale section that focuses specifically on why certain ideas were not ultimately pursued. +The idea of introducing this functionality to the IHederaAccountService interface directly was discarded as this would require that a contract be deployed which may not always be desired. Due to security considerations, doing so would make the functionality less than useful. ## Open Issues -While a HIP is in draft, ideas can come up which warrant further discussion. Those ideas should be recorded so people know that they are being thought about but do not have a concrete resolution. This helps make sure all issues required for the HIP to be ready for consideration are complete and reduces people duplicating prior discussions. - ## References -A collections of URLs used as references through the HIP. +[HIP-632](https://github.com/hashgraph/hedera-improvement-proposal/blob/main/HIP/hip-632.md) +[HIP-719](https://github.com/hashgraph/hedera-improvement-proposal/blob/main/HIP/hip-719.md) ## Copyright/license From ae6c00f66e367ccef82ad83f310489eec598a799 Mon Sep 17 00:00:00 2001 From: lukelee-sl Date: Mon, 26 Feb 2024 09:09:23 -0800 Subject: [PATCH 02/19] fix header issues Signed-off-by: lukelee-sl --- hip-0000-template.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/hip-0000-template.md b/hip-0000-template.md index beb4bf440..518c2b962 100644 --- a/hip-0000-template.md +++ b/hip-0000-template.md @@ -1,14 +1,15 @@ --- -hip: +hip: 000 title: Proxy Redirect Contract for Hbar Allowance and Approval author: Luke Lee <@lukelee-sl> working-group: Nana Essilfie-Conduah <@nana-ec> +requested-by: Smart contract developers type: Standards Track category: Service needs-council-approval: Yes -status: +status: Review created: 2024-02-23 -discussions-to: +discussions-to: https://github.com/hashgraph/hedera-improvement-proposal/discussions/906 updated: requires: 632 --- From 6ecb7f7bbf99087e98a815bfdd0e7bfdb513f66f Mon Sep 17 00:00:00 2001 From: lukelee-sl Date: Mon, 26 Feb 2024 09:10:53 -0800 Subject: [PATCH 03/19] set updated date Signed-off-by: lukelee-sl --- hip-0000-template.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hip-0000-template.md b/hip-0000-template.md index 518c2b962..154c607ac 100644 --- a/hip-0000-template.md +++ b/hip-0000-template.md @@ -10,7 +10,7 @@ needs-council-approval: Yes status: Review created: 2024-02-23 discussions-to: https://github.com/hashgraph/hedera-improvement-proposal/discussions/906 -updated: +updated: 2023-02-26 requires: 632 --- From 11cc6dc6f5c79880df0740ca20a308199dc054b8 Mon Sep 17 00:00:00 2001 From: lukelee-sl Date: Tue, 5 Mar 2024 10:33:39 -0800 Subject: [PATCH 04/19] move new hip file to HIP folder Signed-off-by: lukelee-sl --- HIP/hip-0000-template.md | 124 +++++++++++++++++++++++++++++++++++++++ hip-0000-template.md | 123 ++++++++++++-------------------------- 2 files changed, 160 insertions(+), 87 deletions(-) create mode 100644 HIP/hip-0000-template.md diff --git a/HIP/hip-0000-template.md b/HIP/hip-0000-template.md new file mode 100644 index 000000000..154c607ac --- /dev/null +++ b/HIP/hip-0000-template.md @@ -0,0 +1,124 @@ +--- +hip: 000 +title: Proxy Redirect Contract for Hbar Allowance and Approval +author: Luke Lee <@lukelee-sl> +working-group: Nana Essilfie-Conduah <@nana-ec> +requested-by: Smart contract developers +type: Standards Track +category: Service +needs-council-approval: Yes +status: Review +created: 2024-02-23 +discussions-to: https://github.com/hashgraph/hedera-improvement-proposal/discussions/906 +updated: 2023-02-26 +requires: 632 +--- + +## Abstract + +The Smart Contract service provides for functionality to grant allowance and approve for tokens from the owner account to a spender account. +However, currently there is no functionality to grant allowance and approve for hbars from an owner account via the Smart Contract service. +This HIP proposes to remedy this omission. + +## Motivation + +Smart Contracts developers have obstructions on implementing certain potential use cases for transferring hbar between accounts because there is no way to grant allowance and approve for them from an owner account without using HAPI. +Providing this functionality will remove these obstructions for developers and provide for a better developer experience. + +## Rationale + +This HIP proposes to add the needed functionality via a new interface `IHRC632` which will act on an account address. The account will be the actor in view with respect to the allowance to the `spender` account for the specified amount. +An alternative approach would be to introduce a new interface which a contract can implement. This would necessitate that a contract be deployed which may always be desired. In addition, taking this approach would potentially require violating the +smart contracts security model as the sender of the frame when executing the system contract would be the deployed contract and not the EOA which would not be desire in most cases. + +## User stories + +1. As a smart contract developer, I want to be able to grant approve an allowance for hbars from an EOA to a spender account or contract. +2. As a smart contract developer, I want to be able to grant approve an allowance for hbars from a contract to a spender account or contract. +3. As a smart contract developer, I want to be able to get the allowance of hbars from an owner account to a spender account or contract. + +## Specification + +HIP-632 proposes an introduction of a new system contract for accessing Hedera account functionality (Hedera Account Service - HAS). +This HIP extends the new system contract to another related interface `IHRC632` to support the `hbarAllowance` and `hbarApprove` functions. +The `hbarAllowance` function will be used to retrieve information about allowance granted to a spender and the `hbarApprove` function will allow the sender to grant to the `spender` an allowance of hbars. + + +Similar to the way redirection to a proxy contract during EVM execution for tokens works [see HIP-719](https://github.com/hashgraph/hedera-improvement-proposal/blob/main/HIP/hip-719.md), +this HIP proposes to introduce a new proxy contract for accounts. During EVM execution, if the target of the current frame is an account, a call to a proxy contract will be created and the current calldata will be injected into +the proxy contract for processing by the Hedera Account Service system contract. + +The bytecode for the proxy contract can be created by compiling the following contract: + +```solidity +// SPDX-License-Identifier: Apache-2.0 +pragma solidity ^0.8.0; +contract Assembly { + fallback() external { + address precompileAddress = address(0x167); + assembly { + mstore(0, 0xFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFE) + calldatacopy(32, 0, calldatasize()) + let result := delegatecall(gas(), precompileAddress, 8, add(24, calldatasize()), 0, 0) + let size := returndatasize() + returndatacopy(0, 0, size) + switch result + case 0 { revert(0, size) } + default { return(0, size) } + } + } +} +``` + +The following table describes the function selector for the new `hbarAllownace` and `hbarApprove` functions and the associated function signature and response. + +| Function Selector Hash | Function Signature | Response | +|------------------------|---------------------------------------------|---------------------------------------------------------------------------| +| 0xbbee989e | hbarAllowance(address spender) | (ResponseCode, int256 - amount of hbar allowances granted to the spender) | +| 0x86aff07c | hbarApprove(spender address, amount int256) | ResponseCode | + +The solidity interface for IHRC632 will be the following + +``` +interface IHRC632 { + function hbarAllowance(address spender) external returns (responseCode, int256); + function hbarApprove(spender address, amount int256) external returns (responseCode); +} +``` + +Once the above functionality has been implemented in services, an EOA will be able to call the `hbarAllownace` and `hbarApprove` functions as follows: + +``` +IHRC(accountAddress).hbarAllowance(address spender) +IHRC(accountAddress).hbarApprove(spender address, amount int256) +``` + + +## Backwards Compatibility + +As this is new functionality there is no concern for backwards compatibility. + +## Security Implications + +Granting an allowance to a spender account or contract opens up the owner to possible unwanted loss of hbars and thus security considerations must be paramount +when implementing this functionality. Thorough testing will be required to ensure that only the intended spender account or contract can spend the owners hbars. + +## How to Teach This + +The `hbarAllowance` and `hbarApprove` functions can be accessed by an EOA or a contract by calling the `IHRC` interface as described above. This enhances the functionality and use cases +available to the smart contract developer. + +## Rejected Ideas + +The idea of introducing this functionality to the IHederaAccountService interface directly was discarded as this would require that a contract be deployed which may not always be desired. Due to security considerations, doing so would make the functionality less than useful. + +## Open Issues + +## References + +[HIP-632](https://github.com/hashgraph/hedera-improvement-proposal/blob/main/HIP/hip-632.md) +[HIP-719](https://github.com/hashgraph/hedera-improvement-proposal/blob/main/HIP/hip-719.md) + +## Copyright/license + +This document is licensed under the Apache License, Version 2.0 -- see [LICENSE](../LICENSE) or (https://www.apache.org/licenses/LICENSE-2.0) diff --git a/hip-0000-template.md b/hip-0000-template.md index 154c607ac..0237d2b5d 100644 --- a/hip-0000-template.md +++ b/hip-0000-template.md @@ -1,123 +1,72 @@ --- -hip: 000 -title: Proxy Redirect Contract for Hbar Allowance and Approval -author: Luke Lee <@lukelee-sl> -working-group: Nana Essilfie-Conduah <@nana-ec> -requested-by: Smart contract developers -type: Standards Track -category: Service -needs-council-approval: Yes -status: Review -created: 2024-02-23 -discussions-to: https://github.com/hashgraph/hedera-improvement-proposal/discussions/906 -updated: 2023-02-26 -requires: 632 +hip: +title: +author: +working-group: a list of the technical and business stakeholders' name(s) and/or username(s), or name(s) and email(s). +requested-by: the name(s) and/or username(s), or name(s) and email(s) of the individual(s) or project(s) requesting the HIP +type: +category: +needs-council-approval: +status: +created: +discussions-to: +updated: +requires: +replaces: +superseded-by: --- ## Abstract -The Smart Contract service provides for functionality to grant allowance and approve for tokens from the owner account to a spender account. -However, currently there is no functionality to grant allowance and approve for hbars from an owner account via the Smart Contract service. -This HIP proposes to remedy this omission. +Please provide a short (~200 word) description of the issue being addressed. ## Motivation -Smart Contracts developers have obstructions on implementing certain potential use cases for transferring hbar between accounts because there is no way to grant allowance and approve for them from an owner account without using HAPI. -Providing this functionality will remove these obstructions for developers and provide for a better developer experience. +The motivation is critical for HIPs that want to change the Hedera codebase or ecosystem. It should clearly explain why the existing specification is inadequate to address the problem that the HIP solves. HIP submissions without sufficient motivation may be rejected outright. ## Rationale -This HIP proposes to add the needed functionality via a new interface `IHRC632` which will act on an account address. The account will be the actor in view with respect to the allowance to the `spender` account for the specified amount. -An alternative approach would be to introduce a new interface which a contract can implement. This would necessitate that a contract be deployed which may always be desired. In addition, taking this approach would potentially require violating the -smart contracts security model as the sender of the frame when executing the system contract would be the deployed contract and not the EOA which would not be desire in most cases. +The rationale fleshes out the specification by describing why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. -## User stories +The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during the discussion. -1. As a smart contract developer, I want to be able to grant approve an allowance for hbars from an EOA to a spender account or contract. -2. As a smart contract developer, I want to be able to grant approve an allowance for hbars from a contract to a spender account or contract. -3. As a smart contract developer, I want to be able to get the allowance of hbars from an owner account to a spender account or contract. +## User stories +Provide a list of "user stories" to express how this feature, functionality, improvement, or tool will be used by the end user. Template for user story: “As (user persona), I want (to perform this action) so that (I can accomplish this goal).” + ## Specification -HIP-632 proposes an introduction of a new system contract for accessing Hedera account functionality (Hedera Account Service - HAS). -This HIP extends the new system contract to another related interface `IHRC632` to support the `hbarAllowance` and `hbarApprove` functions. -The `hbarAllowance` function will be used to retrieve information about allowance granted to a spender and the `hbarApprove` function will allow the sender to grant to the `spender` an allowance of hbars. - - -Similar to the way redirection to a proxy contract during EVM execution for tokens works [see HIP-719](https://github.com/hashgraph/hedera-improvement-proposal/blob/main/HIP/hip-719.md), -this HIP proposes to introduce a new proxy contract for accounts. During EVM execution, if the target of the current frame is an account, a call to a proxy contract will be created and the current calldata will be injected into -the proxy contract for processing by the Hedera Account Service system contract. - -The bytecode for the proxy contract can be created by compiling the following contract: - -```solidity -// SPDX-License-Identifier: Apache-2.0 -pragma solidity ^0.8.0; -contract Assembly { - fallback() external { - address precompileAddress = address(0x167); - assembly { - mstore(0, 0xFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFE) - calldatacopy(32, 0, calldatasize()) - let result := delegatecall(gas(), precompileAddress, 8, add(24, calldatasize()), 0, 0) - let size := returndatasize() - returndatacopy(0, 0, size) - switch result - case 0 { revert(0, size) } - default { return(0, size) } - } - } -} -``` - -The following table describes the function selector for the new `hbarAllownace` and `hbarApprove` functions and the associated function signature and response. - -| Function Selector Hash | Function Signature | Response | -|------------------------|---------------------------------------------|---------------------------------------------------------------------------| -| 0xbbee989e | hbarAllowance(address spender) | (ResponseCode, int256 - amount of hbar allowances granted to the spender) | -| 0x86aff07c | hbarApprove(spender address, amount int256) | ResponseCode | - -The solidity interface for IHRC632 will be the following - -``` -interface IHRC632 { - function hbarAllowance(address spender) external returns (responseCode, int256); - function hbarApprove(spender address, amount int256) external returns (responseCode); -} -``` - -Once the above functionality has been implemented in services, an EOA will be able to call the `hbarAllownace` and `hbarApprove` functions as follows: - -``` -IHRC(accountAddress).hbarAllowance(address spender) -IHRC(accountAddress).hbarApprove(spender address, amount int256) -``` - +The technical specification should describe the syntax and semantics of any new features. The specification should be detailed enough to allow competing, interoperable implementations for at least the current Hedera ecosystem. ## Backwards Compatibility -As this is new functionality there is no concern for backwards compatibility. +All HIPs that introduce backward incompatibilities must include a section describing these incompatibilities and their severity. The HIP must explain how the author proposes to deal with these incompatibilities. HIP submissions without a sufficient backward compatibility treatise may be rejected outright. ## Security Implications -Granting an allowance to a spender account or contract opens up the owner to possible unwanted loss of hbars and thus security considerations must be paramount -when implementing this functionality. Thorough testing will be required to ensure that only the intended spender account or contract can spend the owners hbars. +If there are security concerns in relation to the HIP, those concerns should be explicitly addressed to make sure reviewers of the HIP are aware of them. ## How to Teach This -The `hbarAllowance` and `hbarApprove` functions can be accessed by an EOA or a contract by calling the `IHRC` interface as described above. This enhances the functionality and use cases -available to the smart contract developer. +For a HIP that adds new functionality or changes interface behaviors, it is helpful to include a section on how to teach users, new and experienced, how to apply the HIP to their work. + +## Reference Implementation + +The reference implementation must be complete before any HIP is given the status of “Final”. The final implementation must include test code and documentation. ## Rejected Ideas -The idea of introducing this functionality to the IHederaAccountService interface directly was discarded as this would require that a contract be deployed which may not always be desired. Due to security considerations, doing so would make the functionality less than useful. +Throughout the discussion of a HIP, various ideas will be proposed which are not accepted. Those rejected ideas should be recorded along with the reasoning as to why they were rejected. This both helps record the thought process behind the final version of the HIP as well as preventing people from bringing up the same rejected idea again in subsequent discussions. + +In a way, this section can be thought of as a breakout section of the Rationale section that focuses specifically on why certain ideas were not ultimately pursued. ## Open Issues +While a HIP is in draft, ideas can come up which warrant further discussion. Those ideas should be recorded so people know that they are being thought about but do not have a concrete resolution. This helps make sure all issues required for the HIP to be ready for consideration are complete and reduces people duplicating prior discussions. + ## References -[HIP-632](https://github.com/hashgraph/hedera-improvement-proposal/blob/main/HIP/hip-632.md) -[HIP-719](https://github.com/hashgraph/hedera-improvement-proposal/blob/main/HIP/hip-719.md) +A collections of URLs used as references through the HIP. ## Copyright/license From dae05bbcc9d6523eece236f04832c3f97fdf6670 Mon Sep 17 00:00:00 2001 From: lukelee-sl Date: Tue, 5 Mar 2024 10:38:00 -0800 Subject: [PATCH 05/19] modify updated date Signed-off-by: lukelee-sl --- HIP/hip-0000-template.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/HIP/hip-0000-template.md b/HIP/hip-0000-template.md index 154c607ac..52db3ea68 100644 --- a/HIP/hip-0000-template.md +++ b/HIP/hip-0000-template.md @@ -10,7 +10,7 @@ needs-council-approval: Yes status: Review created: 2024-02-23 discussions-to: https://github.com/hashgraph/hedera-improvement-proposal/discussions/906 -updated: 2023-02-26 +updated: 2024-02-26, 24-3-05 requires: 632 --- From b787b22061f085f59bb4c96220f4f54ac09bbfed Mon Sep 17 00:00:00 2001 From: lukelee-sl Date: Tue, 5 Mar 2024 10:50:11 -0800 Subject: [PATCH 06/19] add century Signed-off-by: lukelee-sl --- HIP/hip-0000-template.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/HIP/hip-0000-template.md b/HIP/hip-0000-template.md index 52db3ea68..23c45ba03 100644 --- a/HIP/hip-0000-template.md +++ b/HIP/hip-0000-template.md @@ -10,7 +10,7 @@ needs-council-approval: Yes status: Review created: 2024-02-23 discussions-to: https://github.com/hashgraph/hedera-improvement-proposal/discussions/906 -updated: 2024-02-26, 24-3-05 +updated: 2024-02-26, 2024-3-05 requires: 632 --- From c81c11ad0d1c39bc95b5eb6b8cd1b077ae67d75a Mon Sep 17 00:00:00 2001 From: lukelee-sl Date: Tue, 5 Mar 2024 10:52:35 -0800 Subject: [PATCH 07/19] rename hip file Signed-off-by: lukelee-sl --- HIP/{hip-0000-template.md => hip-0000-hbar-approve.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename HIP/{hip-0000-template.md => hip-0000-hbar-approve.md} (100%) diff --git a/HIP/hip-0000-template.md b/HIP/hip-0000-hbar-approve.md similarity index 100% rename from HIP/hip-0000-template.md rename to HIP/hip-0000-hbar-approve.md From caae19c584d2eb0a2921311450f42ff3e7e291fc Mon Sep 17 00:00:00 2001 From: lukelee-sl Date: Tue, 5 Mar 2024 15:15:46 -0800 Subject: [PATCH 08/19] improve clarity Signed-off-by: lukelee-sl --- HIP/hip-0000-hbar-approve.md | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/HIP/hip-0000-hbar-approve.md b/HIP/hip-0000-hbar-approve.md index 23c45ba03..d9327eb38 100644 --- a/HIP/hip-0000-hbar-approve.md +++ b/HIP/hip-0000-hbar-approve.md @@ -16,36 +16,36 @@ requires: 632 ## Abstract -The Smart Contract service provides for functionality to grant allowance and approve for tokens from the owner account to a spender account. -However, currently there is no functionality to grant allowance and approve for hbars from an owner account via the Smart Contract service. +The Smart Contract service currently provides functionality to grant allowance and approval for tokens from an owner account to a spender account. +However, currently there is no way to grant allowance and approval for hbars from an owner account from the Smart Contract service. This HIP proposes to remedy this omission. ## Motivation -Smart Contracts developers have obstructions on implementing certain potential use cases for transferring hbar between accounts because there is no way to grant allowance and approve for them from an owner account without using HAPI. -Providing this functionality will remove these obstructions for developers and provide for a better developer experience. +Smart Contracts developers are obstructed in implementing certain potential use cases for transferring hbar between accounts and contracts because there is no way to grant allowance and approval for them without using HAPI. +Providing this functionality will remove this obstruction for developers and provide for a better developer experience. ## Rationale -This HIP proposes to add the needed functionality via a new interface `IHRC632` which will act on an account address. The account will be the actor in view with respect to the allowance to the `spender` account for the specified amount. -An alternative approach would be to introduce a new interface which a contract can implement. This would necessitate that a contract be deployed which may always be desired. In addition, taking this approach would potentially require violating the +This HIP proposes to add the missing functionality via a new interface `IHRC632` which will act on an account address. +An alternative approach would be to introduce a new interface which a contract can implement. This would necessitate that a contract be deployed which may not always be desired. In addition, taking this approach would potentially require violating the smart contracts security model as the sender of the frame when executing the system contract would be the deployed contract and not the EOA which would not be desire in most cases. ## User stories -1. As a smart contract developer, I want to be able to grant approve an allowance for hbars from an EOA to a spender account or contract. -2. As a smart contract developer, I want to be able to grant approve an allowance for hbars from a contract to a spender account or contract. -3. As a smart contract developer, I want to be able to get the allowance of hbars from an owner account to a spender account or contract. +1. As a smart contract developer, I want to be able to grant an allowance for hbars from an EOA to a spender account or contract. +2. As a smart contract developer, I want to be able to grant an allowance for hbars from a contract to a spender account or contract. +3. As a smart contract developer, I want to be able to get the current allowance of hbars from an owner account to a spender account or contract. ## Specification -HIP-632 proposes an introduction of a new system contract for accessing Hedera account functionality (Hedera Account Service - HAS). -This HIP extends the new system contract to another related interface `IHRC632` to support the `hbarAllowance` and `hbarApprove` functions. +HIP-632 proposes to introduce a new system contract for accessing Hedera account functionality (Hedera Account Service - HAS). +This HIP extends the functionality of the new system contract by adding another related interface `IHRC632` to support the `hbarAllowance` and `hbarApprove` functions. The `hbarAllowance` function will be used to retrieve information about allowance granted to a spender and the `hbarApprove` function will allow the sender to grant to the `spender` an allowance of hbars. Similar to the way redirection to a proxy contract during EVM execution for tokens works [see HIP-719](https://github.com/hashgraph/hedera-improvement-proposal/blob/main/HIP/hip-719.md), -this HIP proposes to introduce a new proxy contract for accounts. During EVM execution, if the target of the current frame is an account, a call to a proxy contract will be created and the current calldata will be injected into +this HIP proposes to introduce a new proxy contract for accounts. During EVM execution, if the target of the current frame is an account, a call to the new proxy contract will be created and the current calldata will be injected into the proxy contract for processing by the Hedera Account Service system contract. The bytecode for the proxy contract can be created by compiling the following contract: @@ -55,7 +55,7 @@ The bytecode for the proxy contract can be created by compiling the following co pragma solidity ^0.8.0; contract Assembly { fallback() external { - address precompileAddress = address(0x167); + address precompileAddress = address(0x16a); assembly { mstore(0, 0xFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFE) calldatacopy(32, 0, calldatasize()) @@ -86,7 +86,7 @@ interface IHRC632 { } ``` -Once the above functionality has been implemented in services, an EOA will be able to call the `hbarAllownace` and `hbarApprove` functions as follows: +Once the above functionality has been implemented in services, an EOA or contract with hbars will be able to call the `hbarAllownace` and `hbarApprove` functions as follows: ``` IHRC(accountAddress).hbarAllowance(address spender) From 3733773da62c03247fdc3302e064945a6dcdb98c Mon Sep 17 00:00:00 2001 From: lukelee-sl Date: Tue, 5 Mar 2024 18:04:38 -0800 Subject: [PATCH 09/19] further wording improvements Signed-off-by: lukelee-sl --- HIP/hip-0000-hbar-approve.md | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/HIP/hip-0000-hbar-approve.md b/HIP/hip-0000-hbar-approve.md index d9327eb38..c77a60833 100644 --- a/HIP/hip-0000-hbar-approve.md +++ b/HIP/hip-0000-hbar-approve.md @@ -16,20 +16,21 @@ requires: 632 ## Abstract -The Smart Contract service currently provides functionality to grant allowance and approval for tokens from an owner account to a spender account. -However, currently there is no way to grant allowance and approval for hbars from an owner account from the Smart Contract service. -This HIP proposes to remedy this omission. +The Smart Contract service currently provides functionality to grant allowance and approval for tokens from an owner account to a spender account. +However, there is currently no way to grant allowance and approval for hbars from an owner account using the Smart Contract service. This HIP proposes to remedy this omission. ## Motivation -Smart Contracts developers are obstructed in implementing certain potential use cases for transferring hbar between accounts and contracts because there is no way to grant allowance and approval for them without using HAPI. -Providing this functionality will remove this obstruction for developers and provide for a better developer experience. +Smart Contracts developers face an obstacle when implementing certain use cases for transferring hbars between accounts and contracts. +The lack of a mechanism to grant allowance and approval for hbars without using HAPI hinders developers’ workflow. Providing this functionality will enhance the developer experience and remove this limitation. ## Rationale -This HIP proposes to add the missing functionality via a new interface `IHRC632` which will act on an account address. -An alternative approach would be to introduce a new interface which a contract can implement. This would necessitate that a contract be deployed which may not always be desired. In addition, taking this approach would potentially require violating the -smart contracts security model as the sender of the frame when executing the system contract would be the deployed contract and not the EOA which would not be desire in most cases. +This HIP proposes adding the missing functionality via a new interface called `IHRC632`, which will act on an account address. + +An alternative approach would be to introduce a new interface that a contract can implement. However, this would require deploying a contract, which may not always be desired. +Additionally, taking this approach could potentially violate the smart contracts security model, as the sender of the frame when executing the system contract would be the deployed contract rather than the EOA (Externally Owned Account), which would not be desirable in most cases. + ## User stories @@ -105,7 +106,7 @@ when implementing this functionality. Thorough testing will be required to ensu ## How to Teach This -The `hbarAllowance` and `hbarApprove` functions can be accessed by an EOA or a contract by calling the `IHRC` interface as described above. This enhances the functionality and use cases +The `hbarAllowance` and `hbarApprove` functions can be accessed by an EOA or a contract by calling the `IHRC632` interface as described above. This enhances the functionality and use cases available to the smart contract developer. ## Rejected Ideas From 3bdc7529f350a1433a5e7b833587d5f17a2b9612 Mon Sep 17 00:00:00 2001 From: Michael Garber Date: Wed, 6 Mar 2024 09:13:26 -0500 Subject: [PATCH 10/19] Update and rename hip-0000-hbar-approve.md to hip-906.md Assign number to hip Signed-off-by: Michael Garber --- HIP/{hip-0000-hbar-approve.md => hip-906.md} | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) rename HIP/{hip-0000-hbar-approve.md => hip-906.md} (98%) diff --git a/HIP/hip-0000-hbar-approve.md b/HIP/hip-906.md similarity index 98% rename from HIP/hip-0000-hbar-approve.md rename to HIP/hip-906.md index c77a60833..83f0e8416 100644 --- a/HIP/hip-0000-hbar-approve.md +++ b/HIP/hip-906.md @@ -1,16 +1,16 @@ --- -hip: 000 +hip: 906 title: Proxy Redirect Contract for Hbar Allowance and Approval author: Luke Lee <@lukelee-sl> working-group: Nana Essilfie-Conduah <@nana-ec> -requested-by: Smart contract developers +requested-by: EVM developers type: Standards Track category: Service needs-council-approval: Yes status: Review created: 2024-02-23 discussions-to: https://github.com/hashgraph/hedera-improvement-proposal/discussions/906 -updated: 2024-02-26, 2024-3-05 +updated: 2024-03-06 requires: 632 --- From 8b535a8e628ee5357c1758ec3fbd723b72f9f8dc Mon Sep 17 00:00:00 2001 From: lukelee-sl Date: Sun, 10 Mar 2024 19:50:12 -0700 Subject: [PATCH 11/19] address review comments Signed-off-by: lukelee-sl --- HIP/hip-906.md | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/HIP/hip-906.md b/HIP/hip-906.md index 83f0e8416..ba38cf013 100644 --- a/HIP/hip-906.md +++ b/HIP/hip-906.md @@ -10,7 +10,7 @@ needs-council-approval: Yes status: Review created: 2024-02-23 discussions-to: https://github.com/hashgraph/hedera-improvement-proposal/discussions/906 -updated: 2024-03-06 +updated: 2024-03-08 requires: 632 --- @@ -26,7 +26,8 @@ The lack of a mechanism to grant allowance and approval for hbars without using ## Rationale -This HIP proposes adding the missing functionality via a new interface called `IHRC632`, which will act on an account address. +[HIP-632](https://github.com/hashgraph/hedera-improvement-proposal/blob/main/HIP/hip-632.md) proposed to introduce a new system contract for accessing Hedera account functionality (Hedera Account Service - HAS). +This HIP proposes adding missing functionality via a new interface called `IHRC632`, which will act on an account address. An alternative approach would be to introduce a new interface that a contract can implement. However, this would require deploying a contract, which may not always be desired. Additionally, taking this approach could potentially violate the smart contracts security model, as the sender of the frame when executing the system contract would be the deployed contract rather than the EOA (Externally Owned Account), which would not be desirable in most cases. @@ -40,8 +41,8 @@ Additionally, taking this approach could potentially violate the smart contracts ## Specification -HIP-632 proposes to introduce a new system contract for accessing Hedera account functionality (Hedera Account Service - HAS). -This HIP extends the functionality of the new system contract by adding another related interface `IHRC632` to support the `hbarAllowance` and `hbarApprove` functions. +## Smart Contracts +This HIP extends the functionality of the Hedera Account Service system contract by adding another related interface `IHRC632` to support the `hbarAllowance` and `hbarApprove` functions. The `hbarAllowance` function will be used to retrieve information about allowance granted to a spender and the `hbarApprove` function will allow the sender to grant to the `spender` an allowance of hbars. @@ -71,6 +72,8 @@ contract Assembly { } ``` +> Note: Just as with the Hedera Token Service system contract, the Hedara Account Service system contract will not be callable using `delegatecall` from a contract. + The following table describes the function selector for the new `hbarAllownace` and `hbarApprove` functions and the associated function signature and response. | Function Selector Hash | Function Signature | Response | @@ -93,11 +96,16 @@ Once the above functionality has been implemented in services, an EOA or contrac IHRC(accountAddress).hbarAllowance(address spender) IHRC(accountAddress).hbarApprove(spender address, amount int256) ``` +> The `hbarApprove` function will be callable by either an EOA or a contract as long as the signatures required by the security model are met. + +## Mirror Node Explorer +It is recommended that the Mirror Node Explorer be updated to reflect allowance details that pertain to contracts as well as account. ## Backwards Compatibility -As this is new functionality there is no concern for backwards compatibility. +As this is new functionality there is no concern for backwards compatibility. The new proposed functionality provides an +avenue for accessing existing allowance and approval functionality available via HAPI to smart contracts and thus conform to existing rules and limitations. ## Security Implications From 6a3ee38d66db6277ad57a1acec2e23e7d56da476 Mon Sep 17 00:00:00 2001 From: lukelee-sl Date: Tue, 19 Mar 2024 07:40:46 -0700 Subject: [PATCH 12/19] update proxy contract Signed-off-by: lukelee-sl --- HIP/hip-906.md | 32 ++++++++++++++++++-------------- 1 file changed, 18 insertions(+), 14 deletions(-) diff --git a/HIP/hip-906.md b/HIP/hip-906.md index ba38cf013..bbcfd577e 100644 --- a/HIP/hip-906.md +++ b/HIP/hip-906.md @@ -10,7 +10,7 @@ needs-council-approval: Yes status: Review created: 2024-02-23 discussions-to: https://github.com/hashgraph/hedera-improvement-proposal/discussions/906 -updated: 2024-03-08 +updated: 2024-03-19 requires: 632 --- @@ -56,19 +56,23 @@ The bytecode for the proxy contract can be created by compiling the following co // SPDX-License-Identifier: Apache-2.0 pragma solidity ^0.8.0; contract Assembly { - fallback() external { - address precompileAddress = address(0x16a); - assembly { - mstore(0, 0xFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFE) - calldatacopy(32, 0, calldatasize()) - let result := delegatecall(gas(), precompileAddress, 8, add(24, calldatasize()), 0, 0) - let size := returndatasize() - returndatacopy(0, 0, size) - switch result - case 0 { revert(0, size) } - default { return(0, size) } - } - } + + fallback() external { + + address precompileAddress = address(0x167); + assembly { + mstore(0, 0xFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFE) + calldatacopy(32, 0, calldatasize()) + + let result := delegatecall(gas(), precompileAddress, 8, add(24, calldatasize()), 0, 0) + let size := returndatasize() + returndatacopy(0, 0, size) + + switch result + case 0 { revert(0, size) } + default { return(0, size) } + } + } } ``` From e6980c31104efc2a085972d523a273567fe2305b Mon Sep 17 00:00:00 2001 From: lukelee-sl Date: Wed, 27 Mar 2024 14:53:10 -0700 Subject: [PATCH 13/19] use uint256 instead of int256 for amounts Signed-off-by: lukelee-sl --- HIP/hip-906.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/HIP/hip-906.md b/HIP/hip-906.md index bbcfd577e..d29dd6a30 100644 --- a/HIP/hip-906.md +++ b/HIP/hip-906.md @@ -10,7 +10,7 @@ needs-council-approval: Yes status: Review created: 2024-02-23 discussions-to: https://github.com/hashgraph/hedera-improvement-proposal/discussions/906 -updated: 2024-03-19 +updated: 2024-03-27 requires: 632 --- @@ -80,10 +80,10 @@ contract Assembly { The following table describes the function selector for the new `hbarAllownace` and `hbarApprove` functions and the associated function signature and response. -| Function Selector Hash | Function Signature | Response | -|------------------------|---------------------------------------------|---------------------------------------------------------------------------| -| 0xbbee989e | hbarAllowance(address spender) | (ResponseCode, int256 - amount of hbar allowances granted to the spender) | -| 0x86aff07c | hbarApprove(spender address, amount int256) | ResponseCode | +| Function Selector Hash | Function Signature | Response | +|------------------------|----------------------------------------------|----------------------------------------------------------------------------| +| 0xbbee989e | hbarAllowance(address spender) | (ResponseCode, uint256 - amount of hbar allowances granted to the spender) | +| 0x76f17392 | hbarApprove(spender address, amount uint256) | ResponseCode | The solidity interface for IHRC632 will be the following From c152a7e9115576b104431743a0d242220b18cfa3 Mon Sep 17 00:00:00 2001 From: lukelee-sl Date: Tue, 9 Apr 2024 15:31:48 -0700 Subject: [PATCH 14/19] additional comments on key benefits and potential use cases. Also add a section discussing notification of update events Signed-off-by: lukelee-sl --- HIP/hip-906.md | 32 +++++++++++++++++++++++++------- 1 file changed, 25 insertions(+), 7 deletions(-) diff --git a/HIP/hip-906.md b/HIP/hip-906.md index d29dd6a30..b5fb9ad04 100644 --- a/HIP/hip-906.md +++ b/HIP/hip-906.md @@ -10,7 +10,7 @@ needs-council-approval: Yes status: Review created: 2024-02-23 discussions-to: https://github.com/hashgraph/hedera-improvement-proposal/discussions/906 -updated: 2024-03-27 +updated: 2024-04-09 requires: 632 --- @@ -30,7 +30,7 @@ The lack of a mechanism to grant allowance and approval for hbars without using This HIP proposes adding missing functionality via a new interface called `IHRC632`, which will act on an account address. An alternative approach would be to introduce a new interface that a contract can implement. However, this would require deploying a contract, which may not always be desired. -Additionally, taking this approach could potentially violate the smart contracts security model, as the sender of the frame when executing the system contract would be the deployed contract rather than the EOA (Externally Owned Account), which would not be desirable in most cases. +Additionally, taking this approach could potentially violate the smart contracts security model, as the sender of the frame when executing the system contract would be the deployed contract rather than the EOA (Externally Owned Account), which would not be desirable in many cases. ## User stories @@ -59,7 +59,7 @@ contract Assembly { fallback() external { - address precompileAddress = address(0x167); + address precompileAddress = address(0x16a); assembly { mstore(0, 0xFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFE) calldatacopy(32, 0, calldatasize()) @@ -80,10 +80,10 @@ contract Assembly { The following table describes the function selector for the new `hbarAllownace` and `hbarApprove` functions and the associated function signature and response. -| Function Selector Hash | Function Signature | Response | -|------------------------|----------------------------------------------|----------------------------------------------------------------------------| -| 0xbbee989e | hbarAllowance(address spender) | (ResponseCode, uint256 - amount of hbar allowances granted to the spender) | -| 0x76f17392 | hbarApprove(spender address, amount uint256) | ResponseCode | +| Function Selector Hash | Function Signature | Response | +|------------------------|----------------------------------------------|----------------------------------------------------------------------------------------| +| 0xbbee989e | hbarAllowance(address spender) | (ResponseCode, uint256 - amount of hbar allowances currently available to the spender) | +| 0x76f17392 | hbarApprove(spender address, amount uint256) | ResponseCode | The solidity interface for IHRC632 will be the following @@ -102,6 +102,24 @@ IHRC(accountAddress).hbarApprove(spender address, amount int256) ``` > The `hbarApprove` function will be callable by either an EOA or a contract as long as the signatures required by the security model are met. +## Key Benefits and Possible Use Cases +Key benefits include: +1. Better developer experience. Develops will not have to use the SDK to perform tasks that will be available via this HIP. +2. Support for potentially new flows for DAPs such as DEFI and token marketplaces. +3. Differentiates Hedera from other chains that do not allow an allowance/approval mechanism for their native tokens. + +Potential use cases that have been communicated by the community include uses for NFT marketplaces to overcome signing requirements that can cause friction. +For example in a marketplace application, a contract can act as an agent for an EOA to hold balances of hbar, fungible tokens and non-fungible tokens. This HIP enables this contract to +grant an allowance to another contract who can act as a broker by gathering all the necessary allowances to enable an exchange. Using the allowance +mechanism can alleviate the need for an EOA to sign transactions for such use cases as royalty fallback fees. + +## Updates via HAPI + +It is possible that the approved allowances for a spender can be spent or increased by submitting a separate approval transaction via +HAPI. In this case, the smart contract would not be aware of these changes in state could possibly hold stale state. While it would be possible +for EVM transactions to emit an event to communicate such updates to interested parties, such a facility for HAPI transaction updates are not +considered at this time. + ## Mirror Node Explorer It is recommended that the Mirror Node Explorer be updated to reflect allowance details that pertain to contracts as well as account. From 2ec08b89178a4b212f13df6f4b412f670a1eb748 Mon Sep 17 00:00:00 2001 From: lukelee-sl Date: Tue, 16 Apr 2024 10:43:44 -0700 Subject: [PATCH 15/19] address pr comments Signed-off-by: lukelee-sl --- HIP/hip-906.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/HIP/hip-906.md b/HIP/hip-906.md index b5fb9ad04..a1c06fcc1 100644 --- a/HIP/hip-906.md +++ b/HIP/hip-906.md @@ -10,7 +10,7 @@ needs-council-approval: Yes status: Review created: 2024-02-23 discussions-to: https://github.com/hashgraph/hedera-improvement-proposal/discussions/906 -updated: 2024-04-09 +updated: 2024-04-16 requires: 632 --- @@ -94,7 +94,7 @@ interface IHRC632 { } ``` -Once the above functionality has been implemented in services, an EOA or contract with hbars will be able to call the `hbarAllownace` and `hbarApprove` functions as follows: +Once the above functionality has been implemented in services, an EOA or contract with hbars will be able to call the `hbarAllowance` and `hbarApprove` functions as follows: ``` IHRC(accountAddress).hbarAllowance(address spender) @@ -104,7 +104,7 @@ IHRC(accountAddress).hbarApprove(spender address, amount int256) ## Key Benefits and Possible Use Cases Key benefits include: -1. Better developer experience. Develops will not have to use the SDK to perform tasks that will be available via this HIP. +1. Better developer experience. Developers will not have to use the SDK to perform tasks that will be available via this HIP. 2. Support for potentially new flows for DAPs such as DEFI and token marketplaces. 3. Differentiates Hedera from other chains that do not allow an allowance/approval mechanism for their native tokens. @@ -116,7 +116,7 @@ mechanism can alleviate the need for an EOA to sign transactions for such use ca ## Updates via HAPI It is possible that the approved allowances for a spender can be spent or increased by submitting a separate approval transaction via -HAPI. In this case, the smart contract would not be aware of these changes in state could possibly hold stale state. While it would be possible +HAPI. In this case, the smart contract would not be aware of these changes in state and it could possibly hold stale state. While it would be possible for EVM transactions to emit an event to communicate such updates to interested parties, such a facility for HAPI transaction updates are not considered at this time. From 6296b0f934a97b48cfe1072168b046792ba81d6f Mon Sep 17 00:00:00 2001 From: Michael Garber Date: Wed, 17 Apr 2024 11:57:55 -0400 Subject: [PATCH 16/19] Update hip-906.md to Last Call Signed-off-by: Michael Garber --- HIP/hip-906.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/HIP/hip-906.md b/HIP/hip-906.md index a1c06fcc1..fa6746491 100644 --- a/HIP/hip-906.md +++ b/HIP/hip-906.md @@ -7,10 +7,11 @@ requested-by: EVM developers type: Standards Track category: Service needs-council-approval: Yes -status: Review +status: Last Call +last-call-date-time: 2024-05-01T07:00:00Z created: 2024-02-23 discussions-to: https://github.com/hashgraph/hedera-improvement-proposal/discussions/906 -updated: 2024-04-16 +updated: 2024-04-17 requires: 632 --- From 72471f3838bab12822f4b280e774b0c3871822d6 Mon Sep 17 00:00:00 2001 From: lukelee-sl Date: Wed, 17 Apr 2024 09:44:49 -0700 Subject: [PATCH 17/19] fill in requested-by section in header Signed-off-by: lukelee-sl --- HIP/hip-906.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/HIP/hip-906.md b/HIP/hip-906.md index a1c06fcc1..6cb63d54f 100644 --- a/HIP/hip-906.md +++ b/HIP/hip-906.md @@ -3,14 +3,14 @@ hip: 906 title: Proxy Redirect Contract for Hbar Allowance and Approval author: Luke Lee <@lukelee-sl> working-group: Nana Essilfie-Conduah <@nana-ec> -requested-by: EVM developers +requested-by: Michael Kantor <@kantorcodes>, Ariane Labs <@ArianeLabs> type: Standards Track category: Service needs-council-approval: Yes status: Review created: 2024-02-23 discussions-to: https://github.com/hashgraph/hedera-improvement-proposal/discussions/906 -updated: 2024-04-16 +updated: 2024-04-17 requires: 632 --- From 16bae62cf22d1df29bd00af1d740614b4a021119 Mon Sep 17 00:00:00 2001 From: lukelee-sl Date: Wed, 17 Apr 2024 10:15:52 -0700 Subject: [PATCH 18/19] update authors in heading Signed-off-by: lukelee-sl --- HIP/hip-906.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/HIP/hip-906.md b/HIP/hip-906.md index 4a16b82e0..66fb89cfb 100644 --- a/HIP/hip-906.md +++ b/HIP/hip-906.md @@ -1,7 +1,7 @@ --- hip: 906 title: Proxy Redirect Contract for Hbar Allowance and Approval -author: Luke Lee <@lukelee-sl> +author: Luke Lee <@lukelee-sl>, Michael Kantor <@kantorcodes> working-group: Nana Essilfie-Conduah <@nana-ec> requested-by: Michael Kantor <@kantorcodes>, Ariane Labs <@ArianeLabs> type: Standards Track From c581f77b801be7497d4dff4f51c974688dbce149 Mon Sep 17 00:00:00 2001 From: lukelee-sl Date: Thu, 18 Apr 2024 10:34:23 -0700 Subject: [PATCH 19/19] fix function call signature Signed-off-by: lukelee-sl --- HIP/hip-906.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/HIP/hip-906.md b/HIP/hip-906.md index 66fb89cfb..a874851aa 100644 --- a/HIP/hip-906.md +++ b/HIP/hip-906.md @@ -11,7 +11,7 @@ status: Last Call last-call-date-time: 2024-05-01T07:00:00Z created: 2024-02-23 discussions-to: https://github.com/hashgraph/hedera-improvement-proposal/discussions/906 -updated: 2024-04-17 +updated: 2024-04-18 requires: 632 --- @@ -81,17 +81,17 @@ contract Assembly { The following table describes the function selector for the new `hbarAllownace` and `hbarApprove` functions and the associated function signature and response. -| Function Selector Hash | Function Signature | Response | -|------------------------|----------------------------------------------|----------------------------------------------------------------------------------------| -| 0xbbee989e | hbarAllowance(address spender) | (ResponseCode, uint256 - amount of hbar allowances currently available to the spender) | -| 0x76f17392 | hbarApprove(spender address, amount uint256) | ResponseCode | +| Function Selector Hash | Function Signature | Response | +|------------------------|------------------------------------------------|----------------------------------------------------------------------------------------| +| 0xbbee989e | hbarAllowance(address spender) | (ResponseCode, uint256 - amount of hbar allowances currently available to the spender) | +| 0x76f17392 | hbarApprove(address spender, uint256 amount) | ResponseCode | The solidity interface for IHRC632 will be the following ``` interface IHRC632 { function hbarAllowance(address spender) external returns (responseCode, int256); - function hbarApprove(spender address, amount int256) external returns (responseCode); + function hbarApprove(address spender, uint256 amount) external returns (responseCode); } ``` @@ -99,7 +99,7 @@ Once the above functionality has been implemented in services, an EOA or contrac ``` IHRC(accountAddress).hbarAllowance(address spender) -IHRC(accountAddress).hbarApprove(spender address, amount int256) +IHRC(accountAddress).hbarApprove(address spender, uint256 amount) ``` > The `hbarApprove` function will be callable by either an EOA or a contract as long as the signatures required by the security model are met.