whitelist: add getbags.app + *.getbags.app (BAGS — Solana Merchant of Record)#1817
whitelist: add getbags.app + *.getbags.app (BAGS — Solana Merchant of Record)#1817VedantAnand17 wants to merge 1 commit into
Conversation
BAGS is a Merchant of Record / payment-infrastructure product. The production checkout dApp lives at https://www.getbags.app/pay/* and signs a single bounded SPL USDC Transfer to the merchant's ATA per cart. The domain is currently being soft-flagged in Phantom (hard "Request blocked" dialog on Solana connect/sign). A concurrent allowlist request has been sent to review@phantom.com (cc review@blowfish.xyz). This PR adds the apex + wildcard to whitelist.yaml so we are shielded if the domain ever lands in fuzzylist.
📝 WalkthroughWalkthroughThe PR updates ChangesWhitelist Domain Expansion
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
whitelist.yaml (1)
34-35: Establish formal whitelist governance and monitoring.Security whitelists require robust operational processes to protect users. Consider implementing:
Whitelist addition process:
- Documented criteria (domain age, security audit requirements, ownership verification)
- Multi-party approval (security team + operations)
- Staged rollout or probationary periods for new domains
- Public transparency log for whitelist additions
Ongoing monitoring:
- Automated monitoring of whitelisted domains for compromise indicators (certificate changes, DNS changes, content changes)
- Regular security re-audits (especially for young domains)
- User feedback channels for reporting suspicious activity
- Incident response plan for compromised domains
Tiered trust model:
- Consider trust tiers (established platforms vs new services)
- Different security policies per tier
- Gradual promotion based on security track record
- Separate "provisional whitelist" with enhanced monitoring for domains <6 months old
Documentation:
- Maintain a SECURITY.md or similar file documenting the whitelist process
- Include in CONTRIBUTING.md guidelines for whitelist requests
- Keep audit trail of all whitelist decisions
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@whitelist.yaml` around lines 34 - 35, The whitelist currently contains entries for getbags.app and "*.getbags.app" but lacks governance and monitoring; add a documented whitelist governance process by creating/updated SECURITY.md and CONTRIBUTING.md describing documented criteria (domain age, ownership verification, security audit), multi-party approval workflow, staged/probationary rollout and a provisional whitelist tier for domains <6 months; implement operational controls referenced in docs (automated monitoring for cert/DNS/content changes, periodic re-audits, user reporting channel, incident response steps) and an audit trail for all changes to the whitelist (including entries like getbags.app and "*.getbags.app") with metadata (requestor, approvers, timestamps, tier).
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@whitelist.yaml`:
- Around line 34-35: Add required verification and approval artifacts for the
new whitelist entries in whitelist.yaml: attach documented ownership
verification (e.g., DNS TXT, /.well-known proof, or signed wallet message) and
reference the exact proofs next to the url: getbags.app and url: "*.getbags.app"
entries, record an explicit security team approval note (reviewer name, date,
and checklist) and link any security audit or bounded-on-chain-behavior report;
if wildcard scope is not justified, narrow or remove the "*.getbags.app" entry
and include rationale for any remaining wildcard usage in the same documentation
block.
- Line 35: The wildcard entry "*.getbags.app" in the whitelist.yaml is too
permissive; remove that wildcard line and replace it with explicit allowed hosts
such as the apex domain "getbags.app" and only the specific subdomains needed
for the PR (e.g., "www.getbags.app" and the exact subdomain(s) serving the
checkout/pay flow like "pay.getbags.app" or "checkout.getbags.app"); ensure the
whitelist contains only these explicit host entries and not a wildcard to limit
attack surface and allow granular revocation.
---
Nitpick comments:
In `@whitelist.yaml`:
- Around line 34-35: The whitelist currently contains entries for getbags.app
and "*.getbags.app" but lacks governance and monitoring; add a documented
whitelist governance process by creating/updated SECURITY.md and CONTRIBUTING.md
describing documented criteria (domain age, ownership verification, security
audit), multi-party approval workflow, staged/probationary rollout and a
provisional whitelist tier for domains <6 months; implement operational controls
referenced in docs (automated monitoring for cert/DNS/content changes, periodic
re-audits, user reporting channel, incident response steps) and an audit trail
for all changes to the whitelist (including entries like getbags.app and
"*.getbags.app") with metadata (requestor, approvers, timestamps, tier).
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
| - url: getbags.app | ||
| - url: "*.getbags.app" |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Verify domain ownership claims and check for existing verification documentation
echo "=== Checking for ownership verification documentation ==="
# Search for any verification docs, security reviews, or approval trails
rg -i "getbags\.app|verification|ownership|approval|security.*review" --type md --type txt -C 3
echo -e "\n=== Checking for whitelist addition process documentation ==="
# Look for documented whitelist addition process
fd -e md -e txt | xargs rg -l "whitelist.*process|whitelist.*criteria|whitelist.*approval" | head -5
echo -e "\n=== Checking git log for PR approval/review ==="
# Check recent commits for review/approval patterns
git log --oneline --grep="review\|approve\|verify" -10
echo -e "\n=== Checking for security policy documentation ==="
fd SECURITY.md README.md CONTRIBUTING.md | head -5Repository: phantom/blocklist
Length of output: 530
🌐 Web query:
What are the current best practices for domain age requirements in crypto wallet whitelists?
💡 Result:
In the context of crypto wallet whitelisting, domain age is not considered a primary or standalone security control [1][2]. While it can serve as a supplemental signal for risk assessment, relying on it as a foundation for security is discouraged due to its limitations in modern threat landscapes [1][2]. Current best practices for securing crypto wallet whitelists focus on robust identity verification, multi-party governance, and behavioral analysis rather than domain age [3][4][5]. Key Security Practices for Wallet Whitelists: 1. Identity and Control Verification: Before an address is added to a whitelist, the owner should complete Know Your Customer (KYC) checks [3][5]. Additionally, the user should prove control over the wallet, typically by signing a cryptographic message [3][4][5]. 2. Multi-Approver Governance: To prevent unauthorized changes, whitelist modifications should require approval from multiple authorized individuals [3][4]. This mitigates the risk of a single compromised account or malicious insider modifying destination addresses [3][4]. 3. Activation Delays: Implementing a mandatory waiting period (e.g., 24 hours) after a new address is added to a whitelist provides a critical window to detect and reverse unauthorized additions [5]. 4. Comprehensive Risk Screening: Addresses should be screened against sanctions lists and monitored for links to known fraudulent activity or high-risk entities [3][4][5]. 5. Limitations of Domain Age: While some automated tools use domain age to flag potentially suspicious sites or services, it is an imperfect metric [1][2]. Attackers frequently bypass age-based filters by using aged domains purchased on secondary markets, compromising legitimate sites, or aging domains before launching campaigns [2]. Consequently, security strategies should prioritize comprehensive threat intelligence, behavioral analysis, and strict access controls over domain age thresholds [1][2]. In summary, while domain age may provide limited supplemental value in automated filtering, it should not be relied upon as a primary security mechanism for crypto wallet whitelisting [1][2]. Instead, organizations should implement layered defenses centered on identity verification, multi-party approval, and continuous monitoring [3][4][5].
Citations:
- 1: https://www.skyhighsecurity.com/threat-research/domain-age-as-an-internet-filter-criterion.html
- 2: https://alluresecurity.com/blog/domain-age-myth-detection-limits/
- 3: https://stripe.com/en-be/resources/more/crypto-whitelist-strategy
- 4: https://www.investimentimagazine.it/whitelist-per-criptovalute-guida-pratica-per-team-e-servizi/
- 5: https://stripe.com/en-cy/resources/more/crypto-whitelist-strategy
Document verification process and security approval before merging.
Adding domains to this whitelist bypasses security checks in Phantom wallet. While the commit references "BAGS — Solana Merchant of Record," the following documentation gaps must be resolved:
-
No verification documentation: Neither ownership verification (DNS TXT, /.well-known, wallet signatures) nor any approval evidence exists in the repository or PR.
-
Missing approval from security team: No documented approval from security reviewers is included.
-
Unverifiable security claims: Claims about bounded on-chain behavior cannot be verified from configuration changes and require audit documentation.
-
Wildcard scope: The pattern
*.getbags.appwhitelists all subdomains, which should be justified or narrowed if possible.
Required before merge: Document completed ownership verification, explicit security team approval, and security audit results validating the dApp's on-chain behavior.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@whitelist.yaml` around lines 34 - 35, Add required verification and approval
artifacts for the new whitelist entries in whitelist.yaml: attach documented
ownership verification (e.g., DNS TXT, /.well-known proof, or signed wallet
message) and reference the exact proofs next to the url: getbags.app and url:
"*.getbags.app" entries, record an explicit security team approval note
(reviewer name, date, and checklist) and link any security audit or
bounded-on-chain-behavior report; if wildcard scope is not justified, narrow or
remove the "*.getbags.app" entry and include rationale for any remaining
wildcard usage in the same documentation block.
| - url: nftplus.io No newline at end of file | ||
| - url: nftplus.io | ||
| - url: getbags.app | ||
| - url: "*.getbags.app" |
There was a problem hiding this comment.
Wildcard subdomain pattern significantly amplifies security risk.
The *.getbags.app wildcard pattern allows ALL subdomains to bypass security checks, which creates multiple risk vectors:
-
Expanded attack surface: If DNS or hosting is compromised, attackers can create arbitrary malicious subdomains that inherit whitelist status.
-
No subdomain isolation: Different subdomains may serve different purposes with varying security levels (e.g., staging vs production, admin vs public), but all receive the same trust level.
-
Difficult remediation: Revoking access requires removing the entire wildcard entry, potentially disrupting legitimate services.
Comparison with existing wildcards: Other wildcards in this file (e.g., *.github.io, *.netlify.app, *.vercel.app) are for established hosting platforms with their own security controls and cannot be arbitrarily manipulated by a single entity.
Recommendation:
- Preferred: Limit to specific subdomains that require whitelisting (e.g.,
checkout.getbags.app,pay.getbags.app) - Alternative: Start with apex domain only (
getbags.app) and expand based on demonstrated need and security track record
🔒 Suggested change to use specific subdomain(s)
Based on PR objectives mentioning "production checkout dApp at https://www.getbags.app/pay/*", consider:
- url: nftplus.io
- url: getbags.app
- - url: "*.getbags.app"Or if subdomains are required, specify them explicitly:
- url: nftplus.io
- url: getbags.app
- - url: "*.getbags.app"
+ - url: pay.getbags.app
+ - url: checkout.getbags.app📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - url: "*.getbags.app" | |
| - url: getbags.app |
| - url: "*.getbags.app" | |
| - url: getbags.app | |
| - url: pay.getbags.app | |
| - url: checkout.getbags.app |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@whitelist.yaml` at line 35, The wildcard entry "*.getbags.app" in the
whitelist.yaml is too permissive; remove that wildcard line and replace it with
explicit allowed hosts such as the apex domain "getbags.app" and only the
specific subdomains needed for the PR (e.g., "www.getbags.app" and the exact
subdomain(s) serving the checkout/pay flow like "pay.getbags.app" or
"checkout.getbags.app"); ensure the whitelist contains only these explicit host
entries and not a wildcard to limit attack surface and allow granular
revocation.
1 participant
Summary
Adds
getbags.appand*.getbags.apptowhitelist.yaml.Who we are
BAGS (https://www.getbags.app) is a Solana payment processor / Merchant of Record for SaaS and AI companies. The production checkout dApp at
https://www.getbags.app/pay/*signs a single, bounded SPL USDCTransferinstruction from the buyer's USDC ATA to the merchant's USDC ATA on Solana mainnet (USDC mintEPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v). NosetAuthority, noapprove, nosignAllTransactions, no unbounded SOL transfers — only the displayed cart amount to the merchant treasury.Domain ownership
We control
getbags.app. Production is live at https://www.getbags.app. Public docs at https://docs.getbags.app. We can satisfy any additional ownership proof on request — TXT record,/.well-known/file, signed-message-from-wallet, video call, whatever the review team prefers. The site already publishes machine-readable identity at/.well-known/api-catalog,/.well-known/oauth-protected-resource,/.well-known/agent-skills/index.json, and/.well-known/mcp/server-card.json.Why this PR
The domain is currently being soft-flagged inside Phantom — buyers see a hard "Request blocked — This dApp could be malicious" dialog on Solana connect/sign. Likely cause is automated reputation heuristics (the domain is ~3 months old; earliest CT cert 2026-02-22). The Solana code path is clean; we just need an allowlist entry.
A concurrent allowlist request was emailed to review@phantom.com (cc review@blowfish.xyz) on 2026-05-17. This PR is the defensive companion so we're also shielded if the domain ever ends up in
fuzzylist.yaml.Change
```yaml
whitelist.yaml — appended
```
Format follows the existing entries (e.g.
- url: \"*.vercel.app\") and the README's wildcard guidance (quoted,*.prefix for subdomain coverage).Contact
Reachable via the concurrent email to review@phantom.com if you'd like to discuss before merge. Happy to provide audit reports, on-chain treasury addresses, KYC/compliance partner info, or anything else useful.
Made with Cursor
Summary by CodeRabbit