Skip to content

feat(ctf): add support for proxy wallet when calling CTF contract#15

Open
jclmnop wants to merge 1 commit intoPolymarket:mainfrom
jclmnop:feat/proxy-wallet-ctf-v2
Open

feat(ctf): add support for proxy wallet when calling CTF contract#15
jclmnop wants to merge 1 commit intoPolymarket:mainfrom
jclmnop:feat/proxy-wallet-ctf-v2

Conversation

@jclmnop
Copy link
Copy Markdown

@jclmnop jclmnop commented Apr 25, 2026

Problem

CTF client can currently only perform write operations (split/merge/redeem) for EOA type wallets. Read operations work for all types.

Solution

I added a wallet_type field to the CTF client (defaults to EOA so default behaviour isn't changed if user doesn't set it).

The send_call() method takes a call to the CTF contract and uses the appropriate mechanism to send the tx based on wallet type. send_call() is only used for split/merge/redeem.

For EOA type it doesn't do anything differently.

The reason I created a separate WalletType enum instead of using the existing SignatureType enum is because GNOSIS isn't yet implemented, and I wanted to limit the variants to types that are actually implemented. If GNOSIS is eventually implemented, then you can just re-use the signature type enum (to avoid breaking the API at that point, just change the param type to impl Into<WalletType> and implement From<SignatureType> for WalletType).

Also derived Deserialize on the enum so users can include it in their own configs etc (same for Serialize in case people want to be able to Serialize their own configs to another format or something).

Example usage

For EOA wallets, CTF initialisation is the same:

// Using with default (EOA) wallet type
let ctf = CtfClient::new(provider, ContractClient::CHAIN)?;
ctf.split_position(...).await?;

For proxy wallets, just one extra method is required when initialising the client:

// Using with proxy wallet type
let ctf = CtfClient::new(provider, ContractClient::CHAIN)?
    .with_wallet_type(WalletType::Proxy);
ctf.split_position(...).await?;

Added example usage to examples/ctf.rs.

Risk

THIS CHANGE WAS WRITTEN FOR V1 AND HASN'T BEEN TESTED WITH V2 so if there are any differences I'm unaware of regarding the CTF contract etc, this will need some modifications.

Existing behaviour isn't changed. CTF client uses EOA by default, which makes contract calls in exactly the same way as before.

In V1, I've been using this implementation myself to do all 3 types of write calls (split, merge and redeem) with a proxy wallet and had no issues. Beforehand I couldn't make those calls using the CTF client with a proxy wallet.

Tests

I did attempt to write some unit tests, using the same mocking logic as the other CTF client tests, but I have no idea how the raw expected responses are formed and didn't really have time to dive into it.

If unit tests are required, then just point me in the direction of how to find expected response bodies for each request type and I'll implement them.


Note

Medium Risk
Adds a new transaction-sending path for CTF write operations that routes calls through a ProxyFactory, which can affect how on-chain transactions are constructed/sent and may fail on chains without the proxy contract configured.

Overview
Adds proxy-wallet support for CTF write operations by introducing a WalletType (defaulting to EOA) and routing split/merge/redeem (including NegRisk redeem) through a new send_call helper that either sends directly or wraps the call in a ProxyFactory.proxy() transaction.

Updates client construction to optionally load the chain’s proxy factory address (wallet_contract_config) and provides Client::with_wallet_type(...) for selecting proxy behavior, plus updates the examples/ctf.rs CLI to accept eoa/proxy flags for write-mode runs.

Reviewed by Cursor Bugbot for commit c5c3fa4. Bugbot is set up for automated code reviews on this repo. Configure here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant