> For the complete documentation index, see [llms.txt](https://secant.gitbook.io/secant-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://secant.gitbook.io/secant-docs/phase-1-current-build.md). # Phase 1: Current Build Phase 1 is the product that is live in the current Secant workspace. Everything listed here is built and functional. ## Wallets * EVM wallet connection for Base and other EVM activity through injected providers (MetaMask, Coinbase Wallet, Rabby). * Solana Wallet Adapter and Wallet Standard support for Phantom, Solflare, Backpack, and Jupiter Mobile. * Separate EVM and Solana wallet identity displayed in the header and across all checkout surfaces. * Dashboard balance scope selector: All wallets, EVM wallet, or Solana wallet. ## Dashboard * Aggregated portfolio balance across all connected wallets. * Balance chart with wallet scope filtering. * Asset list and network distribution from portfolio provider data. * Activity entry points for payment history and settlement tracking. ## Terminal Checkout * USDC checkout terminal with configurable amount. * Base and Solana chain selector with active rail indicator. * Receive mode: generates QR code and payment link for customers to pay. * Send mode: transfer USDC from connected wallet. * Solana Pay URL encoding with recipient, amount, SPL token mint, reference keypair, and memo. * Payment status polling with exponential backoff on errors. * Chain identity shown beside the checkout asset so the active rail is always visible. ## Scan & Pay (Point of Sale) * Point-of-sale screen for merchant-facing payment collection. * QR scanning and manual paste fallback for payment payloads. * Base USDC and Solana Pay support with active-chain tabs. * Max USDC balance display for the selected rail. * Amount keypad with validation against connected wallet balance. * Chain-aware transaction building and signing. ## Invoices * Invoice creation with amount, chain, and recipient configuration. * Customer wallet request field for Solana invoices. When supplied, Secant creates the invoice and sends a Dialect payment request notification to the customer wallet. * Optional memo field for tagging invoices with context (company name, project, purpose). Memo is stored with the invoice and displayed on the invoice list, payment link, and Blink card. * Unique invoice ID generation (`inv_` + cryptographically random hex). * Base payment links for EVM USDC checkout. * Solana payment links for Solana Pay checkout. * Secant Blinks: a first-party Solana Action endpoint exposing invoice metadata and building the payment transaction in the Secant backend. Invoices unfurl as payable cards in compatible clients (Secant's own `/pay` checkout, native wallets, and Dialect `dial.to` as the shareable web renderer). Only the payer account is caller-supplied — recipient, amount, mint, and reference come from the stored invoice. When a memo is set, it appears in the Blink title and description. * Copy and share actions for payment links. * Copy Blink URL action for Solana invoices. Blink rendering depends on the receiving client or renderer; the Secant backend remains the transaction builder. * Invoice status tracking: PENDING, SETTLED, EXPIRED, FAILED. * Settled invoices remain visible in the merchant list and cannot be hidden from the local invoice list UI. * 30-minute invoice expiry enforced at both creation and settlement time. * Plan-based monthly invoice limits: the **Starter** plan allows **10 active invoices per calendar month**; **Growth** and **Enterprise** are unlimited. An invoice counts while it is pending or settled — when an unpaid invoice expires, its slot is automatically refunded, so abandoned invoices never permanently cost an allowance. The cap is enforced server-side with an atomic counter (no client-side bypass), and current usage (e.g. "Starter · 7 / 10 this month") is shown on the Invoices page. * Automatic expiry sweep: a scheduled job transitions overdue `PENDING` invoices to `EXPIRED`, refunds the monthly quota slot, and stamps a DynamoDB TTL so the expired record is auto-deleted after a grace window. Settled invoices carry no TTL and are retained. ## Account Settings * Merchant profile keyed by connected wallet: business name, contact email/phone, settlement mode, default network, and website. * Wallet-signature gate: profile details are blurred until the wallet proves ownership by signing a one-time message. Nothing is cached in the browser. * Optional two-factor authentication (TOTP): enable an authenticator app on top of the wallet signature. When enabled, reading and writing settings (and disabling 2FA) additionally require a 6-digit code. TOTP secrets are AES-256-GCM encrypted at rest and never leave the backend. * Settlement-address pre-registration: merchants can add Solana settlement addresses ahead of time so the Helius webhook watches them before any invoice is issued. * Plan and monthly usage are surfaced on the Invoices page; the plan is server-controlled (a settings write can never self-upgrade it). ## Notifications (Dialect Alerts) * Dialect Alerts integration: when a merchant supplies a customer wallet on a Solana invoice, the backend sends an in-app payment-request alert to that wallet, carrying the invoice amount, memo, and pay link. * First-connect opt-in: connecting a Solana wallet prompts the merchant to enable notifications and sign a one-time message that subscribes them to Secant's Dialect app. * In-app inbox in the dashboard notification bell — an anchored dropdown on desktop and a bottom-sheet on mobile — for reviewing received requests and settlement alerts. * The Dialect API key stays server-side; the browser uses only the public dapp address and the publishable client key. * Delivery requires the recipient wallet to be subscribed to Secant's Dialect app. Dialect Alerts are a request surface and never settle invoices — settlement remains the backend's authority. ## Swap & Bridge * Solana-to-Solana swap quotes routed through Jupiter. * EVM swap and bridge routes routed through Zerion. * Same-token selection protection in the UI. * Minimum received amount and slippage controls shown before signing. * Route and price impact visibility. ## Solana-Native Features * Jupiter checkout routing: customers pay with SOL or supported SPL tokens, merchant receives USDC. * Solana Pay URL generation with reference keypairs and memo support. * Helius webhook endpoint for native Solana settlement detection on both devnet and mainnet. * Helius webhook settlement verified on mainnet with invoice status changing from `PENDING` to `SETTLED` after payment. * Automatic Helius address registration: when a Solana invoice is created, the recipient address is appended to the Helius webhook's watched-address list (idempotently — each address is registered once), so payments to a brand-new recipient are detected without manual dashboard configuration. The Helius API key stays backend-only. * SNS `.sol` recipient name resolution. * SPL token transfers through `@solana/spl-token` with proper associated token account handling. * Compute budget priority fee support for reliable transaction landing under congestion. ## Settlement * Backend validates every settlement against stored invoice state: chain, recipient, asset, amount, and reference must all match. * Atomic settlement via DynamoDB `TransactWriteItems` — settlement marker and invoice update succeed or fail together. * Settlement marker rows prevent double-settlement of the same on-chain transaction. * Consistent reads on invoice lookups during settlement validation. * Invoice expiry checked before settlement processing, and an independent scheduled sweep transitions stale `PENDING` invoices to `EXPIRED` (conditional write, so a late payment and the sweep can never both act) and refunds the merchant's monthly quota slot. ## API Security * Per-endpoint authentication: bearer token on invoice initiation, HMAC signature on the settlement webhook, constant-time static bearer on the Helius webhook, RSA signature on the Zerion webhook. Public payment-surface endpoints (invoice details, Blink action, Jupiter checkout) are intentionally unauthenticated — they expose only payable data and build unsigned transactions the payer signs. * Wallet-owned account settings: reading or writing a merchant profile requires a fresh wallet-ownership signature (Solana ed25519 / EVM EIP-191), and the merchant dashboard keeps the profile blurred until the wallet verifies. * Optional TOTP two-factor authentication layered on top of the wallet signature for settings reads/writes; secrets are AES-256-GCM encrypted at rest and never serialized to the client. * Plan/usage endpoint is served behind the same server-side initiator token as invoice creation, so monthly usage is read from the authoritative counter rather than guessed in the browser. * Strict JSON schema enforcement — `DisallowUnknownFields()` rejects payloads with unexpected fields. * Provider API keys isolated to server-side Next.js API routes, never exposed to browser. * RPC proxy with response sanitization to prevent API key leakage through error messages. * Structured error codes and typed error responses across all endpoints. ## Testnet Support * Mainnet and testnet environment toggle. * Base Sepolia for EVM testing. * Solana Devnet for Solana testing. * Native Solana devnet settlement coverage through Helius rather than relying on EVM-first indexer coverage. --- # 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://secant.gitbook.io/secant-docs/phase-1-current-build.md?ask=&goal= ``` `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.