Autheo / THEO: 119 Million Issued on Base, and a Request-Linked Route to Ethereum

Autheo says it discovered unauthorized issuance of its THEO token on October 12, followed by transfers to Base. Its October 13 notice describes a halt to origin-chain block production, validator nodes and the affected cross-chain relayer. The project has not yet confirmed the complete token count or financial impact. Autheo’s incident notice.

The public records examined here answer a narrower question: what can be established from two Base mints, a later sale, a bulk token transfer and an identified cross-chain payment? They show 19 million and 100 million THEO issued to the same wallet, a successful sale that returned ETH to that wallet, and a Relay deposit whose request identifier also appears in an Ethereum transaction paying that same address. A later transfer sent 93,510,011 THEO to a separate address. These are stages to distinguish, not quantities to add into one loss figure.

The main ETH route in brief is token issuance on Base → the receiving wallet’s sale through a swap contract → ETH deposited with Relay on Base → ETH paid to the same address on Ethereum. The bulk THEO transfer is a separate branch. The sale record is one selected conversion, and the cross-chain record is one selected deposit and payment. Neither is presented as the complete incident ledger. The 119 million figure is the exact sum of two mints to one recipient, not every mint on the route or a verified dollar loss.

Three findings guide the account. First, the two selected mint receipts establish 119 million THEO issued to one address, extending the initial 19 million alert without establishing a campaign-wide total. Second, an exact identifier match and the Ethereum payment logs connect one Base deposit with actual destination delivery. Third, neither that delivered amount nor the wallet’s whole balance establishes the incident’s net proceeds. The chronology below explains the evidence behind each distinction.

First, separate the token record from the people involved

THEO is a token: its contract keeps a ledger of who owns how many units. Minting creates units in that ledger. A transfer from the all-zero address is the usual accounting sign of a mint; it is not evidence that a real wallet at that address funded the recipient. ETH, or ether, is the native asset used on Base and Ethereum. Receiving ETH after a sale is a different event from receiving newly issued THEO.

The transaction submitter, the token contract and the mint recipient also have different roles. A wallet submitted a message-processing call to a contract on Base. The token contract recorded the issuance. A separate wallet received THEO and later submitted the sale. Calling the first wallet “the attacker” solely because it submitted a message would erase the unresolved question of whether it was a legitimate relayer processing an unauthorized origin-side event.

A relayer carries information between chains. It does not necessarily move the same physical token from one ledger to another. A destination system can act on a message and issue a local token representation. Establishing whether that issuance was authorized requires the source message and the verification rules in force at the time, not just a destination-side Transfer event.

Figure 1 is a route overview before the chronological account. Start with the blue issuance box, follow it to the receiving wallet, then read the two selected branches. The green branch pairs THEO sold with ETH received; the amber branch is a token transfer to another address. The layout groups roles rather than placing all transactions in time order.

Figure 1. Selected Base records, not a complete supply reconciliation. Equal-width arrows show issuance and transfer direction. Colors distinguish record roles, not levels of certainty or asset value. The sale amount is rounded to approximately 9.501 million THEO and its ETH receipt to six decimals; the native text and tables retain exact values. Sources: mint receipts, selected sale and bulk transfer in the appendix.

The overview shows why a receiving address is not automatically an owner cluster. THEO reaching a second address establishes a transfer, but not its control or consent. The next sections follow when the issuance, conversion and cross-chain payment actually occurred.

17:06:59 UTC: a message-processing call records a 19 million THEO mint

At Base block 52,517,736, a successful transaction called the function displayed by BaseScan as process(bytes _metadata, bytes _message). Its receipt contains a Process event with origin domain 2127, a ProcessId event, a ReceivedTransferRemote event and a THEO Transfer from the zero address to the receiving wallet. The last two events contain the same raw amount, 19000000000000000000000000. Dividing by the token’s displayed 18-decimal precision gives exactly 19,000,000 THEO. Mint receipt; token precision.

These logs place message processing and issuance inside the same successful transaction. The explorer’s decoded metadata field is empty. That observation does not, on its own, prove a verification bypass: a security module may use other state or caller rules. The origin domain and sender fields are data accepted in this execution, not independent proof of a corresponding backed transfer on the origin chain.

The next question is therefore about authority. Which security module and remote sender were configured at this exact block, and what origin-side record justified this message? Current proxy implementation fields cannot substitute for a historical configuration check. The selected receipt establishes issuance, while that authorization question remains open.

17:10–17:16 UTC: an unsuccessful attempt precedes a successful sale

The receiving wallet submitted a swap call at 17:10:21. It failed with the custom error SwapFailed. Its gas expenditure is real, but the failed transaction must not be counted as a completed token sale. Failed attempt.

At 17:16:13, a different call to the same swap contract succeeded. The overview records 9,501,032.606830209368510124 THEO moving from the wallet to that contract and 189.059271901143347167 ETH returning from the contract to the wallet. The transaction includes many intermediary token conversions and an internal-error warning, but its overall status is Success and its final transfers are recorded. An internal failed route is not the same thing as failure of the whole transaction. Successful conversion.

This is evidence of a conversion and a final ETH receipt, not a reason to add every intermediary USDC, WETH and ETH movement together. It also does not establish that every THEO unit sold originated in the selected 19 million mint. Earlier holdings and other token movements need their own reconciliation. The sale’s input is not simplified to exactly 9.5 million THEO in the evidence register.

17:18:15 UTC: ETH enters Relay on Base

Two minutes and two seconds after that successful conversion, the wallet sent 280.448146679916230118 ETH to an address BaseScan labels Relay: Depository. The deposit exceeds the ETH receipt from the single sale just discussed. It must therefore be read with the other receipts and starting funds, rather than attributed wholly to that one conversion.

The successful deposit’s log 227 names the sender, the exact native amount and a 32-byte request identifier. A request identifier is a reference that can help distinguish one cross-chain operation from another. It is stronger linking evidence than two transfers happening a few seconds apart or having similar amounts. Base deposit and request ID.

A deposit is still only the source-side record. It does not prove what arrived on Ethereum. To answer that question, the investigation must locate an actual destination transaction and check both its recipient and the reference connecting it to the deposit.

Eight seconds later: the Ethereum transaction records actual delivery

At Ethereum block 26,177,837, timestamped 17:18:23, a successful solver-submitted transaction paid 278.520848939786734261 ETH from the Relay: Router V3-labeled contract to the same hexadecimal address as the Base depositor. Logs 54 and 55 record the recipient and exact amount. The source deposit’s 32-byte identifier also appears as the final 32 bytes of this transaction’s input data. Ethereum payout logs; input data.

The destination’s decoded FundsMovement metadata is a different value. The matching source identifier was found in the transaction input, not in that event. This distinction matters for reproducibility. The evidence is an exact byte match plus an actual destination payout, rather than a claim that the explorer decoded the same identifier into both events.

This supports linking the selected deposit and payment without relying only on their timing. It is not a replay of Relay’s settlement system or a complete audit of its order records. The original order response would make the identifier’s service-level meaning independently checkable as well.

The two native amounts should not be added as separate losses. Nor should their difference automatically be called the bridge fee: solver conversions, price movement and fees can affect the delivered amount. Determining that breakdown requires the quoted route and settlement accounting.

Read Figure 2 from the Base deposit at the top to the Ethereum payment at the bottom. The middle panel identifies the linking evidence: the source request ID is also present in the destination transaction input. The arrows represent the selected linked stages, not a scale of value or elapsed time.

Figure 2. One source deposit and one actual payout on October 12, 2026. Values are rounded to six decimals; the table above preserves full precision. The source identifier is found in destination calldata, not in the destination FundsMovement metadata. Other deposits and their fulfillment status are outside this figure. Sources: Base deposit and Ethereum payout links above.

The destination evidence goes further than a source deposit alone: it records an actual payment. It still leaves the remaining orders and the wallet’s pre-existing funds to reconcile. The chronology now returns to Base, where a second, larger mint followed.

17:45:03 UTC: a second mint adds 100 million THEO

