Raxx · internal docs

internal · gated ↑ index

Questions for the attorney — first consult

Use this document as your consult agenda. Take it into the meeting; the background and primary sources are already staged in the sibling research docs so the attorney can jump straight to the judgment calls.

Consult structure

First consult typically runs 60–90 minutes and should cover: (a) entity choice + state of formation, (b) trademark posture (MOOSEQUEST + Raxx), (c) IP-assignment plan, (d) engagement + fee structure going forward.

A) Engagement and fee framing (ask first)

  1. What's your hourly rate, and do you offer flat-fee packages for entity formation + founder agreements + trademark assignment?
  2. Can you represent me on both entity formation AND trademark matters, or does trademark work need a separate practitioner registered with the USPTO?
  3. Do you use any client portal (Clio, MyCase)? Preferred comms channel?
  4. Do you handle the FinCEN BOI report (Corporate Transparency Act) as part of formation, or is that a separate scope?
  5. Do you handle Delaware formations + foreign qualification if I form in DE and operate elsewhere, or do you refer Delaware work out?

B) Entity structure + state of formation

(Background: entity-structure.md, state-of-formation.md.)

  1. For a solo-founder pre-revenue SaaS (options-trading retail tooling) in [home state — to be filled in], do you recommend a single-member LLC, an LLC with S-Corp election, or a Delaware C-Corp? Why?
  2. If we form in my home state, are there any home-state-specific traps (charging-order weakness, single-member LLC veil-piercing concerns, publication requirements) I should plan for?
  3. If we form in Delaware or Wyoming while operating in [home state], is foreign qualification in [home state] mandatory for a remote SaaS? What specific activity triggers the "transacting business" test in [home state]?
  4. Should I have a holding LLC for IP and an operating LLC for revenue now, or is that overkill pre-revenue? What's the breakeven point where it becomes worthwhile?
  5. If I might raise angel / VC capital in 12–24 months, should I form as a Delaware C-Corp now to start the QSBS § 1202 five-year holding-period clock? Or is it cleaner to form as an LLC and convert later?
  6. Any reason to use a Series LLC or an Umbrella LLC structure here?

C) Trademark — MOOSEQUEST status + strategy

(Background: trademark-moosequest.md.)

  1. I'll pull the MOOSEQUEST record from USPTO TSDR before we talk — here it is: [attach pulled record showing serial, registration number, status, classes, filing and registration dates, owner of record, register]. Is the registration currently in good standing?
  2. Are there any defects in the current MOOSEQUEST filing (over-broad ID of goods/services, weak specimens, unrecorded ownership change) that I should correct before the next §8 or §§8+9 window?
  3. When should I file the next maintenance filing, and what's your fee (separate from USPTO filing fees per trademark-moosequest.md)?
  4. Should MOOSEQUEST be assigned to the future Raxx LLC, or kept in my personal name and licensed to the entity? What are the tax, asset-protection, and estate-planning implications of each path?
  5. If we assign, can you draft the assignment (with goodwill) and handle ETAS recordation?

D) Trademark — Raxx new filing

  1. Can you run a formal clearance search on RAXX in IC 009, IC 036, IC 041, and IC 042? Fee?
  2. Given Raxx is pre-launch, do you recommend a §1(b) intent-to-use filing now, or waiting for a §1(a) use-based filing post-launch? Tradeoffs (cost, speed, priority date, extension fees)?
  3. What's the right class strategy — file in one class and expand later, or file in all relevant classes at once?
  4. Any concern that "Raxx" reads close to existing marks in financial services, fintech, or software? If so, brand-pivot cost/benefit before filing?

E) IP assignment + founder agreements

  1. All Raxx work to date (code, designs, trademarks, brand) was done by me personally before entity formation. Do I need a founder's IP-assignment agreement transferring that pre-formation work into the new entity on day 1? Can you draft one?
  2. If I retain any contractors (even short-term), what IP-assignment clauses should be in their contracts by default?
  3. Any open-source licensing obligations I should audit in the Raxx codebase before it transfers to the entity? (Likely not attorney scope directly, but flag if you see issues.)

F) Contracts and policies (for the roadmap, not necessarily this consult)

  1. Who drafts Raxx's Terms of Service, Privacy Policy, and Subscription Agreement? Do you have a SaaS package?
  2. GDPR and CCPA posture for a US-based SaaS with some international users — do we need a data-processing addendum template, and when?
  3. Any financial-services disclaimer language required on a retail-facing options-trading tool? Is Raxx a trading tool that triggers FINRA / SEC considerations, or is it firmly an analytical tool outside that regulatory perimeter? (This may be outside the attorney's scope — may need a securities attorney.)

G) Logistics

  1. What's your conflict check process? I want to make sure you can represent both me personally and the future entity.
  2. Retainer required? Expected first-year spend for formation + trademark work?
  3. If you can't handle a specific sub-question (e.g., securities-law / FINRA review), can you refer a specialist?

