# TronVibes Security Audit and Project-State Report

Date: June 7, 2026  
Scope: Current website repository state, newly configured public contract addresses, VIBES token, verified `FixedPriceSave.sol` sale contract, treasury wallet, Netlify deployment shape, free AI reflection APIs, Tongg game flow, Stripe treasury offering, reCAPTCHA/rate-limit posture, public markdown links, and npm production dependency posture.

## Audit Notice

This is an internal security review and public transparency report. It is not a formal third-party audit, legal opinion, financial recommendation, or guarantee of safety. Blockchain participation carries risk. Users should verify contract addresses, inspect wallet prompts, and only participate with funds they can afford to lose.

## Executive Summary

The TronVibes website now points to the newly deployed and verified token and `FixedPriceSave.sol` sale contract.

Positive findings:

- The new token contract is verified on TRONSCAN.
- The new `FixedPriceSave` contract is verified on TRONSCAN.
- `FixedPriceSave` requires exact native TRX payment and prevents accidental direct overpayment.
- The sale contract was deployed with `consume_user_resource_percent` / User Consumption Ratio at 100%, so contract callers pay their own invocation resources.
- Production dependencies currently audit clean with `npm audit --omit=dev`.
- B.AI, Stripe, wallet encryption, database, and API-token secrets are read server-side from environment variables.
- Launch readings are free and no longer require payment proof.
- Stripe is used for optional treasury card offerings while readings are free.

Largest remaining risks:

1. Treasury and sale administration are controlled by a single wallet permission set.
2. The sale owner can still change sale parameters.
3. The sale has no end time and no per-wallet cap.
4. TRONSCAN currently reports the new token with a suspicious red tag until token profile/rating review is completed.
5. Most tokenomics allocation buckets are treasury-managed rather than locked in dedicated contracts.
6. Free AI endpoints need reCAPTCHA, CORS, rate limits, monitoring, and budget discipline before heavier public traffic.

## Current Live Addresses

| Role | Address | Public Link |
| --- | --- | --- |
| VIBES Token | `TYiVmZBsgKsSCt5J7bpcM3y6JhCQEbckzf` | https://tronscan.org/#/token20/TYiVmZBsgKsSCt5J7bpcM3y6JhCQEbckzf |
| Verified Creation Offering | `TWkG7UGjdeSGqzh6isPFKPZn4PA7PgHxua` | https://tronscan.org/#/contract/TWkG7UGjdeSGqzh6isPFKPZn4PA7PgHxua |
| Treasury Wallet | `TD2HSap6EGZ6c7hf5VVqx9NSEtXwqUiGhX` | https://tronscan.org/#/address/TD2HSap6EGZ6c7hf5VVqx9NSEtXwqUiGhX |

## Evidence Reviewed

- `App.tsx`
- `constants.ts`
- `.env.example`
- `.env`
- `server.js`
- `package.json`
- `package-lock.json`
- `netlify.toml`
- `contracts/TronVibes.sol`
- `contracts/FixedPriceSave.sol`
- `verification/tronscan/FixedPriceSave/FixedPriceSave.sol`
- TRONSCAN API metadata for:
  - `TYiVmZBsgKsSCt5J7bpcM3y6JhCQEbckzf`
  - `TWkG7UGjdeSGqzh6isPFKPZn4PA7PgHxua`
- `npm audit --omit=dev`

## Current Configuration Snapshot

From `constants.ts`:

| Field | Value |
| --- | --- |
| `VIBES_TOKEN_ADDRESS` | `TYiVmZBsgKsSCt5J7bpcM3y6JhCQEbckzf` |
| `SALE_CONTRACT_ADDRESS` | `TWkG7UGjdeSGqzh6isPFKPZn4PA7PgHxua` |
| `TREASURY_ADDRESS` | `TD2HSap6EGZ6c7hf5VVqx9NSEtXwqUiGhX` |

TRONSCAN API metadata checked during this audit reports:

- Token `verify_status: 2`.
- Sale `verify_status: 2`.
- Token `redTag: "Suspicious"`.
- Sale has no red tag in checked metadata.
- Both checked contracts are not reported as proxies.
- Both contracts were deployed by `TD2HSap6EGZ6c7hf5VVqx9NSEtXwqUiGhX`.
- Both contracts report `consume_user_resource_percent: 100`.