At Base block 52,518,878, the same submitter called the same message-processing target. The successful receipt again includes Process, ProcessId, ReceivedTransferRemote and Transfer events. Log 249 records 100000000000000000000000000 raw units issued from the zero address to the same receiving wallet: exactly 100,000,000 THEO at 18 decimals. Its message ID is different from the first mint, so these are two distinct transactions rather than two views of one issuance. Second mint receipt.

The two mints are 38 minutes 4 seconds apart and sum to 119,000,000 THEO. This expands the observed issuance beyond the 19 million in the early alert. It does not establish the entire route’s incident-wide mint total or whether matching collateral existed on origin domain 2127. Those are separate scope and authorization questions.

17:57:55 UTC: 93,510,011 THEO reaches a separate address

A later successful transaction, Base block 52,519,264, records 93,510,011 THEO moving from the mint recipient to a second address. The token’s log 591 contains the full sender, recipient and raw amount 93510011000000000000000000. Bulk transfer receipt.

BaseScan displays an ENS name for that recipient. A displayed name is not evidence that the recipient shared control with the sender or knowingly participated in the incident. The diagram stops at receipt rather than extending an ownership accusation. This selected-record review does not establish the recipient’s current token balance or its later disposition.

What these records do not establish

PeckShield’s original alert associated the incident with 19 million minted THEO and 700.8 ETH swapped or bridged. The Ethereum address overview displayed approximately 700.8 ETH during this review, but the same address has signed activity predating the selected mint. A whole-address balance is not a transaction-specific proceeds ledger. This report does not reproduce that headline as an independently verified loss total. Original alert; Ethereum address history.

The Base address list also shows several other Relay deposits and multiple swap calls. The selected payment is one linked branch, not evidence that every deposit had the same destination or was fulfilled on the same terms. A complete account reconciliation would separately identify all successful sale receipts, failed attempts, initial funds, fees, source deposits and request-linked destination receipts.

The observed route does not establish a real-world operator, a completed exchange cash-out, recovery or a freeze. It also does not establish whether the minting failure was inside Autheo’s route configuration, an origin-side authorization failure or a broader messaging-system compromise. The historical verification module, approved remote sender and corresponding origin-chain message remain the specific records needed to test those explanations.

The next evidence should address authority and accounting separately

For the mint, the useful package is the origin-chain transaction, its message identifier, the destination’s incident-block implementation and the verification-module configuration that accepted it. Comparing those records would test whether an authorized relayer handled a false or unauthorized message, rather than assuming that the transaction submitter was itself the exploiter. Autheo’s announced shutdown is a response action, not evidence resolving that cause.

For the proceeds, the next step is to reconcile every successful sale receipt against the wallet’s earlier THEO and ETH holdings, then pair each Relay deposit with its own order record and destination payment. This would separate newly realized value from older receipts and explain conversion costs without assigning every unit in the Ethereum balance to this event. Any service request should name the exact deposit, payout and identifier; there is no verified exchange-freeze target in the selected records.

The central finding is consequently bounded but useful: two selected mints issued 119 million THEO to one recipient, and the records distinguish an actual sale receipt, one identifier-correlated Ethereum payment and a separate bulk THEO transfer. The complete issuance scope, the authorization failure and the incident-specific net proceeds remain separate questions. Following one value-bearing route does not answer all three.

Evidence appendix: selected transaction anchors

Method and provenance: SentinelTX was used to identify investigation leads; the seven transaction anchors below were then inspected directly in BaseScan and Etherscan, including the relevant mint, deposit and payout logs. The official notice supplies the project’s incident account; explorer records supply transaction facts; arithmetic and identifier comparisons are this report’s analysis. This is a selected-record reconstruction, not an exhaustive account audit or a determination of operator identity. Explorer address labels are service annotations, not proof of ownership. The review checkpoint above is when this selection was checked, not an inferred provider-query cutoff.

Address roles by chain

Identifiers are not transaction hashes

These values identify the selected deposit or accepted message, not a wallet or transaction. The source deposit ID is the byte sequence compared with the Ethereum input.