Task 3: Batching Transactions & Signatures Design

Objective

Reduce the number of user interactions (wallet popups) required for trading, specifically for:

1. Batch Execution: Performing multiple actions (e.g., buying multiple outcomes) in a single transaction.
2. Batch Creation: Placing multiple limit orders without signing each one individually.

Proposed Solution

1. Batch Execution (Transactions) using Multicall

Problem: If a user wants to buy YES shares in 3 different markets, they currently send 3 transactions. Solution: Implement Multicall in the CTFExchange contract.

Contract Changes (nostra-contracts):

• Inherit from @openzeppelin/contracts/utils/Multicall.sol in CTFExchange.
• This adds the multicall(bytes[] calldata data) function.
• Users can bundle calls to fillOrder, matchOrders, cancelOrder, deposit, etc.

Frontend Changes (web):

• Use multicall when the user performs a "Batch Action" (e.g., "Bet on All" or "Hedge").

2. Batch Creation (Signatures) using Session Keys

Problem: Creating multiple limit orders requires signing an EIP-712 message for each order. Solution: Implement Session Keys (Delegates). The user approves a temporary key (Session Key) to sign orders on their behalf.

Contract Changes (nostra-contracts):

• New Mixin: contracts/exchange/mixins/Delegates.sol (or add to Auth.sol).

  mapping(address => mapping(address => bool)) public delegates;
  event DelegateUpdated(address indexed user, address indexed delegate, bool status);
  
  function setDelegate(address delegate, bool status) external {
      delegates[msg.sender][delegate] = status;
      emit DelegateUpdated(msg.sender, delegate, status);
  }
  

• Update Signatures.sol:
  • Modify verifyEOASignature:

    function verifyEOASignature(address signer, address maker, bytes32 structHash, bytes memory signature) internal view returns (bool) {
        // Allow if signer is maker OR signer is a delegate of maker
        if (signer != maker && !delegates[maker][signer]) return false;
        return verifyECDSASignature(signer, structHash, signature);
    }
    

  • Note: validateOrderSignature needs to be view (it is), but delegates mapping access is fine.
  • Important: Signatures mixin currently doesn't have access to delegates. We need to expose delegates via an interface or inherit Delegates in Signatures (or CTFExchange overrides validateOrderSignature and checks delegates).
  • Better Approach: CTFExchange inherits Delegates. CTFExchange overrides validateOrderSignature (which is virtual in Signatures).

Frontend Changes (web):

• Generate a local key pair (Session Key) in the browser.
• Prompt user to setDelegate(sessionKeyAddress, true) (One transaction).
• Store Session Key securely (e.g., session storage).
• When placing orders, sign with Session Key. No wallet popup required.

Implementation Roadmap

Phase 1: Multicall (Immediate)

1. Add Multicall inheritance to CTFExchange.
2. Redeploy.
3. Update Frontend to use multicall for batch trades.

Phase 2: Session Keys (Future Scope)

Note: To be implemented in a later iteration to further reduce signature fatigue.

1. Implement Delegates logic in contracts.
2. Update validateOrderSignature.
3. Redeploy.
4. Implement Session Key management in Frontend.

Considerations

• Security: Session keys should have an expiration or scope. However, for MVP, a simple boolean delegate is sufficient (User can revoke).
• Gas: Multicall adds slight overhead but saves significant gas compared to multiple txs.
• Complexity: Session Keys require careful frontend state management.