> For the complete documentation index, see [llms.txt](https://docs.trover.tech/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.trover.tech/engineering/privy-automation.md).

# Privy one-time automation enrollment

Trover uses Privy additional signers for eligible embedded and smart wallets. The user owns the wallet; the server never receives a user wallet private key.

## Server configuration

Set these values on the API and worker only. Do not expose any of them through `NEXT_PUBLIC_*` variables or commit them to Git.

```env
PRIVY_APP_ID=
PRIVY_APP_SECRET=
PRIVY_AUTHORIZATION_KEY=
PRIVY_AUTOMATION_SIGNER_ID=
PRIVY_AUTOMATION_POLICY_ID=
```

Credential roles are deliberately separate:

* `PRIVY_APP_ID` is public and identifies the Privy app.
* `PRIVY_APP_SECRET` authenticates Trover's API and worker to Privy. It is the value used for Privy user/wallet API calls.
* `PRIVY_AUTHORIZATION_KEY` is the private P-256 authorization key created for Trover's server signer. It signs permitted wallet actions only after a user has approved the signer/policy relationship.
* `PRIVY_AUTOMATION_SIGNER_ID` and `PRIVY_AUTOMATION_POLICY_ID` are non-secret Privy resource IDs. They identify the signer and its scoped EVM policy.

An authorization-key private value is not an App Secret and must never be put in `PRIVY_APP_SECRET`. Neither belongs in Vercel `NEXT_PUBLIC_*` variables, browser storage, logs, source control, or X/agent prompts.

## Enrollment lifecycle

1. A user signs in with X, a wallet, or another enabled Privy method. Login proves identity; it does not give Trover signing authority.
2. If the user has no embedded execution wallet, the Account flow offers **Create wallet**. Privy creates a user-owned embedded/smart EVM wallet; Trover receives its public address and Privy wallet ID, never its private key.
3. A new eligible embedded wallet is enrolled with the authorization signer and policy during setup. This is the user's one consent for eligible automated actions.
4. An existing embedded or smart wallet uses **Enable automatic execution** once. The browser invokes Privy's `addSigners` consent flow. The user does not need to reconnect X or create a replacement wallet.
5. The API re-reads the wallet from Privy and only then records `delegatedTradingEnabled: true`; a browser success response alone is never trusted.
6. Future eligible actions may use a server-side Privy authorization signature under the attached policy. No additional wallet popup is needed unless the policy, wallet, or the user's own confirmation setting requires one.

External wallets remain user-signature wallets: a connected external wallet does not give Trover custody or durable server-side signing authority.

Users can export an embedded wallet only through Privy's user-authorized export flow. Trover must not proxy, cache, upload, or log that private key. Exporting a wallet does not automatically grant Trover any additional execution authority.

## Deployment order

1. Create an authorization key and policy in Privy.
2. Set all five variables above in the backend `.env`.
3. Restart the API and worker.
4. Log in with a test embedded wallet, create it or select **Enable automatic execution**, and check `GET /v1/trading/profile` reports `delegatedTradingEnabled: true`.
5. Only after this works, enable Privy's **Require signed requests** dashboard control. It should remain off until the authorization key is configured and deployed.

The web client may read only the signer and policy IDs from `GET /v1/trading/automation/config`; it never receives the authorization private key.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.trover.tech/engineering/privy-automation.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.