# Forensic Review: Coordinated Outcome Trading Between `0xbcc3...41b1` and `0x4b67...ccba`

**Public-chain reconstruction, reward analysis, and wallet-linkage assessment**

> **Evidence cut-off:** 4 September 2026, 09:15:59 UTC  
> **Observed paired-trading window:** 29 August 2026, 19:54:52.442 UTC to 3 September 2026, 22:01:09.296 UTC  
> **Scope:** Public-chain and public-API evidence only

## Executive conclusion

**Bottom line:** the evidence supports deliberate coordination between Wallet A and Wallet B at high confidence. Twenty-six executions across 16 markets paired the wallets at the same millisecond, under the same HyperCore execution hash, for the same quantity and on complementary outcomes. All 26 involved a short-resting limit order from one wallet followed by a crossing order from the other. A separate cross-chain trace proves that Wallet A transferred approximately 23,000 USDC directly to Wallet B, after which Wallet B moved a near-equivalent amount into HyperCore.

The economic pattern is consistent with coordinated reward farming or circular volume. At cluster level, the wallets carried almost no directional exposure. A gross trading loss of **3.420000 USDC**, plus **274.029504 USDC** in reported settlement fees, produced a reconstructed trading loss of **277.449504 USDC**. The wallets received **523.493601 USDC** in rewards. A further **55.746785 USDC** was finalised but unpaid at the evidence cut-off. Paid rewards exceeded the reconstructed trading loss by a scoped apparent surplus of **246.044097 USDC** before bridge charges, native gas, and unrelated activity.

The public record does **not** establish that one person owns both wallets. It also does not establish involvement by an Outcome founder, employee, deployer, or treasury controller. There is no public basis to describe this as insider trading. Both wallets predate the 2026 campaign: Wallet B was active by January 2023 and Wallet A by February 2025. That history shows neither wallet was created solely for this campaign, but it does not identify who operated them in 2026 or weaken the evidence of campaign coordination.

The community memo reached the right conclusion about coordination, but its main ownership argument was wrong. Address `0x6b9e...0a24` is Circle's shared `CoreDepositWallet`, not a private funding wallet. It routed funds to more than 21,000 destinations during the examined window. Its appearance in Wallet A, Wallet B and treasury records creates no ownership link.

The evidence supports the following classification:

> **High-confidence wallet coordination. Activity consistent with excluded circular reward farming. Operator identity unresolved. No present basis for an insider allegation.**

## Findings summary

| Question | Assessment | Basis |
| --- | --- | --- |
| Did A and B coordinate? | **High confidence** | Exact paired executions and a direct A-to-B value transfer |
| Was the activity economically circular? | **Strongly supported** | Mirrored positions, negligible cluster PnL before fees and repeated reciprocal execution |
| Is reward generation the clearest observable economic rationale? | **Strongly supported** | Paid rewards exceeded the reconstructed trading loss before excluded costs |
| Does one person control both wallets? | **Plausible, not established** | Public records prove cooperation, not beneficial ownership or shared private keys |
| Were published reward exclusions potentially triggered? | **Strongly supported** | The rules already excluded self-trading, related-wallet churn, wash trading and circular volume |
| Is there evidence of founder, team or deployer involvement? | **No public evidence found** | No ownership, funding or operational link to Outcome personnel was identified |
| Can a country or time zone be inferred? | **No** | Transaction timestamps can reflect a bot, relayer, VPN, or cloud server rather than the user's location |

## 1. Scope and questions

The investigation addressed six questions:

1. Were the two wallets genuinely paired in the same executions?
2. Did the wallets recycle capital between each other?
3. What economic risk did the pair retain?
4. Did paid rewards exceed the reconstructed trading loss before excluded costs?
5. Can either wallet be linked to Outcome founders, staff, deployers or treasury control?
6. Can transaction timing support a geographic attribution?

All timestamps were normalised to UTC. Public-chain records and public APIs were used for transaction, order, reward, and contract-role verification. Internal KYC, IP, device, session, API-key, referral, and beneficial-owner records were not available. This is an investigative assessment, not a legal determination.

## 2. Address register

| Label | Address | Function established |
| --- | --- | --- |
| Wallet A | `0xbcc3237bb9b0468c32fabb7f000b799be33441b1` | Trader and reward recipient |
| Wallet B | `0x4b67c7f8893bd8fbc819fa57b9dd9dde0b03ccba` | Trader and reward recipient |
| Circle CoreDepositWallet | `0x6b9e773128f453f5c2c60935ee2de2cbc5390a24` | Shared HyperEVM-to-HyperCore deposit infrastructure |
| Circle CctpForwarder | `0xb21d281dedb17ae5b501f6aa8256fe38c4e45757` | Shared CCTP forwarding infrastructure on HyperEVM |
| Reward treasury | `0xf79ea59b856b0aadfc2948fa1a700e762dcbd3cd` | Outcome programme payout address |
| Outcome builder | `0xab5dbc057628bc18523c4cdfc0e1e2ebdbecb704` | Official reward-eligible builder code |
| Core/EVM system address | `0x2000000000000000000000000000000000000000` | HyperCore bridge system address |
| Outcome venue deployer | `0x0c46eb73fae2816f219fcf11f50d6d3c59b5819e` | Live deployer for venue `out` in captured `outcomeMeta` |
| Documentation-listed deployer | `0x423d7f725ae7056f03f7ef57f9d0303f91c62e06` | Address published on Outcome's architecture page; differs from live venue metadata |

Addresses identify onchain accounts, not people. References to A and B do not imply that the same person controls both private keys.

## 3. How the trading mechanism works

Outcome uses a merged binary order book. Buying YES at 0.40 can match someone buying NO at 0.60. One YES token and one NO token form a complete set worth 1 USDC at settlement. This is documented in Outcome's [order-book guide](https://github.com/Outcome-xyz/mintlify-docs/blob/main/reading-the-order-book.mdx) and [token and pricing guide](https://github.com/Outcome-xyz/mintlify-docs/blob/main/outcome-tokens-and-pricing.mdx).

This has an important forensic consequence:

