menu

Aragon

Aragon is the most powerful and modular way to run DAOs

Channels
# All channels
view-forward
# Announcements
view-forward
# App development
view-forward
# Aragon Agent
view-forward
# Aragon Client
view-forward
# Aragon Connect
view-forward
# aragonOS
view-forward
# aragonUI
view-forward
# Feature requests
view-forward
Team

Coinbase review questions | How are scripts verified?

April 13, 2020 at 3:12pm

Coinbase review questions | How are scripts verified?

April 13, 2020 at 3:12pm (Edited 3 months ago)
We are trying to get our token listed on Coinbase and have had some questions from their review team.
The major one is "What review process is in place to ensure that EVMscript votes submitted to the TokenManager are not malicious? (e.g. someone uploads a script to mint tokens for themselves or burn tokens from Coinbase account)"
It is my understanding that a script is verified before a vote for it can be created. Is this correct?
If so, how is the verification done and by what entity? Or is there a predefined set of valid scripts for each app that gets walked through?

April 13, 2020 at 4:50pm
Hi Val, That's a good question. As a general rule, it's always important to be careful with EVMScripts as they can contain any arbitrary code. But the script does go through some verifications so that the vote description can be as explicit as possible:
  1. You will always see the account address that created the vote. So any suspicious address can be blocked.
  2. You will also see the target on which the EVMScript will be executed, which makes it easy to block a vote that is supposed to be executed on a specific app but is executed on another instead.
  3. With almost all the existing apps actions, a clear description will be displayed in the vote. So you will easily be able to see what action a vote will execute and block any suspicious votes with unknown descriptions. E.g. here is a description of a vote that mints a token:
Edited
like-fill
1
  • reply
  • like
  • reply
  • like
That makes sense! Can i add a script to a vote that is arbitrary in the sense that it doesn't affect any apps installed in the DAO, and instead invokes something on some external contract?
Edited
  • reply
  • like
I do believe it would be possible yes. Though the address of that external contract would be clearly indicated in the vote description.
  • reply
  • like
How is the description generated from the script? For example, if my script creates a transaction on a contract 0x123 with an argument that is "name: Alice", how would that be represented in the UI?
Edited
  • reply
  • like

April 14, 2020 at 8:44am
Can i add a script to a vote that is arbitrary in the sense that it doesn't affect any apps installed in the DAO, and instead invokes something on some external contract?
Yes, this is possible, although you may want to use the Agent app instead for these types of "arbitrary" actions—the Agent is meant to represent the organization in external interactions with other contracts as it can hold value (e.g. sending tokens to Uniswap, obtaining loans through Compound, etc).
How is the description generated from the script? For example, if my script creates a transaction on a contract 0x123 with an argument that is "name: Alice", how would that be represented in the UI?
This is currently controlled by radspec, which has a primarily hardcoded list of descriptions for external contracts (those "outside" your organization) for now. We are extending the capabilities so that others can submit descriptions for their own contracts.
At the moment, if no description is found, the UI will simply display "Unknown action" (but please let us know if you're using something popular and it's showing that!).
  • reply
  • like
Thank you guys! This information is very helpful. I think it would be super valuable to have a verification process where scripts outside of installed apps must be approved by a passing vote before a vote can be created using that script.
like-fill
1
  • reply
  • like
what do you think about the feasibility of this? presumably each possible script can be determined when a contract is installed.
  • reply
  • like
This would effectively produce a whitelist. Alternatively there could be a blacklist.
  • reply
  • like
A whitelist would definitely be an interesting feature. The EVMScriptRunner can also take a blacklist as parameter but it is not supported in the Voting app yet unfortunately.
  • reply
  • like

April 14, 2020 at 7:28pm
A whitelist would definitely be an interesting feature. The EVMScriptRunner can also take a blacklist as parameter but it is not supported in the Voting app yet unfortunately.
What do you mean by not supported in the Voting app? Where does the blacklist take affect?
  • reply
  • like
Yes exactly, the runScript() function takes a _blacklist argument but the Voting app currently creates an empty array for it.
Edited
  • reply
  • like

April 15, 2020 at 1:28pm
Thank you guys! This information is very helpful. I think it would be super valuable to have a verification process where scripts outside of installed apps must be approved by a passing vote before a vote can be created using that script.
To understand this better, do you mean that it would be nice if you could configure your installed apps to be only allowed to call certain, pre-approved destination contracts?
This would be an interesting feature for the Agent, which is usually the one that makes these external calls.
  • reply
  • like
Yes! That would be the simplest way for us to restrict what scripts get executed by the Voting app.
  • reply
  • like
But we don't have the Agent installed in the DAO right now so what do you mean by it "makes these external calls"? Our goal is actually to restrict calls to any contracts external to the DAO
  • reply
  • like
Yes, Voting technically can make external calls to contracts outside the DAO, but the Agent app is most likely the one you'd want to use for this instead, as it's the one who will handle tokens and eth balances better (e.g. it can be very limiting to interact with other contracts on-chain with just Voting)
  • reply
  • like
Is there a way we can disable this ability in Voting? We do not want it to make external calls
Edited
  • reply
  • like
At the moment, not that I know of. However, you will always be able to clearly see the address of the contract on which the call will be executed before you vote.
  • reply
  • like
Is there a way we can disable this ability in Voting? We do not want it to make external calls
There is no way to do this, due to technical constraints.
To the Voting app at the moment, all other contracts are considered "external", even those inside your organization that it will likely be interacting with.
I have created an issue for this: https://github.com/aragon/aragon/issues/1414, but moved it directly into the contract-upgrade wishlist because solving this is unfortunately not technically easy at the moment.
However you can develop your own Voting application that includes this constraint and uninstall the current Voting instance from your organization.
Edited
like-fill
1
  • reply
  • like
Ok. One potentially, relatively easy workaround for this is showing the function signature and inputs of the script in the UI. I see that the runScript method takes the script and input as bytes. Presumably we can decode this and also get the function signature from the executor.
  • reply
  • like
Does this sound on the right track?
  • reply
  • like
Yes that's absolutely possible. The hashed function signature is already extracted and compared to known signatures from this registry. It would certainly be possible to extract the parameters as well. Though I'm not sure about functions that aren't in the registry. Though if you want to restrict votes to apps from your organization, you would probably only need to compare the address of the contract.
like-fill
1
  • reply
  • like
Yes, there is an issue for this too :) https://github.com/aragon/aragon/issues/668.
As hash functions are one-way, we can't get the function signature from the data without an external look-up table (e.g. 4byte.directory)
like-fill
1
  • reply
  • like
Yes, there is an issue for this too :) https://github.com/aragon/aragon/issues/668.
As hash functions are one-way, we can't get the function signature from the data without an external look-up table (e.g. 4byte.directory)
4byte.directory is not loading for me. Looks like its down?
  • reply
  • like
Show more messages