A practical description of the information this application uses and where it is stored.
Last updated 27 October 2026
1. Information you provide
An agent configuration contains its name, type, optional description, publication choice, optional artwork reference and coin association, and target: a public Solana mint address, public GitHub repository, or plain technology keywords. A run also records its execution state, progress, timestamps, phase logs, result, and any reported error.
Project information can include a name, token symbol, public mint address, website URL, planning stage, checklist completion, and a saved report. A direct scan request includes the public Solana address and whether it is a token or wallet check.
Do not include seed phrases, private keys, API secrets, passwords, recovery codes, or sensitive personal documents in agent targets or project fields. The application does not need these to provide its current features.
2. Sign-in and holder verification
Privy handles email or external-wallet authentication. The application receives authentication state, an account identifier, an access token, and the account identifier needed to scope saved records. The application uses a generic account label in its interface. Server endpoints validate access tokens against Privy’s public signing keys.
For holder eligibility, the server retrieves the authenticated user’s account record from Privy, checks linked verified Solana wallet information, and requests finalized token-account balances for the configured access-token mint through Helius. This connects account identity with public wallet holdings to decide whether an agent run may start. Saving an agent profile requires authentication; executing it requires this additional holder check. The check is repeated for each run; an entered address or browser-reported balance is not accepted as proof.
Eligibility balance snapshots are processed for the request; the application’s agent tables do not store those raw snapshots. Definitions, run history, and project records are associated with your Privy user identifier. Neither a linked public wallet address nor a balance check gives GudTek your private key or permission to transfer assets.
3. Where information is stored
Data
Storage and purpose
Guest projects
Local storage in the current browser. This allows a guest launch plan to survive a refresh.
Signed-in projects
The application’s configured database, scoped to the authenticated owner, so account projects can be retrieved on later visits.
Agent definitions and runs
The owner-scoped account database. Stores configuration, state, progress, logs, results, errors, and timestamps so work can be reviewed after execution.
Uploaded artwork
Vercel Blob stores a processed WebP image at a public URL. The account database stores its owner, image reference, dimensions, size, and processing status. File names and image metadata are not retained in the published file.
Demo configurations and results
Separate browser session storage. Synthetic data only, isolated from guest and account records.
Recent direct scan reports
Local storage in the current browser, to display report history. This is separate from cloud project storage.
Rate-limit records
The database stores an account identifier, time-window value, and request count to limit direct scans, agent run attempts, and image uploads.
Authentication state
Managed by the Privy client and its session mechanisms. Sign-out ends the active application session.
Downloads
Exported JSON files are saved through your browser. Their later storage and sharing are under your control.
Guest projects and demo records are not automatically uploaded or merged into your account when you sign in. Browser-stored information can remain after sign-out and may be visible to another person using the same browser profile. Clearing site data can remove local projects and report history.
4. Services involved in a request
The hosting provider serves the application and executes bounded background runs. Privy processes authentication and supplies linked-wallet verification information. Helius receives public addresses and read-only RPC requests for token analysis and holder eligibility. The database provider stores account projects, agent configurations, run history, and rate-limit records.
GitHub receives repository names or search keywords needed for public-source agents. Repo Recon retrieves selected public source files for analysis; its saved result contains derived observations, file and line references, and source links rather than full copies of those files. Credential-pattern findings withhold matched values. Tech Discovery requests public repository metadata only. Private repositories are rejected, including when a server-side GitHub credential could otherwise read them.
Infrastructure providers may process technical information such as IP addresses, request metadata, and operational logs under their own terms and privacy practices. Privy app secrets, Helius credentials, and any GitHub API token are server-side configuration; they are not included in browser code or returned in reports. User private keys are not sent to these providers by the review workflow.
Following an external explorer, repository, documentation, or project website link opens a third-party service with its own data practices. A project website field is a saved link; it does not cause an agent to crawl or audit that site.
5. Public sources and sharing
Solana addresses, balances, mint configuration, and transaction signatures are public-chain information. Public GitHub content can identify its authors or organizations. These sources may be public while their connection to your account, research target, or launch plan remains information you want to keep private.
Account projects, agents, and runs are retrieved through owner-scoped endpoints. Agent profiles are private by default. If you publish an agent, its name, description, mission, target, associated public coin address, artwork URL, run counts, and latest run events and results become available through the public Agents and Coins pages. Account identifiers and private wallet-link records are excluded. Public projects and team-sharing permissions are not offered. If you download a report and send it to someone, that is a separate disclosure you control.
Artwork uploads have public URLs even before an agent is published. Only upload artwork you intend to make public. Unpublishing an agent removes it from subsequent public-directory and profile responses; it does not revoke an artwork URL or erase copies other people have already obtained.
6. Retention and deletion controls
Delete an agent to remove its configuration and associated run history from the active account database. Cancel any queued or running review before deleting it. Cancelling a run changes its state but does not itself erase the saved configuration or logs. Agent records do not have an automatic time-based expiry; the workspace limits are 20 configurations and 500 runs per account.
Use the project’s delete control to remove that project from its guest workspace or account database. Use report-history controls where available or clear this site’s browser data to remove local records. Deleting a cloud project or agent does not delete independently downloaded files, uploaded artwork, or separate local report history. The current image limit is 40 uploads per account; removing unused Blob objects is an operator-managed action.
Local records persist until removed, evicted by the browser, or replaced by history limits. Demo data uses separate session storage and follows that browser session’s lifetime. This application does not promise a fixed infrastructure-log or backup retention period. Provider-managed records may follow the relevant provider’s retention policies. No automated account-wide deletion workflow is represented by an individual delete action.
7. Security and your choices
Read-only reviews do not require spending authority.
GudTek does not request token approvals, sign transactions, revoke authorities, transfer funds, or write to a repository as part of its agent or scan workflow.
Protect your email account, browser profile, and connected wallet. Use a trusted device for private planning and research. Export important records before clearing browser storage, and review the full address or source URL before following links or acting on a result.
The isolated demo uses synthetic fixtures in separate session storage. It does not query live wallets or repositories, make holder-verification requests, or read your authenticated account records. Its results are examples rather than observations about real targets.
This notice describes the implemented application. Additional analytics, sharing, scheduled monitoring, or data services would require this notice to be updated to reflect those changes.
8. Public protocol and holder views
The protocol explorer contains source-backed reference material and bounded public GitHub metadata. The holder network reads public token-account data for the configured GudTek mint, aggregates observed balances by wallet owner, and compares them with the configured threshold. These public views can be opened without signing in.
Public wallet addresses and balances are not personal profiles. The holder directory does not publish account emails, Privy identifiers, or private linked-wallet records. Agent targets and run evidence appear separately only when an owner publishes an agent. Its displayed eligibility is a public balance observation, not confirmation that someone has authenticated or used GudTek. Short-lived provider caches and snapshot timestamps are described in the interface.
The separate example holder table uses fictional records and does not connect a wallet. Public-source links lead to external documentation, repositories, or explorers whose own policies apply.