- A YES price and a NO price summing to 1 is expected protocol behaviour.
- The same execution time, quantity and hash are also expected for opposing legs of one match.
- Those facts are not suspicious in isolation.
- The evidence becomes significant because the same two wallets repeat the structure 26 times, finish with exactly mirrored inventory, participate in the same rewarded markets, and directly recycle capital from A to B.

The pattern should therefore be described as repeated reciprocal or circular execution, not as a protocol anomaly.

## 4. First verified wallet activity

The dates below are the earliest events identified across the reviewed public records, not proof of private-key creation. An inbound transfer shows when an address was first touched; it does not prove owner control. The review covered major public EVM mainnets and separately checked Hyperliquid fills and ledger activity, but it cannot exclude earlier activity on an unreviewed or unindexed network.

| Wallet | Earliest verified public-chain appearance | Earliest verified owner-signed action | Earliest verified Hyperliquid activity |
| --- | --- | --- | --- |
| **A** `0xbcc3...41b1` | 6 February 2025, 15:17:11 UTC; received 0.03536 ETH from an address labelled `MEXC 16` by Etherscan. [Transaction](https://etherscan.io/tx/0x2a7f25864f33762d1b8d17c7364b227d64095357ba89aa61cd096c1e34ca3bba) | 6 February 2025, 15:20:59 UTC; Ethereum nonce 0, an ENS commitment later associated with `0xvelka.eth`. [Transaction](https://etherscan.io/tx/0x06a8755c2823a5cd57b61f872def922ad1adb8dddd1aa888dddf5017936bc83c) | Signed deposit of 100 USDC on 28 August 2025, 18:45:14 UTC. [Transaction](https://arbiscan.io/tx/0x660d8e89cbda0a9993bcf779c56b4c8d1c5bae60a272bb61a316629f918382cc). First returned fill: 23 September 2025, 16:35:47.557 UTC. |
| **B** `0x4b67...ccba` | 26 January 2023, 23:12:59 UTC; received 9.9 MATIC (now POL) from an address labelled `Binance 48` by PolygonScan. [Transaction](https://polygonscan.com/tx/0xb8145078ce03d1662795fa1d1149b9da153cf6a21850eb7d6fc523b310de1959) | 27 January 2023, 10:11:23 UTC; Ethereum nonce 0, an NFT approval. [Transaction](https://etherscan.io/tx/0xf57dcf1e129a2cdcdc9077f9260ba0c8575368887b51dc717440614a691b9242) | Signed deposit of 200 USDC.e on 19 December 2023, 19:33:36 UTC. [Transaction](https://arbiscan.io/tx/0xecb2719249235c935ddad641dbd959ae85d7c975e62f731cd47b29ad64bfe6d9). First returned fill: 20 February 2024, 19:20:26.456 UTC. |

## 5. Execution findings

### 5.1 Aggregate results

| Metric | Result |
| --- | ---: |
| Raw fill rows in examined window, A | 52 |
| Raw fill rows in examined window, B | 49 |
| Buy fill rows in examined window, A / B | 34 / 31 |
| Settlement rows in examined window, A / B | 18 / 18 |
| Paired executions in examined window | 26 |
| Distinct Outcome markets | 16 |
| Paired complete sets in examined window | 202,049 |
| A as taker | 7 |
| B as taker | 19 |
| Paired orders using Limit/GTC | 26 of 26 |
| Maker orders with positive rest time | 26 of 26 |
| Minimum maker rest | 0.736 seconds |
| Median maker rest | 1.543 seconds |
| Maximum maker rest | 18.852 seconds |
| Taker submission-to-fill latency | 0 milliseconds for all 26 at the API's timestamp precision |
| Final maker-order status | 24 filled; 2 cancelled after partial fill |
| Fragmented smaller fill rows | 13 |
| Additional equal inventory per wallet | 1,842 shares |
| Fragmented-fill purchase notional | 1,845.420 USDC |
| Markets with exact mirrored final inventory | 16 of 16 |

Every paired execution placed A and B on opposite sides of the same binary market. One wallet first submitted a Limit/GTC order. The other crossed it after a short but positive interval.

This corrects one key statement in the memo. The paired maker orders did rest. They rested for between 0.736 and 18.852 seconds. A later snapshot showing zero open orders only proves that no order remained open at that later moment.

### 5.2 Representative executions

| Time (UTC, 2026) | Market | Size | Wallet A | Wallet B | Taker | Maker rest |
| --- | ---: | ---: | --- | --- | --- | ---: |
| 29 Aug 19:54:52.442 | O1231 | 1,959 | YES at 0.51 | NO at 0.49 | B | 18.852s |
| 2 Sep 21:30:35.413 | O1366 | 20,000 | NO at 0.20 | YES at 0.80 | A | 0.736s |
| 3 Sep 21:59:28.760 | O1409 | 20,000 | YES at 0.79 | NO at 0.21 | B | 1.355s |

The full 26-row execution table appears in Appendix A.

### 5.3 Fragmented smaller fills

Thirteen smaller rows did not pair row-for-row under the strict hash rule. They were limited to O1345 and O1383:

- A accumulated 1,842 additional YES shares.
- B accumulated 1,842 additional NO shares.
- The combined purchase notional was 1,845.420 USDC.
- The resulting inventory still matched exactly across the two wallets.

The memo quoted 2,451 USDC for these fills. That figure could not be reproduced.

### 5.4 Mirrored inventory

All 16 examined markets ended with exact mirror positions. Examples:

| Market | Wallet A | Wallet B |
| --- | --- | --- |
| O1347 | 20,000 YES and 23,000 NO | 23,000 YES and 20,000 NO |
| O1409 | 25,000 YES and 32,000 NO | 32,000 YES and 25,000 NO |
| O1388 | 15,000 YES | 15,000 NO |
| O1366 | 24,000 NO | 24,000 YES |

Settlement paid 1 USDC per winning share and 0 USDC per losing share. Taken as a cluster, the pair had almost no directional exposure. Its combined gross settlement result was a loss of 3.42 USDC before reported fees.

## 6. Economic reconstruction

| Item | Wallet A | Wallet B | Combined |
| --- | ---: | ---: | ---: |
| Purchase notional | 92,729.430000 | 111,164.990000 | 203,894.420000 |
| Gross settlement PnL | +15,011.570000 | -15,014.990000 | **-3.420000** |
| Reported settlement fees | 144.803904 | 129.225600 | **274.029504** |
| Net trading result after reported fees | +14,866.766096 | -15,144.215600 | **-277.449504** |
| Rewards paid | 216.884273 | 306.609328 | **523.493601** |
| Additional finalised awards | 49.032943 | 6.713842 | **55.746785** |
| Total awarded at cut-off | 265.917216 | 313.323170 | **579.240386** |

Before rewards, the cluster lost **277.449504 USDC**. Paid rewards exceeded that cost by:

```text
523.493601 - 277.449504 = 246.044097 USDC
```

If the additional finalised awards are paid, the scoped apparent surplus becomes:

```text
579.240386 - 277.449504 = 301.790882 USDC
```

The comparison excludes network gas, bridge costs, and PnL from unrelated activity. Accordingly, **246.044097 USDC** is a scoped apparent surplus, not a complete net-profit figure. The supported conclusion is that the examined trading was loss-making before incentives and that paid rewards exceeded the reconstructed trading loss before excluded costs.

## 7. Direct capital route from Wallet A to Wallet B

This is the strongest linkage in the investigation.

```mermaid
flowchart LR
    A1["Wallet A on HyperCore<br/>Withdraws 22,999.99 USDC<br/>17:59:45 UTC"]
    A2["Wallet A on Arbitrum<br/>Receives 22,999.79 USDC"]
    B1["Wallet B on Base<br/>Receives 22,997.488700 USDC<br/>via Across"]
    B2["Wallet B on Arbitrum<br/>Receives 22,997.388700 USDC"]
    B3["Wallet B on HyperCore<br/>Credited 22,997.193009 USDC<br/>18:36:26 UTC"]

    A1 --> A2 --> B1 --> B2 --> B3
```

### 7.1 Reconstructed route

| Time (UTC), 3 September 2026 | Step | Amount | Evidence |
| --- | --- | ---: | --- |
| 17:59:45.461 | A withdraws from HyperCore to the Core/EVM system address | 22,999.990000 | [HyperCore transaction](https://app.hyperliquid.xyz/explorer/tx/0x3eb068fb64a76e12402a04439c51dc02026600e0ffaa8ce4e279144e23ab47fc) |
| 17:59:54 | Circle CCTP mints to A on Arbitrum | 22,999.790000 | [Arbitrum transaction](https://arbiscan.io/tx/0xd539c00def19389f02ed3b6a743981db7259d8bf55eea514a7b75cf551143abe) |
| 18:03:29 | A signs an Across deposit on Arbitrum, naming B as Base recipient | 22,997.488700 output | [Arbitrum transaction](https://arbiscan.io/tx/0xa17fdcb6047e0102e72cd41dee646c10a993bc810fb28fc2c9ebacc271e0be80) |
| 18:03:33 | Across fills the relay to B on Base | 22,997.488700 | [Base transaction](https://basescan.org/tx/0x281042ec0c032dce63b0915664499bde7409ee821a8d3a7331d5ab648e165d61) |
| 18:05:07 | B signs a CCTP burn from Base to Arbitrum | 22,997.388700 | [Base transaction](https://basescan.org/tx/0x7cc1b6332b89755d164dbf8e2197b0882dd98a06cba6a7a374b6f1ff2877d633) |
| 18:27:45 | CCTP mints to B on Arbitrum | 22,997.388700 | [Arbitrum transaction](https://arbiscan.io/tx/0xd5e9a2f6828750a1203773bd03cb94286d287430fb1b40f020f3cda210d7bf15) |
| 18:36:20 | B signs a CCTP burn from Arbitrum to HyperCore | 22,997.393009 | [Arbitrum transaction](https://arbiscan.io/tx/0x6ed2fafafbd5900ff66678a1b91fd5729110fbc6c87ef16a4d643f5e7dfc03e2) |
| 18:36:26.407 | B receives the HyperCore credit | 22,997.193009 | HyperEVM [forward transaction](https://hyperevmscan.io/tx/0xbdbab77d5fd73b2ea13f23374d965520d5e4964845792fd95283a1ce1da47378), [HyperCore credit](https://app.hyperliquid.xyz/explorer/tx/0x1fab7876dceaba6a212504439ccade0000e6905c77edd93cc37423c99bee9454) |

The route took **36 minutes and 40.946 seconds** from A's HyperCore withdrawal to B's HyperCore credit. The difference between the opening withdrawal and final credit was **2.796991 USDC**, before native-chain gas accounting.

The Across `FundsDeposited` event explicitly records A as depositor, B as recipient, Arbitrum as origin and Base as destination. The Base `FilledRelay` event repeats the same depositor, recipient and deposit ID `4,604,805`. B then signed both CCTP source transactions used to move a near-equivalent amount into HyperCore.

This establishes an intentional, recipient-directed value transfer from A to B. Because USDC is fungible and intermediate balances differ slightly, this is a reconstructed value route rather than a trace of unique coin units. It does not prove that one person controlled both keys.

Decoded bridge-event identifiers:

| Chain | Across SpokePool | Event topic |
| --- | --- | --- |
| Arbitrum | `0xe35e9842fceaca96570b734083f4a58e8f7c5f2a` | `0x32ed1a409ef04c7b0227189c3a103dc5ac10e775a15b785dcc510201f7c25ad3` |
| Base | `0x09aea4b2242abc8bb4bb78d537a67a245a7bec64` | `0x44b559f101f8fbcc8a0ea43fa91a05a729a5ea6e14a7c75aa750374690137208` |

### 7.2 Circle message identifiers

| Leg | Source domain | Destination domain | CCTP nonce |
| --- | ---: | ---: | --- |
| HyperEVM/HyperCore to Arbitrum | 19 | 3 | `0xc8ece1769e7663bf60ee3eee5144502326a65f23719fb6776f451d725a7f15c3` |
| Base to Arbitrum | 6 | 3 | `0x44c58ef609968f2d4f74937895b20466dd893f778d67b58b19df4306a8774b12` |
| Arbitrum to HyperCore | 3 | 19 | `0x9335bc02f4d283b750b9ef176c077e6535fee6b2dee99e82b60c83e347065b2a` |

These identifiers make each CCTP leg independently reproducible through Circle's messages API.

## 8. Funding analysis

### 8.1 Why `0x6b9e...0a24` is not a common private funder

The community memo treats `0x6b9e...0a24` as a wallet that may connect A, B and the reward treasury. That interpretation is incorrect.

Circle's [HyperCore contract register](https://developers.circle.com/cctp/references/hypercore-contract-addresses) identifies `0x6B9E773128f453f5c2C60935Ee2DE2CBc5390A24` as the mainnet HyperEVM `CoreDepositWallet`. Circle's [contract interface](https://developers.circle.com/cctp/references/coredepositwallet-contract-interface) explains that it deposits USDC into HyperCore and credits the selected recipient.

Complete pagination for the examined period confirms infrastructure behaviour. The first and last returned ledger rows in the captured period were timestamped 29 August 2026, 00:00:28.057 UTC and 4 September 2026, 08:34:27.455 UTC.

| Metric | Result |
| --- | ---: |
| Ledger rows in examined window | 71,864 |
| Incoming transfers | 35,932 |
| Outgoing transfers | 35,932 |
| Incoming USDC | 685,325,358.485525 |
| Outgoing USDC | 685,325,358.485525 |
| Unique outgoing destinations | 21,196 |
| Adjacent equal-amount in/out routes | 33,362 |
| Median route delay | 349 milliseconds |

A shared system contract must be excluded from ownership clustering. Treating this address as a common funder would create thousands of false links.

All six A/B CCTP deposits processed through this infrastructure were initiated on Arbitrum by the corresponding recipient wallet:

| Recipient | Arbitrum source transaction | Gross CCTP amount | HyperCore credit |
| --- | --- | ---: | ---: |
| B | [`0xbb79...8613`](https://arbiscan.io/tx/0xbb79cd489b69aff505201dcb9d55a9863beb544aa1d2e4aebfdf2e7b5cc58613) | 4,999.800000 | 4,999.600000 |
| A | [`0x2c73...63dd`](https://arbiscan.io/tx/0x2c73d6d89b63abdbfdbaa90a7dd03920a96188b6673778575095bbfd3dac63dd) | 4,999.800000 | 4,999.600000 |
| A | [`0x12eb...0b55`](https://arbiscan.io/tx/0x12eb9dde323d0d9b30498342d4d878438cff7455078015a9e1c6b1a9305d0b55) | 9,999.990375 | 9,999.790375 |
| B | [`0x8c79...4b98`](https://arbiscan.io/tx/0x8c79f0926936b31054d3d2d10803e0720fd1d823c94af9be9c5d561daeda4b98) | 19,342.095253 | 19,341.895253 |
| A | [`0xd485...f9d0`](https://arbiscan.io/tx/0xd4850fda99ff4dbec5ee8dcee1ef0ab40fad2dbef35a188d2916190a5303f9d0) | 17,896.282015 | 17,896.082015 |
| B | [`0x6ed2...03e2`](https://arbiscan.io/tx/0x6ed2fafafbd5900ff66678a1b91fd5729110fbc6c87ef16a4d643f5e7dfc03e2) | 22,997.393009 | 22,997.193009 |

This rules out `0x6b9e...0a24` as the alleged private common funder. It does not identify every upstream beneficial funding source.

### 8.2 Coordinated campaign funding

At the start of the examined campaign window, A and B each received a net HyperCore credit of **4,999.6 USDC**, 14.016 seconds apart:

| Wallet | HyperCore credit time | Net credit | Arbitrum CCTP source signer |
| --- | --- | ---: | --- |
| B | 29 Aug 2026, 19:52:24.381 UTC | 4,999.600000 | Wallet B, tx [`0xbb79...8613`](https://arbiscan.io/tx/0xbb79cd489b69aff505201dcb9d55a9863beb544aa1d2e4aebfdf2e7b5cc58613) |
| A | 29 Aug 2026, 19:52:38.397 UTC | 4,999.600000 | Wallet A, tx [`0x2c73...63dd`](https://arbiscan.io/tx/0x2c73d6d89b63abdbfdbaa90a7dd03920a96188b6673778575095bbfd3dac63dd) |

Immediately before these burns, both wallets received 4,999.8 USDC from the same StrategyExecutor smart account, approximately 50 seconds apart. The account's native owner is labelled as Binance infrastructure by public explorers:

- B receipt: [Arbitrum transaction `0xfe70...a3b`](https://arbiscan.io/tx/0xfe706f637be65338b50bbb82663d320c38ee986c639bd7830227008252082a3b)
- A receipt: [Arbitrum transaction `0x645c...be9`](https://arbiscan.io/tx/0x645c66ef0019d1cf8076129de48ed1bbeb7d17b90e7132ae7b8e50fff857cbe9)

The sending StrategyExecutor proxy is [`0xee7...4055`](https://arbiscan.io/address/0xee7ae85f2fe2239e27d9c1e23fffe168d63b4055). Its onchain native-owner value is [`0xB38e...891D`](https://arbiscan.io/address/0xB38e8c17e38363aF6EbdCb3dAE12e0243582891D), which public explorer labels associate with Binance. The label is supporting attribution, not identity evidence for A or B.

The close timing and equal amounts support coordinated preparation. They do not prove common ownership because the source is high-volume exchange infrastructure. Exchange hot wallets and strategy executors serve many unrelated customers.

### 8.3 Treasury ledger

The rewards treasury ledger for the examined window contained 6,783 rows, with 6,773 outgoing payments and 10 incoming transfers. Seven incoming transfers totalling 51,167.6 USDC came through the Circle deposit route. Three additional transfers totalling 15.2 USDC came from `0x047a1c608406972d7c26132f189bbfb0cfefd413`.

The memo's statement that `0x6b9e...0a24` was the treasury's only funding source is therefore false even at ledger level. More importantly, the address is infrastructure rather than an owner.

## 9. Rewards and apparent motive

Outcome's published programme allocates each market reward as follows:

| Reward component | Share |
| --- | ---: |
| Displayed quote depth | 40% |
| Maker fills | 30% |
| Taker fills | 30% |

Both wallets approved the official Outcome builder address and earned programme rewards. Agent metadata captured at the evidence cut-off showed separate Outcome agent keys for A and B:

| Wallet | Outcome-named agent | Other visible agents | Official Outcome builder approved |
| --- | --- | --- | --- |
| A | `0xc21873ae63b5a95795e90b3e8cf8803307a0c213` | None shown in the captured `extraAgents` response | Yes |
| B | `0x80823eefbbbbfa1faed202bb5b3b603e21b43aaf` | `rabby-agent`, `quote` | Yes |

Separate agent keys do not establish separate beneficial owners. They show only that the two main accounts were configured separately at the time of the query. Agent approvals can change, so this snapshot does not prove which keys were used during the campaign.

### 9.1 Paid and pending rewards

| Wallet | Paid | Pending at cut-off | Total awarded | Sent payments |
| --- | ---: | ---: | ---: | ---: |
| A | 216.884273 | 49.032943 | 265.917216 | 9 |
| B | 306.609328 | 6.713842 | 313.323170 | 10 |
| **Combined** | **523.493601** | **55.746785** | **579.240386** | **19** |

The public reward service defines paid USDC as value already transferred from the treasury and pending USDC as finalised awards not yet swept. The values above are a point-in-time snapshot and can change.

The paginated treasury capture preceded Wallet B's O1409 payment and showed nine payments to B totalling 236.111634 USDC. The later reward-service snapshot at 09:15:59 UTC includes the O1409 payment sent at 09:15:21.961 UTC, bringing B to ten payments and 306.609328 USDC paid. The table therefore uses the later reward-service snapshot; the two captures are temporally consistent rather than simultaneous.

<details>
<summary>Per-market reward allocation at the evidence cut-off</summary>

| Market | Wallet A | Wallet B | Combined | Status |
| --- | ---: | ---: | ---: | --- |
| O1223 | 42.516976 | 30.622617 | 73.139593 | sent |
| O1224 | 14.511054 | 5.218554 | 19.729608 | sent |
| O1225 | 46.460620 | 45.719232 | 92.179852 | sent |
| O1231 | 11.803031 | 21.972003 | 33.775034 | sent |
| O1232 | 25.107478 | 23.564028 | 48.671506 | sent |
| O1299 | 19.914471 | 17.465827 | 37.380298 | sent |
| O1345 | 6.088725 | 10.885456 | 16.974181 | sent |
| O1347 | 36.738387 | 45.474719 | 82.213106 | sent |
| O1366 | 13.743531 | 35.189198 | 48.932729 | sent |
| O1383 | 0.005277 | 0.597632 | 0.602909 | pending |
| O1384 | 0.032498 | 0.554614 | 0.587112 | pending |
| O1386 | 0.007370 | 2.841700 | 2.849070 | pending |
| O1388 | 3.102175 | 1.127603 | 4.229778 | pending |
| O1389 | 0.062195 | 0.790489 | 0.852684 | pending |
| O1390 | 0.050258 | 0.801804 | 0.852062 | pending |
| O1409 | 45.773170 | 70.497694 | 116.270864 | A pending, B sent |
| **Total** | **265.917216** | **313.323170** | **579.240386** | mixed |

</details>

Wallet B's O1409 allocation moved from pending to sent at 09:15:21.961 UTC, 37 seconds before the evidence cut-off. Wallet A's O1409 allocation remained pending. This illustrates why payout status must always be tied to a precise snapshot time.

### 9.2 Rules in force

The published [Outcome liquidity-reward rules](https://github.com/Outcome-xyz/mintlify-docs/blob/main/outcome-liquidity-rewards.mdx) state that the following activity does not score:

> self-trading, related-wallet churn, wash trading or circular volume

The exclusion language appeared in [commit `56cd9a2`](https://github.com/Outcome-xyz/mintlify-docs/commit/56cd9a25824fa8e3e09a9f5f55f6b2ab4be7936a), committed on 28 August 2026 at 21:54:29 UTC. This predates the first examined paired execution by just over 22 hours.

Public records show that rewards were nevertheless awarded and paid. They cannot show whether an authorised exception existed. In the absence of a documented exception, this points to a reward-screening and enforcement gap.

## 10. Wallet history and ownership signals

Both wallets had verified public-chain and Hyperliquid activity before the examined campaign. Wallet A first appeared in the reviewed public-chain records on 6 February 2025, signed its first identified transaction minutes later, deposited to Hyperliquid on 28 August 2025, and had its first returned fill on 23 September 2025. Wallet B first appeared in the reviewed public-chain records on 26 January 2023, signed its first identified transaction the next day, deposited to Hyperliquid on 19 December 2023, and had its first returned fill on 20 February 2024.

The returned Hyperliquid histories contained 18 pre-window fills for Wallet A and 375 for Wallet B across BTC, ETH, HYPE, and other products.

This disproves the memo's global statement that the wallets only traded against each other. It does not weaken the evidence of coordination during the Outcome campaign. Existing wallets can later be coordinated, delegated or operated through a shared service.

No shared, non-zero execution hash was found in the returned pre-campaign fill histories. This limits the publicly demonstrated coordination period to the activity examined here. It does not identify when the relationship began.

### 10.1 What links A and B

The strongest linkage factors are:

1. Twenty-six opposing fills with the same millisecond, hash, market and quantity
2. Complementary prices and exact mirrored inventory across all 16 examined markets
3. Repeated short sequence of maker order followed by the other wallet's crossing order
4. Equal, near-simultaneous campaign funding
5. A direct, signed A-to-B cross-chain transfer of approximately 23,000 USDC
6. Both wallets received programme rewards in markets where the reciprocal activity occurred

### 10.2 What does not link A and B to Outcome personnel

No public evidence connected either wallet to:

- the live `out` venue deployer or the separate documentation-listed deployer
- a founder or employee address
- the reward treasury's control keys
- a team funding wallet
- a public identity belonging to Outcome personnel
- access to nonpublic market information

The Circle deposit contract cannot be used for that purpose. Builder approval also cannot be used as an ownership link because it is required for ordinary reward eligibility.

## 11. Timing and geographic attribution

The memo's timing characterisation is incorrect. Of the 26 paired executions:

- 10 occurred less than one hour before the relevant market expiry.
- 4 occurred between one and three hours before expiry.
- 12 occurred more than three hours before expiry.
- The full range was 3 minutes 22.787 seconds to 23 hours 27 minutes 30.283 seconds before expiry.

The activity clustered around scheduled markets, including a session around 11:48 UTC and sessions from roughly 18:45 to 22:01 UTC. This is consistent with automation and awareness of incentive or expiry schedules. It does **not** support a country or time zone inference.

## 12. Community memo reconciliation

| Memo claim | Result | Reason |
| --- | --- | --- |
| 26 paired executions totalling 202,049 complete sets | **Validated** | Reproduced exactly from public fills |
| A and B took complementary sides | **Validated** | Same hash, time, size and market; YES plus NO price equals 1 |
| Both wallets received rewards | **Validated** | Treasury and reward-service snapshots reconcile when the later B payment is aligned by timestamp |
| `0x6b9e...0a24` is a common private funder | **Rejected** | It is Circle's public CoreDepositWallet |
| Neither wallet placed resting orders | **Rejected** | All 26 maker orders had positive rest time |
| All activity occurred one to three hours before expiry | **Rejected** | Only 4 of 26 executions fall in that range |
| Smaller unpaired fills totalled 2,451 USDC | **Rejected** | Reproduced purchase notional is 1,845.420 USDC |
| The wallets only traded against each other | **Rejected globally** | Both have older unrelated Hyperliquid history |
| Pair lost only fees | **Incomplete** | Gross PnL was -3.42 USDC before 274.029504 USDC of reported fees |
| Size distribution in the memo | **Arithmetic error** | It omitted the 12,000 trade and overstated the count of 5,000 trades |
| Market-share percentages | **Not relied upon** | The numerator and denominator semantics were not sufficiently defined |
| Timing can reveal geography | **Unsupported** | Public timestamps do not identify operator location |
| Activity proves insider involvement | **Unsupported** | No public identity or information-access link was found |

## 13. Alternative explanations

| Scenario | Assessment | What would resolve it |
| --- | --- | --- |
| One operator controlling both wallets | **Plausible** | KYC, device, API-agent, request and signature records |
| Two users coordinating deliberately | **Plausible** | Identity correlation and communications evidence |
| Shared bot or delegated trading service | **Possible** | Historical API-key and agent-registration data |
| Compromised wallet credentials | **Possible but unsupported** | Security, login and recovery records |
| Independent legitimate market makers | **Very unlikely** | A credible explanation for the direct transfer and repeated reciprocal fills |
| Authorised liquidity or test activity | **Unsubstantiated publicly** | Internal agreement, mandate or written exception |
| Employee involvement | **No public evidence** | Internal identity and access correlation |
| Pure coincidence | **Extremely unlikely** | The direct A-to-B transfer and 26 exact paired executions are incompatible with ordinary coincidence |

The most likely explanations are either one operator using two wallets or two users deliberately cooperating. Public records cannot distinguish those two cases.

Terms such as circular and wash-like describe the observed mechanics. Any statutory or regulatory classification should be handled separately by counsel.

## 14. Final finding

The public record supports deliberate coordination between Wallet A and Wallet B at high confidence. It directly establishes a transfer of approximately 23,000 USDC from A to B, followed by B moving a near-equivalent amount into HyperCore.

The trading pattern is consistent with reward farming through matched complementary positions. At cluster level, paid rewards exceeded the reconstructed trading loss before bridge charges, native gas and unrelated activity. The activity is also consistent with categories excluded by the published programme rules.

The evidence does not establish common beneficial ownership, employee involvement, access to nonpublic information, or geographic origin.

---

## Appendix A: All 26 paired executions

| # | Time (UTC) | Market | Size | Wallet A | Wallet B | Taker | Maker rest | HyperCore execution hash |
| ---: | --- | ---: | ---: | --- | --- | --- | ---: | --- |
| 1 | 2026-08-29 19:54:52.442 | O1231 | 1,959 | YES 0.51 | NO 0.49 | B | 18.852s | `0xdcfa701d92a7a54ade740443417d3602020400032daac41c80c31b7051ab7f35` |
| 2 | 2026-08-29 19:56:37.213 | O1223 | 1,850 | NO 0.46 | YES 0.54 | A | 15.888s | `0xa007fac04de0e2f5a18104434182f501dd0012a5e8e401c743d0a6130ce4bce0` |
| 3 | 2026-08-29 20:16:08.888 | O1232 | 2,000 | YES 0.50 | NO 0.50 | B | 7.262s | `0x1161877c07c80cb312db044341c3a501bb009f61a2cb2b85b52a32cec6cbe69d` |
| 4 | 2026-08-29 20:17:44.643 | O1225 | 961 | YES 0.52 | NO 0.48 | B | 6.293s | `0x3fa249b252634764411c044341c8c402011a0097ed666636e36af5051167214e` |
| 5 | 2026-08-29 20:21:15.484 | O1224 | 609 | YES 0.82 | NO 0.18 | B | 8.468s | `0xdd388ed87d914307deb2044341d4930201fa00be189461d981013a2b3c951cf2` |
| 6 | 2026-08-29 20:40:19.480 | O1225 | 2,212 | YES 0.52 | NO 0.48 | B | 9.626s | `0x8a1bf36a4f95aa848b95044342127602016b004fea98c9562de49ebd0e99846f` |
| 7 | 2026-09-01 19:45:05.070 | O1299 | 8,800 | YES 0.50 | NO 0.50 | A | 5.968s | `0x8d19bfa5be4559f28e93044378c65c020290008b594878c430e26af87d4933dd` |
| 8 | 2026-09-02 11:48:04.431 | O1347 | 15,000 | NO 0.612 | YES 0.388 | B | 7.126s | `0xb5bb4c404ff0bd30b7350443851d130201900025eaf3dc025983f7930ef4971b` |
| 9 | 2026-09-02 11:50:39.193 | O1345 | 4,658 | YES 0.45 | NO 0.55 | B | 5.649s | `0x1321ce4d15583cc3149b04438525b10202c00032b05b5b95b6ea799fd45c16ad` |
| 10 | 2026-09-02 20:39:54.296 | O1347 | 10,000 | YES 0.66 | NO 0.34 | B | 1.812s | `0x1d580fd524cb3f271ed104438bf1d902010700babfce5df9c120bb27e3cf1911` |
| 11 | 2026-09-02 20:42:18.153 | O1347 | 10,000 | YES 0.69 | NO 0.31 | B | 1.480s | `0xcc51bdb8473a42b3cdcb04438bf9d101ee00d59de23d6185701a690b063e1c9e` |
| 12 | 2026-09-02 20:45:11.429 | O1347 | 8,000 | NO 0.50 | YES 0.50 | A | 1.164s | `0x285349291344def029cd04438c037d01fb00610eae47fdc2cc1bf47bd248b8da` |
| 13 | 2026-09-02 21:30:35.413 | O1366 | 20,000 | NO 0.20 | YES 0.80 | A | 0.736s | `0xc40060451755f441c57a04438c9673019600782ab259131367c90b97d659ce2c` |
| 14 | 2026-09-02 21:32:29.717 | O1390 | 5,000 | YES 0.493 | NO 0.507 | B | 1.016s | `0x76a1de4e9ed412b9781b04438c9cad02032c003439d7318b1a6a89a15dd7eca4` |
| 15 | 2026-09-02 21:33:18.866 | O1389 | 5,000 | YES 0.506 | NO 0.494 | B | 1.606s | `0xcf8fd1f7f56af954d10904438c9f4002015e00dd906e182673587d4ab46ed33f` |
| 16 | 2026-09-02 21:34:09.594 | O1388 | 5,000 | YES 0.505 | NO 0.495 | B | 0.936s | `0x64ebe88d36bd1d3f666504438ca1df0201e00072d1b03c1108b493dff5b0f72a` |
| 17 | 2026-09-02 21:35:05.812 | O1384 | 5,000 | NO 0.53 | YES 0.47 | B | 1.002s | `0xff697a48b490e76200e304438ca4da020147002e4f940635a332259b7394c14d` |
| 18 | 2026-09-02 21:38:20.996 | O1366 | 4,000 | NO 0.195 | YES 0.805 | A | 1.011s | `0x1207e62353e5dfbb138104438caf280201fe0008eee8fe8db5d0917612e9b9a5` |
| 19 | 2026-09-03 18:45:14.632 | O1388 | 1,000 | YES 0.84 | NO 0.16 | B | 0.814s | `0x4b9f7a04280708e74d1904439ce85302057900e9c30a27b9ef682556e70ae2d1` |
| 20 | 2026-09-03 18:45:30.369 | O1388 | 9,000 | YES 0.84 | NO 0.16 | B | 16.551s | `0x029d0937adf7cfe0041604439ce92c020233001d48faeeb2a665b48a6cfba9ca` |
| 21 | 2026-09-03 18:47:14.402 | O1386 | 20,000 | NO 0.14 | YES 0.86 | B | 1.075s | `0x0c59dabee37bb0c30dd304439ceebf02022c00a47e7ecf95b0228611a27f8aad` |
| 22 | 2026-09-03 18:48:18.306 | O1383 | 5,000 | YES 0.33 | NO 0.67 | B | 0.912s | `0x3ee969e7547f1fc9406304439cf22402020300ccef723e9be2b2153a1372f9b3` |
| 23 | 2026-09-03 21:58:34.857 | O1409 | 20,000 | NO 0.19 | YES 0.81 | B | 1.294s | `0x9bb5ce2b3dd078799d2f04439f633f0202420010d8d3974b3f7e797dfcd45264` |
| 24 | 2026-09-03 21:59:28.760 | O1409 | 20,000 | YES 0.79 | NO 0.21 | B | 1.355s | `0x07c2685b4f3c8437093c04439f664b02018c0040ea3fa309ab8b13ae0e305e21` |
| 25 | 2026-09-03 22:00:29.977 | O1409 | 12,000 | NO 0.20 | YES 0.80 | A | 1.733s | `0x576f74ed37c7973258e904439f698502065b00d2d2cab604fb38203ff6cb711c` |
| 26 | 2026-09-03 22:01:09.296 | O1409 | 5,000 | YES 0.80 | NO 0.20 | A | 1.412s | `0x99c65b97d02951e29b4004439f6bc10207a5007d6b2c70b43d8f06ea8f2d2bcd` |

## Appendix B: strict reconstruction logic

The core pairing condition can be reproduced as:

```text
pair(A_fill, B_fill) when:
    A_fill.time == B_fill.time
    and A_fill.hash == B_fill.hash
    and market(A_fill.coin) == market(B_fill.coin)
    and side(A_fill.coin) != side(B_fill.coin)
    and A_fill.size == B_fill.size
    and A_fill.price + B_fill.price == 1
```

Maker rest time was calculated as:

```text
maker_rest_ms = fill.time_ms - historical_order.timestamp_ms
```

Every identified maker rest time was positive.

Prices were parsed and compared using exact decimal arithmetic rather than binary floating-point arithmetic.

## Appendix C: reproducible public queries

### Hyperliquid fills

`POST https://api.hyperliquid.xyz/info`

```json
{
  "type": "userFillsByTime",
  "user": "0xbcc3237bb9b0468c32fabb7f000b799be33441b1",
  "startTime": 1787961600000,
  "endTime": 1788566400000,
  "aggregateByTime": false
}
```

All wallet-specific queries in this appendix were repeated with Wallet B by substituting `0x4b67c7f8893bd8fbc819fa57b9dd9dde0b03ccba` for the `user` value. The requested end boundary was 5 September 2026, 00:00 UTC so the capture included all records available during 4 September.

### Historical orders

```json
{
  "type": "historicalOrders",
  "user": "0xbcc3237bb9b0468c32fabb7f000b799be33441b1"
}
```

### Non-funding ledger

```json
{
  "type": "userNonFundingLedgerUpdates",
  "user": "0xbcc3237bb9b0468c32fabb7f000b799be33441b1",
  "startTime": 1787961600000,
  "endTime": 1788566400000
}
```

The ledger endpoint returns at most 2,000 rows per response. Complete reconstruction within a requested time window requires pagination with overlap-safe deduplication.

### Agents and builders

```json
{ "type": "extraAgents", "user": "0xbcc3237bb9b0468c32fabb7f000b799be33441b1" }
```

```json
{ "type": "approvedBuilders", "user": "0xbcc3237bb9b0468c32fabb7f000b799be33441b1" }
```

### Live Outcome metadata

```json
{ "type": "outcomeMeta" }
```

### Outcome rewards

```text
GET https://pd-liquidity-rewards-payouts.outcome-e91.workers.dev/v1/rewards/0xbcc3237bb9b0468c32fabb7f000b799be33441b1
GET https://pd-liquidity-rewards-payouts.outcome-e91.workers.dev/v1/rewards/0x4b67c7f8893bd8fbc819fa57b9dd9dde0b03ccba
```

### Circle CCTP messages

```text
GET https://iris-api.circle.com/v2/messages/{sourceDomain}?nonce={nonce}
```

Use source domains 19, 6 and 3 with the nonces listed in section 7.2.

## Appendix D: evidence hashes

| Evidence item | SHA-256 |
| --- | --- |
| Original community DOCX | `d77957855358aec5824b22a478f82121d6d320258d84a2e4cb81ee72a244597d` |
| Wallet A fills | `b3e6d893a8f1353ab3927349915322e399302a74b493c2bb85d49fa49e0c3cf0` |
| Wallet B fills | `1880be644b22794c018a5f9714db584dd9f20a0a990e5840828caf4f36e3e347` |
| Wallet A historical orders | `09157d43dd08d6d68f9455d656f62945965549699de378d5b182b486cbd9d6da` |
| Wallet B historical orders | `0110be80948845ea675dd04e75089f87bb5071127ab3846bcc78c1a2ec1536f4` |
| Wallet A ledger | `335829b007e12e58fbc50644f4a80c06e4238156729332dd96d5739be3f40e94` |
| Wallet B ledger | `a45dab4c0b17d179bc59de083b45dbe5a9772c86651bdaf831d7869c2840027c` |
| Circle infrastructure ledger | `51caf9a8abb3eb66f0e3d1860b9c0d347606735a66fc26e141cd372fcc15c559` |
| Reward treasury ledger | `5ad5b1b9a9aad4b32731f133e1e0ed5d5780dc8a7df62e0052b048823ac0c89d` |
| Paired executions | `de1c8e8ffc5919863884923d9b6af330b8a6a86fabd6cd32edf8c2270f8adcc5` |
| Fragmented fills | `ede991a62336ff44581f002c41e0fd14571c8b092a270f0e366866a4ad0e4080` |
| Mirrored positions | `8a39baa7b37f34598d4e6d7008fc45c44287f13b74665c94bf93393b857a94ba` |
| Settlement events | `4887ca33b390c8fc446d028c700788ac112fd9b5251fe7e874f82e0ce9eadae4` |
| Analysis summary | `2fa410aa8b01e032e51023118ecc166139666ba8b25b2d1f22a72c955390eb82` |
| Relevant wallet ledger rows | `28729508128d900c214f79161bc2674e885fb8f1fc453770dfb72e539b838ed8` |
| Live Outcome metadata | `4bf2ee27d4b6e68ed0cf32baef579b615342102a98f9b7659a7e0ec743505c48` |
| Reward, agent and builder snapshot at cut-off | `22d04804a81388219ea72edac667885425df8f1e77948eb45cd8ea1fbf1cf691` |
| CCTP source traces | `f1f380d6870b1c34ed0b17b363048f470b7f3d7aa322bb8c625e7a68ba0bf36e` |
| Core deposit EVM traces | `0d3b4d6b0b8fccde78f861615fcb2ba0130cc2bfb806a99152f543f5100bc9c7` |
| A-to-B route reconstruction | `0a4c9c767f827c1ee4710a9463b6e9b0172e3ac95af1a58eff7dfc19b7f1da6c` |
| Reconstruction script | `3d237c4570a87872e011ddcbb84a63ef3ddbf81b52a28d3207676fe48ff76c61` |

## Appendix E: limitations

Public data can establish transaction sequence, account signatures, contract interaction, fill structure, balances and reward transfers. It cannot by itself establish:

- the human or company behind an address
- whether two keys were held by one person
- physical location
- intent or private communications
- IP, device or browser identity
- historical API-key ownership beyond exposed agent metadata
- whether an internal authorisation or exception existed
- a legal finding of wash trading, fraud or insider trading

These limits are the reason this report reaches a strong finding on coordination and activity consistent with excluded circular reward farming, while keeping operator identity and internal involvement unresolved.

## Appendix F: primary references

- [Hyperliquid Info API documentation](https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/info-endpoint)
- [Circle HyperCore CCTP contract addresses](https://developers.circle.com/cctp/references/hypercore-contract-addresses)
- [Circle CoreDepositWallet interface](https://developers.circle.com/cctp/references/coredepositwallet-contract-interface)
- [Circle CCTP messages API](https://developers.circle.com/api-reference/cctp/all/get-messages-v2)
- [Outcome liquidity-reward rules](https://github.com/Outcome-xyz/mintlify-docs/blob/main/outcome-liquidity-rewards.mdx)
- [Reward exclusions commit](https://github.com/Outcome-xyz/mintlify-docs/commit/56cd9a25824fa8e3e09a9f5f55f6b2ab4be7936a)
- [Outcome architecture and documentation-listed addresses](https://github.com/Outcome-xyz/mintlify-docs/blob/main/outcome-architecture.mdx)
- [Outcome merged order-book explanation](https://github.com/Outcome-xyz/mintlify-docs/blob/main/reading-the-order-book.mdx)
- [Outcome complete-set pricing explanation](https://github.com/Outcome-xyz/mintlify-docs/blob/main/outcome-tokens-and-pricing.mdx)
- [Outcome reward API documentation](https://github.com/Outcome-xyz/hip4/blob/main/docs/OUTCOME-REWARDS.md)