You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is required to allow using Neon Proxy only for restricted amount of clients for the Pre-Alpha/Alpha period. Such restrictions will be implemented by introducing several types of account whitelists:
Operator whitelist - already implemented in Neon-EVM
Client whitelist - set of client accounts that was approved by Neon to run transactions
Application whitelist - set of program accounts that was approved by Neon to deploy programs to it
Client and Application whitelists will be implemented by using special 'allowance' tokens:
Client allowance tokens should be transferred to selected tester accounts that was approved by Neon. Proxy will check sender of every incoming transaction to have non-zero allowance-token balance or reject transaction otherwise.
Application allowance tokens should be transferred to selected program accounts that was approved by Neon to deploy programs to it. Proxy will check every incoming deployment transaction to have non-zero allowance-token balance on target program account or reject transaction otherwise.
Addresses of allowance token's mints should be hardcoded into Neon-EVM. Proxy should retrieve this addresses from Neon-EVM and use it then to correctly calculate allowance-token-accounts for clients and programs
UPD:
After brainstorming it was decided to introduce additional tokens:
Client denial token
Contract denial token
Denial tokens will be used to deny some client/contract to execute transactions/deploy. Permissions for client/contract will be calculated as difference allowance-token-balance minus denial-token-balance. Received value than will be compared with preconfigured minimal-balance to make a decision: client/contract will be allowed to execute transaction/deploy if difference is greater or equal to minimal balance and denied otherwise. This approach is more flexible in case when it is required to revoke allowance for some clients/contracts. Also this approach makes it easier to test feature on different environments
It is required to allow using Neon Proxy only for restricted amount of clients for the Pre-Alpha/Alpha period. Such restrictions will be implemented by introducing several types of account whitelists:
Client and Application whitelists will be implemented by using special 'allowance' tokens:
Addresses of allowance token's mints should be hardcoded into Neon-EVM. Proxy should retrieve this addresses from Neon-EVM and use it then to correctly calculate allowance-token-accounts for clients and programs
UPD:
After brainstorming it was decided to introduce additional tokens:
Denial tokens will be used to deny some client/contract to execute transactions/deploy. Permissions for client/contract will be calculated as difference allowance-token-balance minus denial-token-balance. Received value than will be compared with preconfigured minimal-balance to make a decision: client/contract will be allowed to execute transaction/deploy if difference is greater or equal to minimal balance and denied otherwise. This approach is more flexible in case when it is required to revoke allowance for some clients/contracts. Also this approach makes it easier to test feature on different environments
Proposed test plan
┆Issue is synchronized with this Jira Task by Unito
The text was updated successfully, but these errors were encountered: