AutoSign
Session-based transaction signing for onchain applications, first deployed in Civitia.
Overview
AutoSign lets an onchain application execute a defined set of transactions without interrupting the user with a wallet approval for every action. I ideated, designed, and implemented the first version in InterwovenKit, then worked with Civitia as its first production use case.
The product problem was not transaction signing by itself. It was interaction rhythm. A game cannot feel immediate if every dice roll, purchase, or claim opens a wallet, asks the player to parse a transaction, and then returns them to the application.
System design
The first implementation combined a session wallet with Cosmos SDK authorization primitives:
- The player approved a narrowly scoped authorization from their main wallet.
- The application used a session wallet for eligible actions.
- Each action still executed under the main wallet's explicit authorization.
- Fee grants allowed the application to cover gas without another user prompt.
This preserved an inspectable onchain permission boundary while moving repeated approvals out of the core interaction loop. I later redesigned AutoSign around signature-derived session wallets; the technical deep dive and redesign notes cover the two architectures.
Civitia case study
Civitia launched AutoSign on November 18, 2025. To evaluate the change, I compared two equal UTC windows and omitted launch day:
- Before: November 4-17, 2025
- After: November 19-December 2, 2025
A Civitia gameplay transaction is a successful transaction containing an `initia.move.v1.MsgExecute` call where `module_name` is `civitia`. The call may be top-level or nested inside `cosmos.authz.v1beta1.MsgExec`. Counting the underlying function makes the windows comparable even though AutoSign changed the transaction envelope.
| Metric | Before | After | Change |
|---|---|---|---|
| All chain transactions | 70,142 | 87,654 | +25.0% |
| Civitia gameplay transactions | 64,867 | 81,196 | +25.2% |
| `roll_dice` actions | 33,079 | 43,494 | +31.5% |
| Unique gameplay senders | 269 | 279 | +3.7% |
| Gameplay transactions per sender | 241.1 | 291.0 | +20.7% |
| Gameplay share of chain transactions | 92.48% | 92.63% | +0.15 pp |
The clearest signal is intensity. Unique gameplay senders changed modestly, while repeated gameplay actions and transactions per sender rose much faster. `roll_dice`, a stable function across both windows, increased more than overall chain activity.
The gameplay share of all chain transactions stayed essentially flat. This matters because the result is not an artifact of counting the new `MsgExec` envelope. It reflects more calls to the same underlying gameplay functions.
Interpretation
The adjacent windows control for window length and weekday mix, but this is not an experiment. Campaigns, season cadence, and concurrent product changes can also affect activity. The data supports an association between the lower-friction signing flow and higher gameplay intensity; it does not isolate AutoSign as the sole cause.
Data source: the public Civitia Rollytics transaction indexer for chain `civitia-1`. Counts include successful transactions only (`code = 0`).