H) Data licensing (added 2026-04-23) — historical options-chain data for MBT backtester

(Background: docs/data-science/historical-options-data-vendors.md. Priority: HIGH — this is the hard blocker flagged in markov-fit-analysis.md before any backtest work begins.)

Context: Raxx's MBT paper-trading engine includes a mbt.run_backtest function. Users trigger backtests on the server; the backtest consumes historical options chain data internally and returns computed results (P&L, win rate, drawdown) to the user. No raw options chain data is passed through to or stored by the user. The underlying data candidates are ORATS (historical API) and potentially Databento (OPRA).

  1. OPRA non-display use classification. OPRA charges a $1,500/mo redistributor fee for anyone who displays OPRA data to third parties. If Raxx's MBT backtester uses historical options chain data server-side only — computing results, never transmitting raw chain data to users — does this qualify as "non-display use" under OPRA's fee schedule, avoiding the redistribution fee? Primary source to review: https://www.opraplan.com/faqs and https://www.marketdata.app/education/options/opra-fees/

  2. ORATS enterprise terms review. ORATS's standard retail API terms state "internal business purposes only" and prohibit distribution/redistribution to third parties, with a single-user license. Review ORATS's enterprise/commercial agreement (obtainable by contacting ORATS sales). Specific questions: (a) Does running backtests on behalf of paying users (server-side computation, results returned to users) constitute "redistribution" or "internal use" under ORATS's terms? (b) Does caching ORATS data in Raxx's database for repeated backtest access constitute redistribution? (c) Does surfacing regime-state signals derived from ORATS IV data (e.g., a regime-probability score shown in Antlers) constitute redistribution of the underlying data? Primary source: https://orats.com/terms-conditions

  3. Polygon.io enterprise vs. standard terms. Polygon.io's standard plan terms explicitly prohibit "business or commercial purposes" and redistribution. Review their enterprise/business tier agreement. Is the enterprise tier's scope sufficient for Raxx's server-side backtest use case, and what are the governing terms for "display use only" vs. computational use? Primary source: https://polygon.io/legal/market-data-terms-of-service

  4. Alpaca redistribution scope. Alpaca support documentation states data cannot be "redistributed for business purposes." Does Raxx's use of Alpaca options chain data to simulate fills in MBT's real-time paper-trading engine (server-side, never passed to users as raw data) constitute "redistribution" under Alpaca's definition, or is it covered by the subscription as a typical API consumer? Primary source: https://alpaca.markets/support/redistribute-alpaca-api

  5. EU data transfer flag. If Raxx onboards EU users in the future, does the data-vendor relationship (ORATS or Databento) require a GDPR Article 46 transfer mechanism (standard contractual clauses) in addition to the commercial license?

Priority for this consult: H1 and H2 are the highest-priority questions from this section. H1 determines whether the entire backtest architecture is viable under OPRA rules. H2 determines whether ORATS is the right vendor.

(Background: docs/business/2026-05-04-support-autoreply-legal-posture.md. Priority: MEDIUM — needed before launch; not a blocker for pre-launch testing.)

Context: Raxx's support queue (support@raxx.app) fires an automated acknowledgment to any inbound email. The autoreply will include a disclaimer footer. The platform has no published Terms of Service or Privacy Policy as of 2026-05-04. These questions should be addressed before the first paid subscription is accepted.

  1. SEC investment-adviser perimeter. Does Raxx's positioning — automation layer, user-defined rules, no personalized recommendations — keep it outside the SEC investment-adviser definition under the Advisers Act ABCs test? If any planned feature (AI-surfaced pattern suggestions, earnings-event alerts, regime indicators) could cause re-entry into the advisory definition, what is the specific line Raxx should not cross without a formal opinion?

  2. "Not investment advice" disclaimer adequacy. Is the following footer language sufficient to rebut any claim that the autoreply constitutes investment advice: "Raxx does not provide investment, financial, or tax advice. This email is an automated acknowledgment — not a recommendation." Or should this be more specific (reference to Investment Advisers Act, mention of no SEC registration, etc.)?

  3. SLA language review. Does "we aim to respond within 1 business day" in the autoreply create any enforceable obligation once a subscription agreement is signed? Should the Terms of Service explicitly subordinate all support communications to the ToS?

  4. ToS + Privacy Policy drafting scope. Can you draft both the Terms of Service and Privacy Policy for a SaaS trading-tools platform at a flat fee? What must the Privacy Policy include to satisfy both GDPR Article 13 and CCPA Section 1798.100?

  5. CAN-SPAM physical address. Does Raxx's support autoreply — which contains no promotional content — require a physical mailing address and unsubscribe mechanism under the CAN-SPAM Act? Or does the "transactional or relationship message" exemption apply cleanly?

  6. Confidentiality legend. Should the autoreply include an email confidentiality notice ("This email may contain confidential information…")? Is that protective or purely theatrical for a SaaS support queue?

