Pactory | Devpost

Pactory Thumbnail
Pactory Diagram/Thumbnail

Inspiration

Pactory started with a simple question: where does trust actually break down, and where can code replace it?

Today, brand deals make up 70% of creator income, yet the payment process is stuck in the 1990s. Creators finish their work and then "wait and pray" for a check. Sponsors take on massive risks paying upfront with no guarantee of ROI. This friction causes 58% of creators to struggle with monetization despite a 54% YoY growth in the industry.

Smart contracts work best when outcomes are objective, not subjective. While it’s unrealistic to encode something like legal judgment or creative quality, many real-world agreements already rely on clear, measurable results.

We realized that creator success isn't subjective anymore—it's data-driven. Views, engagement, and reach are public, measurable, and verifiable. If performance is objective, payment shouldn’t depend on a human clicking "send" weeks later.

It should be a function of the code.

Pactory was built around that insight. Instead of promises, Pactory runs on proof.

What it does

Pactory is a programmable escrow for creator sponsorships It allows brands and creators to create on-chain sponsorship agreements where money is locked before work begins, payout terms are transparent, and earnings unlock automatically based on real performance.

A sponsor creates a pact by defining:

The creator’s wallet address
A campaign duration
Performance-based payout milestones (e.g. $1 per 1,000 views)
Optional all-or-nothing bonus incentives

Once the creator reviews and accepts the pact, the sponsor funds it. The funds are held in a smart contract escrow that neither party can manipulate.

After the creator publishes their video, Pactory automatically tracks engagement metrics like views and calculates how much of the payout has been unlocked. Creators can claim their earnings at any time, and when the campaign ends, unearned funds are refunded to the sponsor.

Every step --> funding, progress, payouts --> is visible and verifiable on-chain.

How we built it

Pactory is built as a three-layer system, each with a clear responsibility.

Interface (Frontend)

The frontend is a web app built with vanilla JavaScript and Ethers.js. It handles:

Wallet connection and role selection (sponsor vs creator) Pact creation and negotiation Viewing live payout progress Triggering on-chain actions like funding and claiming payouts

All blockchain interactions happen directly from the user’s wallet, ensuring that private keys never touch the backend.

Oracle/Coordination Layer (Backend)

The backend is built with Node.js, Express, and SQLite. It acts as a coordination and utility layer:

Manages pact negotiation state (sent for review, accepted, created) Stores pact metadata and video links Scrapes engagement metrics from platforms like TikTok and YouTube using Apify Computes how much payout should be unlocked based on current performance Crucially, the backend cannot move funds. Even if it goes offline, all locked funds remain safe and claimable directly from the smart contract.

Source of Truth (Solidity)

At the core is a Solidity escrow contract deployed on Ethereum (Mainnet or Sepolia testnet).

The contract:

Holds sponsored funds in escrow Enforces payout rules exactly as defined Tracks how much has been claimed Automatically refunds unearned funds at the end of a pact The smart contract is the source of truth! The backend and frontend are replaceable… the funds are not.

Challenges we ran into

One of our biggest challenges was ensuring the smart contract could "trust" the view counts coming from our backend. In a decentralized system, the backend is a point of failure. The Struggle: If our backend was hacked, a malicious actor could spoof 1 million views and drain the escrow. The Engineering Fix: We implemented a Cryptographic Acknowledgment Pattern. Instead of the backend simply "sending" data to the blockchain, the backend generates an ECDSA signature (using MessageHashUtils and ECDSA from OpenZeppelin) that vouches for a specific pactId and viewCount. The smart contract then recovers the signer's address to verify it matches our authorized server. This ensures that even if a user interacts directly with the contract, they cannot claim funds without a valid, server-side proof of performance.

Then, we hit a massive wall when moving from a local development environment to a distributed production stack. The Struggle: We faced "CORS (Cross-Origin Resource Sharing) Hell" because our Vercel frontend, Railway backend, and Alchemy RPC nodes were all on different origins. The Engineering Fix: We had to move beyond simple cors(*) wildcards, which are insecure for Web3 apps, and implement a robust whitelist strategy and manual Preflight (OPTIONS) request handling in Express. We also had to synchronize ChainIDs across the stack to ensure the frontend didn't attempt to fund a Sepolia pact while the user was on Mainnet, leading to a custom "Network Guardian" component in our React logic.

Developing the PactEscrow.sol contract was also a lesson to be learned! The Struggle: Early versions of our contract had "Locked State" bugs where a rejected pact would leave funds in limbo if the creator never set a video link. The Engineering Fix: We re-architected the contract as a strict State Machine with five distinct phases: Null, Proposed, Funded, Active, and Finalized. We utilized the Checks-Effects-Interactions pattern to prevent reentrancy and added a refundAfterDeadline fail-safe. Writing the Foundry test suite to simulate these edge cases (like a creator claiming mid-campaign vs. a sponsor refunding after a ghosted project) was the most grueling, but rewarding, part of the build.

We also spent a lot of time refining the UI and user flow. Sponsorships involve multiple steps and roles, and making that feel intuitive, without overwhelming users, was harder than it looked. Features like role switching, guided tours, and clean state transitions required multiple redesigns and refactors.