## Severity Summary

| Severity | Count |
| --- | ---: |
| Critical | 1 |
| High | 3 |
| Medium | 5 |
| Low | 3 |
| Informational | 8 |

## Critical Findings

### C-01: Single-key treasury and sale administration

The treasury wallet `TD2HSap6EGZ6c7hf5VVqx9NSEtXwqUiGhX` is the operational treasury and deployer/admin path for sale operations.

Impact:

- One compromised key can move treasury assets.
- One compromised key can administer sale settings.
- One lost key can block future administration.
- Public trust depends on a single operational key rather than multi-party controls.

Recommendation:

- Move treasury control to stronger permissions, a multi-signature wallet, or a dedicated treasury contract.
- Transfer sale ownership to the stronger control structure after deployment/configuration.
- Publish a signer and emergency response policy.

## High Findings

### H-01: Sale owner can change core sale parameters

The sale exposes owner-only controls such as:

- `setPrice(uint256)`
- `setSchedule(uint256,uint256)`
- `setCaps(uint256,uint256)`
- `setTreasury(address)`
- `withdrawUnsold(address,uint256)`
- `rescue(address,uint256)`
- `transferOwnership(address)`

Impact:

- Price, schedule, caps, treasury address, and inventory handling can change through owner actions.
- Users depend on owner discipline and public communication.

Recommendation:

- Publish sale-setting policy.
- Avoid changing settings without public notice.
- Consider timelocks, immutable sale settings, or stronger ownership controls for later scale.

### H-02: Sale has no end time and no per-wallet cap

Configured/default values:

- `startTime = 0`
- `endTime = 0`
- `perWalletCap = 0`

Impact:

- Sale is open immediately with no scheduled end.
- One wallet can buy the remaining allocation subject to inventory and hard cap.

Recommendation:

- If intentional, state it clearly.
- If not intentional, set an end time and/or per-wallet cap.

### H-03: Token is still automatically tagged suspicious by TRONSCAN

TRONSCAN API metadata for the new token reports:

```json
"redTag": "Suspicious"
```

Impact:

- Wallet and explorer trust may be reduced.
- Users may see warnings even though the token source is verified.
- Token discovery and credibility can be affected.

Recommendation:

- Complete TRONSCAN token Basic Info.
- Publish website, whitepaper, audit, logo, official email, and verified contracts.
- Submit token rating update after the metadata is recorded.

## Medium Findings

### M-01: Most tokenomics buckets are treasury-managed

The tokenomics describe multiple allocations, but dedicated vesting, rewards, liquidity, staking, marketplace, team, partner, and infrastructure contracts are not currently live.

Recommendation:

- Publish allocation wallet addresses.
- Deploy vesting/allocation contracts when needed.
- Update public docs when allocation controls are live.

### M-02: Free AI endpoints create cost and abuse exposure

Current protections include CORS allowlist, global/API rate limits, AI-specific rate limits, optional Google reCAPTCHA v3, optional API-token guards for sensitive follow-ups, and server-side B.AI keys.

Recommendation:

- Keep reCAPTCHA enabled in production.
- Keep Cloudflare or equivalent WAF/rate protection in front of the site.
- Monitor B.AI spend and error rates.
- Keep wallet-address jobs async and bounded by TTL, max tokens, and retry limits.

### M-03: Treasury offering is separate but irreversible by design

TRX offerings are direct on-chain transfers to the treasury. USD offerings use Stripe hosted Checkout. Neither issues VIBES.

Recommendation:

- Keep "does not issue VIBES" copy visible.
- Keep TRX and USD input fields separate.
- Keep Stripe secret key server-side only.

### M-04: Wallet UX depends on injected wallet providers

The app depends on wallet injection from TronLink, Klever, or compatible TRON wallet browsers.

Recommendation:

- Keep wallet launcher separated from the main menu.
- Keep TronLink/Klever instructions accessible.
- Display target addresses and links near transaction actions.

### M-05: Profile wallet and Trace Memory backend code exists while visible sections are dormant

