Security-First by Design

MATRIX is built on three security pillars: Stripe escrow with manual capture, Supabase Row-Level Security (RLS), and a transparent dispute resolution process. Here's exactly how each layer works.

How Escrow Works on Stripe (Manual Capture)

MATRIX uses Stripe's manual capture payment flow, which is the industry-standard approach for escrow-style transactions. Here's what happens at each stage:

1. Authorization (Funding): When you fund a mission, Stripe authorizes the payment on your card. The funds are earmarked and held by Stripe, but not yet transferred to anyone. This is similar to how a hotel holds a deposit when you check in — the money is reserved, not moved.
2. Escrow Holding Period: During the mission, the authorized funds sit in Stripe's custody. MATRIX never touches the money. The worker cannot access it. Only you (the mission creator) can trigger the next step. Stripe's PCI Level 1 compliant infrastructure protects the authorization during this entire period.
3. Capture (Release): When you click "Release Payment," MATRIX sends a capture request to Stripe. Stripe then completes the transaction and the funds move from your card to the MATRIX platform, where they're immediately disbursed to the worker's payout method.
4. Expiration & Refund: If a mission is cancelled before the worker accepts, the authorization is released and the funds are never captured. Your card is never charged — only the temporary hold disappears (typically within 5-7 business days depending on your bank).

This manual capture approach means that MATRIX never has custody of your money. Stripe — a publicly traded, audited financial institution with millions of merchants worldwide — holds the authorization. The only way funds change hands is through your explicit action. This is fundamentally different from platforms that collect money into their own accounts and act as a bank.

Platform-Secured vs. Immutable — An Honest Distinction

We believe in transparency, so we want to be clear about the security model. MATRIX uses a platform-secured architecture, not a truly immutable one. Here's what that means in practice:

Platform-Secured (How MATRIX Works): Your data — missions, proof submissions, profile details — is stored in a Supabase PostgreSQL database protected by Row-Level Security (RLS) policies. These policies ensure that only authenticated users with the correct permissions can read or write specific rows. A mission creator can only see their own missions; a worker can only see missions they accepted. No user can access another user's financial data. The platform administrator has access to the database schema and can perform administrative actions (like resolving disputes or restoring accounts). This is the standard model for SaaS applications — it's secure, auditable, and admin-controlled.

Immutable (What We Don't Do): An immutable system — like a blockchain-based escrow smart contract — would guarantee that no human (including platform admins) could alter the transaction history. Every action would be permanently recorded on a distributed ledger with no backdoor. While this sounds ideal in theory, immutable systems come with significant trade-offs: they're slower, more expensive, cannot handle dispute resolution gracefully (a smart contract can't evaluate "did the worker deliver quality work?"), and provide no customer support recourse if something goes wrong.

MATRIX chose the platform-secured model deliberately. It gives us the ability to mediate disputes, reverse accidental payments, comply with financial regulations, and provide real customer support. We back this with strict internal access controls, audit logs, and quarterly security reviews. If you need immutable guarantees for specific transactions, we're actively exploring escrow smart contract integrations for enterprise customers — contact us for details.

Supabase RLS Policies — How They Work

Every database query on MATRIX passes through Supabase's Row-Level Security system. RLS is a PostgreSQL feature that attaches SQL policies to tables — think of them as automated gatekeepers that check every request. Here are the key policies:

• Missions Table: Users can SELECT missions where they are the creator (creator_id = auth.uid()) or the assigned worker (worker_id = auth.uid()). INSERT is allowed for any authenticated user creating a mission. UPDATE is restricted to the creator (for status changes) or the assigned worker (for accepting and submitting proof).
• Profiles Table: Users can SELECT their own profile only. INSERT happens on signup (via a Supabase trigger). UPDATE is restricted to the profile owner — no user can modify another user's name, role, or banking details.
• Proof Submissions: Linked to mission IDs with the same RLS cascade — only the mission creator and the assigned worker can view proof files. Geo-location metadata and timestamps are immutable once recorded (write-once policy via a Supabase trigger).

These policies ensure that even if an authentication token were compromised, the attacker could only access data belonging to that specific user account. They couldn't enumerate users, view other missions, or read financial information. Combined with Supabase's built-in rate limiting, CAPTCHA on signup, and email verification, the attack surface is dramatically reduced.

Geo-Tagged Proof Submissions

When a worker submits proof of completion, the browser captures the GPS coordinates and a precise timestamp using the Geolocation API. This metadata is bundled with the uploaded files and stored as an immutable audit record:

• Location: Latitude and longitude coordinates at the time of submission, providing geographic proof of where the work was completed.
• Timestamp: Server-verified timestamp (from Supabase's now() function), not a client-side time that could be manipulated.
• File Hash: Each uploaded file is hashed (SHA-256) on the client before upload, creating a fingerprint that can verify file integrity later.

This geo-tagged trail is invaluable for location-dependent work — photography assignments, site inspections, delivery verification, event coverage, and any mission where knowing "when and where" the work was done matters as much as the work itself.

Dispute Resolution Process

When a dispute is raised, the mission freezes immediately — no further status changes, no payment releases, no fund movements. Both parties then submit evidence through the platform. A MATRIX administrator reviews the complete mission history, including:

• The original mission requirements and budget specified by the client.
• All proof submissions from the worker (files, geo-tags, timestamps).
• Any communication history between both parties.
• Previous mission history and reputation of both users.

The admin delivers a resolution within 48 hours. Options include: full payment to the worker (work meets requirements), full refund to the client (work was insufficient or not delivered), or a proportional split based on partial completion. Both parties receive a detailed written explanation of the decision. An appeal process is available with additional evidence review within 24 hours.

Security Comparison