On the technical side, this was our first time building a full Web3 stack from scratch. Learning Solidity, understanding how escrow contracts should be structured, and figuring out how frontend wallets interact safely with smart contracts involved a lot of trial, error, and many Cyfrin Updraft & YouTube tutorials.

Lastly, being "production-ready" means testing in conditions that mimic the real world, and for us, that meant the MNEE Sandbox. However, reality hit hard when the testnet faucet went dry. We spent hours architecting our flow around the MNEE token, only to realize we couldn't get the test assets needed to actually trigger the fund() function. The Pivot: Instead of waiting, we took a "builder-first" approach. We pivoted to writing and deploying our own MockMNEE.sol contract—a 1:1 mirror of the MNEE interface—complete with a custom minting function. This allowed us to simulate the entire lifecycle of a sponsorship, from token approval to performance-based claims, without being blocked by external infrastructure. It was a crash course in "don't wait for the tool—build the tool."

Accomplishments that we're proud of

Production Architecture We didn't just build a "Happy Path" demo; we built a production-ready protocol capable of handling real capital. Our architecture successfully decouples the data layer (Web2 scraping) from the settlement layer (Ethereum), ensuring that even if our backend infrastructure were compromised, the smart contract remains an immutable vault. The funds are governed by code, not by our database.

High-Fidelity UX for Complex DeFi Most escrow tools are clunky and intimidating. We successfully built a dynamic Payout Engine that visualizes complex "Linear + Milestone" payment curves.

The Payout Graph: We engineered a custom visualization tool using SVG and vanilla JS logic that calculates the derivative of the payout function. This allows sponsors to see exactly where their "Performance Sweet Spot" is before they lock a single token.

Resilient Frontend: By sticking to vanilla JavaScript and Ethers.js, we achieved a lightning-fast initial load and eliminated the "framework bloat" that often causes wallet-connection lag in modern dApps.

"Mainnet-Ready" Rigor Pactory is not just a hackathon experiment—it is deployment-ready. We’ve battle-tested the logic for:

MNEE Token Integration: Fully supporting the MNEE ecosystem with proper decimal handling and approve/transferFrom workflows.

State Recovery: If a user’s browser crashes mid-transaction, the system recovers the state from the blockchain and the SQLite cache, ensuring no "lost" pacts.

Production DevOps: We moved beyond localhost to a multi-cloud environment (Railway + Vercel) with a hardened API layer featuring rate-limiting and signature-based authentication for all destructive actions.

What we learned

We gained a deep mastery of the Web3 Security Lifecycle. We learned that writing the contract is only 20% of the work; the other 80% is "defensive engineering"—preventing reentrancy, managing gas price volatility, and ensuring that the UI provides clear feedback during the "pending" state of a transaction.

We also learned the power of hybrid systems. While the blockchain is great for settlement, a traditional SQL database (SQLite in WAL mode) is vastly superior for providing the "snappy" experience creators expect when checking their view counts. Balancing these two worlds taught us how to build applications that feel like Web2 but have the soul of Web3.

Last but not least, we realized that for creator sponsorships, the choice of token isn't about hype—it’s about settlement finality. Traditional bank wires take 3–5 days and have zero programmability. By using MNEE, we were able to link the "Payment Rail" directly to the "Engagement Data." This allows us to move away from the "invoice and pray" model toward a model where the currency itself is aware of the contract terms. It’s a boring but powerful upgrade to how creators get paid.

What's next for Pactory

Pactory is already configured for a Mainnet deployment, but we aren't stopping at the MVP. Our roadmap focuses on turning this from a tool into a full-scale sponsorship operating system.

AI-Assisted "Pact Drafting" Currently, users manually define milestones. We plan to integrate a fine-tuned LLM to assist in contract creation. A sponsor could simply describe their goal—"I want a campaign for a fitness app with a focus on long-term retention"—and the AI will suggest optimized, performance-based payout curves and milestone triggers based on historical creator data. This lowers the barrier to entry for brands who aren't yet "fluent" in performance-based math.
Multi-Channel Notifications & "Pact Alerts" We’ve realized that the "check the dashboard" workflow is a friction point. We are implementing a Notification Engine using Push Protocol (formerly EPNS) and XMTP.

Sponsors will receive real-time pings when a creator links a video or when a major view milestone is hit.

Creators will get "Payment Unlocked" alerts directly to their wallets or mobile devices, eliminating the need to constantly refresh the UI to see if their earnings are ready to claim.

Omni-Platform Campaign Aggregation Sponsorships rarely happen on just one platform. Our next major technical milestone is allowing a single Pact to aggregate data across TikTok, IG, and YouTube simultaneously. One MNEE-backed escrow will handle a cross-platform campaign, automatically calculating the "Total Reach" and releasing funds accordingly.
Yield-Bearing Escrow While funds are locked in the PactEscrow contract, they represent idle capital. We plan to explore a "Yield-Split" feature where the locked MNEE can be deposited into a liquidity pool or staking vault. The interest generated during the campaign can be used to automatically cover the creator’s gas fees when they claim their payout, making the protocol effectively "free" to use for the talent.