From a57d2a53aa8b0b8a1949bfe03efa436964001a66 Mon Sep 17 00:00:00 2001 From: Akhi Singhania Date: Mon, 19 Feb 2024 14:33:59 +0100 Subject: [PATCH] fix lint issue --- neps/nep-519-yield-execution.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/neps/nep-519-yield-execution.md b/neps/nep-519-yield-execution.md index 2c346402f..bf39662a4 100644 --- a/neps/nep-519-yield-execution.md +++ b/neps/nep-519-yield-execution.md @@ -117,8 +117,8 @@ The section should return to the examples given in the previous section, and exp Some potential security issues have been identified and are covered below: -* Smart contracts using this functionality have to be careful not to let just any party trigger a call to `promise_yield_resume`. In the example above, it is possible that a malicious actor may pretend to be an external signer and call the `signature_available()` function with an incorrect signature. Hence contracts should be taking precautions by only letting select callers call the function (by using [this](https://github.com/aurora-is-near/near-plugins/blob/master/near-plugins/src/access_controllable.rs) service for example) and validating the payload before acting upon it. -* This mechanism introduces a new way to create delayed receipts in the protocol. When the protocol is under conditions of congestion, this mechanism could be used to further aggravate the situation. This is deemed as not a terrible issue as the existing mechanisms of using promises and etc. can also be used to further exacerbate the situation. +- Smart contracts using this functionality have to be careful not to let just any party trigger a call to `promise_yield_resume`. In the example above, it is possible that a malicious actor may pretend to be an external signer and call the `signature_available()` function with an incorrect signature. Hence contracts should be taking precautions by only letting select callers call the function (by using [this](https://github.com/aurora-is-near/near-plugins/blob/master/near-plugins/src/access_controllable.rs) service for example) and validating the payload before acting upon it. +- This mechanism introduces a new way to create delayed receipts in the protocol. When the protocol is under conditions of congestion, this mechanism could be used to further aggravate the situation. This is deemed as not a terrible issue as the existing mechanisms of using promises and etc. can also be used to further exacerbate the situation. ## Alternatives