Priority for this consult: I1 (investment-adviser perimeter) and I4 (ToS/Privacy Policy drafting scope) are the highest-priority questions in this section. I1 has implications for the entire product roadmap. I4 is the shortest path to closing the GDPR gap.

J) GitHub org creation before LLC formation — authority, IP, and DBA (added 2026-05-06)

(Background: docs/legal/research/github-org-pre-llc-2026-05-06.md. Priority: HIGH — J1 and J2 should be resolved before the repo transfer from MooseQuest/TradeMasterAPI to raxx-app/TradeMasterAPI is treated as permanent. J3 may have a 40-day hard deadline — see Timing section of that doc.)

Context: On 2026-05-06, Kristerpher created a GitHub organization (raxx-app, https://github.com/raxx-app) on the GitHub Team plan ($4/user/month), entering "Raxx" as the business name and accepting GitHub's Customer Agreement attestation ("I hereby accept the GitHub Customer Agreement on behalf of my organization and confirm that I have the authority to do so") — before any LLC or corporation named "Raxx" is filed with any state. The next step is transferring MooseQuest/TradeMasterAPI to raxx-app/TradeMasterAPI.

  1. Authority attestation risk. Kristerpher accepted GitHub's Customer Agreement attestation on behalf of "Raxx" before any Raxx entity legally exists. Does this attestation create personal liability exposure? Does it create a contract-formation defect (i.e., is the agreement void or voidable because one named "party" has no legal existence)? What — if anything — should be done to correct the record once Raxx LLC is formed?

  2. IP chain of title — org transfer mechanics. When Raxx LLC is formed, what is the cleanest documented path to: (a) transfer GitHub org ownership from Kristerpher's personal control to the LLC, and (b) ensure the IP assignment to the LLC (code, designs, trademarks) is consistent with and contemporaneous to the GH org ownership change? Is a founder IP-assignment agreement + org ownership transfer sufficient, or is a bill of sale or additional instrument needed?

  3. DBA / fictitious name risk — California. California Business and Professions Code §17910 requires a fictitious business name filing within 40 days when a sole proprietor transacts business under a name not containing their legal surname. Kristerpher spends ~4 months/year in California. By entering "Raxx" as the GitHub org business name and using the org for commercial development activity while in CA, has the CA DBA filing window opened? If so, which county clerk is correct, and what is the newspaper-publication requirement? Primary source: https://leginfo.legislature.ca.gov/faces/codes_displaySection.xhtml?lawCode=BPC&sectionNum=17910.

  4. DBA / fictitious name risk — Pennsylvania. Does the same scenario trigger a PA fictitious name registration? What is the fee and process, and does it interact with or precede LLC formation?

  5. Trademark owner matching. USPTO Reg. 7779396 records a specific owner. The GitHub org now publicly names "Raxx" as the business. Once Raxx LLC is formed, should the ETAS trademark assignment from the current owner of record to Raxx LLC be executed before the LLC is publicly associated with the raxx-app org (e.g., on getraxx.com), or is the sequence flexible? What is the risk of operating publicly under a mark whose ETAS assignment has not yet been recorded?

  6. GitHub ToS interaction with securities-adjacent code. Raxx's private repos contain Raptor (backend) and MQ-A (algo layer), which are adjacent to securities-execution tooling. Does the GitHub Data Protection Agreement's data-controller / data-processor framing create any obligation for Raxx as data controller once the GH org houses production code that processes user trade data? Any GitHub ToS clause that would restrict housing such code in a private org repo? Primary sources: https://github.com/customer-terms/github-data-protection-agreement and https://docs.github.com/en/site-policy/github-terms/github-corporate-terms-of-service

Priority for this consult: J1 and J2 are highest priority — resolve before the repo transfer is made permanent. J3 may have a hard deadline of approx. 2026-06-15 (40 days from 2026-05-06) under Cal. BPC §17910 — flag this date at the top of the consult.

K) RAXX trademark §2(d) conflict — Crosby signal 2026-05-05 (added 2026-05-06)

