Pitch: Enhancing Vote Traceability

[hmrtn]

Background:
The aim of this proposal is to improve the traceability of our voting system for batched checkout, which are expected to be implemented in a future enhancement with a new Multi-checkout contract. The core of the issue lies in the traceability of the originating account in multi-round checkout contract invocations.

Context:

Currently, our system allows users to vote on a RoundImplementation contract, which subsequently passes the encoded votes to the QuadraticFundingImplementation contract, ultimately triggering a Vote event. If a Multi-checkout contract were introduced to execute batched checkouts by calling Round.vote, then msg.sender within Round.vote would register the address of the Multi-checkout contract, instead of the EOA that invoked the original transaction.

Suggested Implementation:

To enhance traceability and enable identification of the original EOA that invoked the transaction, irrespective of the sender of Round.vote, it is proposed to include tx.origin in the Vote event emitted by the QuadraticFundingImplementation contract. This change will allow us to identify the original EOA, even when intermediary contracts are used.

In QuadraticFundingImplementation:

  // update version
  string public constant VERSION = "0.2.1";

  ...

  // Emitted when a new vote is sent
  event Voted(
    address token,                    // voting token
    uint256 amount,                   // voting amount
    address indexed voter,            // voter address
    address grantAddress,             // grant address
    bytes32 indexed projectId,        // project id
    uint256 applicationIndex,         // application index
    address indexed roundAddress      // round address
    address origin                    // tx origin
  );

  ...

  // fn vote 
  emit Voted(token, amount, voter, grantAddress, projectId, applicationIndex, roundAddress, tx.origin);

In the updated Voted event, an origin field is added, representing tx.origin, the address of the original EOA that initiated the transaction.

When the event is emitted, ensure to include tx.origin as the origin parameter:

Implications

While this proposal will improve traceability, it's important to note that tx.origin should only be used for tracking or auditing purposes and should not be utilized in any security-critical functionality due to potential security vulnerabilities.

You can find more of the past discussion here: https://discord.com/channels/562828676480237578/1108094112617484398

[meglister]

Thanks @hmrtn for kicking this off, I'm excited about this project!

I'm also wondering if this modification would solve for the blocking issue with fiat onramping. My understanding is that we were hoping to integrate a fiat onramp and were blocked from doing so because the votes could not be traced to specific voters. I think Olsen (not sure his gh un!) was closest to that project and may have more details!

[hmrtn]

I am not sure if this relates to that issue - can you provide a link to discussion or description of that feature request?

[vacekj]

+1 for fiat onramps. cc @kevinrolsen

[kevinrolsen]

Unfortunately, the fiat on-ramping investigation didn't reveal a solution that would make sense for us. Our hope was to create a flow that didn't rely on the user creating a wallet, funding that wallet, and then voting. The current options are limited geographically as well as functionally and require the user to install and manage their own wallet. So this effort was not continued.

For completeness of the conversation here - we hoped to find a fiat/credit-card flow that uses a custodial/abstracted wallet behind the scenes to interact with our round/voting contract. Depending on the specifics of that fiat provider implementation, I would expect that we would need the changes proposed above.

[thelostone-mc]

@hmrtn Just checked this out. LGTM

• Raise an AIP into the development folder (assuming the changes are being made now) https://github.com/allo-protocol/aips/tree/main/AIPS/in-development
• Raise a PR and link it to the AIP against the https://github.com/allo-protocol/allo-contracts repo

We'll review and get the changes merged

[hmrtn]

AIP Doc Linked here: https://github.com/allo-protocol/aips/blob/aip-13/AIPS/in-development/aip-13.md