The server has profile registration, login, wallet generation/export, and Trace Memory endpoints. Visible profile wallet, Trace Memory, Silent Access, and MediaPipe lab sections are currently dormant.

Recommendation:

- Keep these endpoints behind rate limits and auth.
- Keep secrets and wallet encryption keys out of public files.
- Avoid public copy that implies dormant sections are live.

## Low Findings

### L-01: Standard approval race exists in token design

The token uses standard `approve`, `transfer`, and `transferFrom` behavior without `increaseAllowance` or `decreaseAllowance`.

Recommendation:

- Future allowance UIs should set allowance to zero before setting a new nonzero value.

### L-02: Token has no emergency controls

The token has no pause, blacklist, mint, burn, or admin recovery controls.

Impact:

- This improves fixed-supply trust.
- It also means token-level mistakes cannot be reversed.

### L-03: Public docs must be updated with every contract migration

Recommendation:

- Update docs, constants, Netlify variables, TRONSCAN metadata, and UI labels in the same release whenever contract addresses change.

## Informational Notes

### I-01: Production dependency audit is clean

Command:

```bash
npm audit --omit=dev
```

Current result:

- 0 production vulnerabilities.

### I-02: `FixedPriceSave.sol` fixes direct overpayment

The active sale contract requires:

```solidity
require(msg.value == cost, "bad value");
```

This fixes the previous direct-overpayment issue.

### I-03: B.AI model configuration is current

- `BAI_CHAT_MODEL=deepseek-v4-pro`
- `BAI_FALLBACK_MODELS=deepseek-v4-flash`

### I-04: Launch readings are free

`LAUNCH_READINGS_ARE_FREE` is set to `true` in the frontend. Legacy Stripe decoder checkout handling remains in code but does not gate launch readings.

### I-05: Stripe card offering is treasury-only

The active Stripe path for users is the treasury offering Checkout session.

### I-06: reCAPTCHA v3 is optional by environment

When `VITE_RECAPTCHA_SITE_KEY` and `RECAPTCHA_SECRET_KEY` are set, browser AI calls include reCAPTCHA tokens and server routes verify them. `RECAPTCHA_BYPASS_TOKEN` exists for private smoke testing only and should not be exposed publicly.

### I-07: Netlify routing is simple and appropriate

`netlify.toml` builds with `npm run build`, publishes `dist`, redirects `/api/*` to the API function, and falls back other paths to `index.html`.

### I-08: Public footer links exist

The footer links to `/audit.md`, `/whitepaper.md`, `/media-assets.md`, `/security-plan.md`, `/privacy-safety.md`, and the TRONSCAN sale inspection URL.

## Website Review

Visible current sections reviewed in `App.tsx`:

- Hero.
- Identity manifesto.
- Public Witness section.
- Free wallet-address reflection.
- Personal decoder.
- Word and number decoder.
- Tongg.
- Klever/TRX bridge guidance.
- Address Reflection.
- Initial Creation Offering.
- Treasury Offering.
- Tokenomics.
- Contract Information.
- Bug Reports.
- Footer documentation links.

## Recommended Action Plan

Priority 1:

1. Complete TRONSCAN token Basic Info.
2. Submit token rating update.
3. Confirm sale inventory has been deposited.
4. Keep reCAPTCHA v3, rate limits, and CORS configured before driving traffic to free AI tools.

Priority 2:

1. Move treasury and sale ownership to stronger controls.
2. Decide whether a sale end time or per-wallet cap is needed.
3. Publish allocation wallet addresses or deploy allocation contracts.
4. Keep `npm audit --omit=dev` in the release checklist.
5. Add Cloudflare or equivalent WAF/DDoS protection for free AI and game traffic.

Priority 3:

1. Commission an independent third-party smart contract audit before scale.
2. Publish signed release notes for contract, frontend, or treasury changes.
3. Maintain a public changelog for contract addresses, sale settings, tokenomics, and AI policy changes.

## Current Audit Status

Status: Updated internal/public transparency report.

The new VIBES token and `FixedPriceSave.sol` sale contract are verified and now configured in the website. The main remaining public-trust task is completing TRONSCAN token metadata and rating review.