(Background: docs/legal/research/raxx-tm-conflict-analysis-2026-05-06.md, docs/legal/research/ramp-payment-solutions-raxx-ownership-2026-04-30.md. Priority: HIGH — Matthew Crosby replied 2026-05-05 18:13 UTC signaling that the proposed identification amendment does not materially reduce §2(d) risk. Decision required before filing or pivoting.)

Context: The cited RAXX registration (Reg. 7779396, Ramp Payment Solutions LLC, Class 36) covers broad payment-processing and financial-transaction services. Crosby confirmed the USPTO will analyze the cited registration's identification text — not the registrant's actual commerce (bar/restaurant POS in Wisconsin) — when assessing likelihood of confusion under TMEP § 1207.01(a)(iii). Raxx's tightened identification (options trading software, Classes 9 and 42) is in different classes but the financial-technology surface overlap may still trigger a §2(d) refusal. The GitHub org github.com/raxx-app (business name "Raxx") was created 2026-05-05 UTC, increasing brand investment in RAXX. No trademark application has yet been filed.

  1. §2(d) probability assessment. Given the cited registration's full identification text (provided in Crosby's 2026-05-05 letter), what is your current assessment of likelihood-of-confusion probability for our application as filed with the tightened description? Is this "likely OA / winnable response" or "near-certain OA / outcome uncertain"? What is the probability of successful registration after OA response?

  2. §14 cancellation vulnerability. Is Reg. 7779396 vulnerable to cancellation under 15 U.S.C. § 1064? (a) Pull the TSDR file wrapper on Serial 97826727 — does the specimen actually support the breadth of the identification, particularly "financial transaction services" and "online payment platform"? (b) What is the exact registration date of Reg. 7779396, and is the 5-year incontestability window still open? (c) Given that Ramp Payment Solutions appears to be actively using the mark (raxxpay.com, active annual DFI filings), is a non-use cancellation petition viable?

  3. Coexistence agreement feasibility. Should we proactively approach Ramp Payment Solutions LLC (CEO: Pam Koski, raxxpay.com) about a consent/coexistence agreement? What is the realistic probability they would consent given their profile (small regional Wisconsin MSP, no identified IP counsel, no TTAB history)? What leverage do we have, and what might they ask for?

  4. Office action cost + timeline. If we file and receive a §2(d) OA, what is the realistic attorney-fee budget for OA response through final disposition? What is the timeline from filing to registration assuming one OA round? Two OA rounds?

  5. Brand pivot threshold. At what point does the §2(d) risk and expected contest cost exceed the cost of a brand pivot? The operator has created github.com/raxx-app (2026-05-05 UTC), holds raxx.app and getraxx.com, and has a growing codebase under the Raxx name. What is your recommendation on the pivot-vs-fight decision at this brand investment level?

  6. GitHub org interaction with conflict analysis. Does the creation of github.com/raxx-app (business name "Raxx," 2026-05-05 UTC) affect the channels-of-trade distinction argument in any way that is useful for a potential OA response? Does it establish or support a date-of-use record worth documenting?

Priority: K1 and K2 are the highest-priority questions in this section. K1 determines whether to file at all; K2 determines whether the cited registration itself can be removed. These questions should be addressed in the next communication with Crosby before any filing decision is made.

Questions by priority

Must answer this consult: - B1, B2, B3 (entity + state) - C1, C2, C4 (MOOSEQUEST status + assignment) - E1 (founder IP assignment) - H1, H2 (data licensing — hard blocker for MBT backtester) - J1, J2 (GH org authority attestation + IP chain of title — resolve before repo transfer) - K1, K2 (RAXX §2(d) probability + §14 cancellation vulnerability — URGENT)

Has potential hard deadline (approx. 2026-06-15): - J3 (CA DBA filing — 40 days from 2026-05-06 under Cal. BPC §17910)

Would be valuable: - A1–A5 (engagement terms) - D1, D2 (Raxx clearance + filing timing) - F3 (securities perimeter) - H3, H4 (Polygon + Alpaca licensing scope) - I1, I4 (investment-adviser perimeter + ToS/PP drafting scope) - J4, J5 (PA DBA + trademark sequence) - K3, K4 (coexistence agreement + OA cost/timeline)

Can defer to follow-up: - B4, B5, B6 (holding structure, QSBS, Series LLC) - D3, D4 (Raxx class strategy, brand-pivot analysis) - E2 (contractor IP template) - F1, F2 (SaaS contracts, GDPR / CCPA) - H5 (EU data transfer flag — only relevant if EU users onboarded) - I2, I3, I5, I6 (disclaimer text, SLA language, CAN-SPAM, confidentiality legend) - J6 (GitHub ToS / DPA interaction with securities-adjacent code) - K5, K6 (pivot threshold + GH org interaction)

This document is preparation material only. The attorney's answers — not this document — are the actionable output.