The architecture of smART follows a decentralized model that integrates on-chain logic, event indexing, distributed storage, and a modern Web3 interface. Its goal is to minimize intermediaries in freelancer-client interactions and ensure transparency, integrity, and impartial dispute resolution.

The platform is structured into four layers: a blockchain layer that executes the core business logic, an off-chain event indexing and processing layer, a frontend DApp layer that enables users to interact seamlessly with the system, and a set of providers that supply RPC access, wallet connectivity, and decentralized file storage. It also includes a GenAI validation service backed by PostgreSQL and Redis for caching and fast retrieval.

Figure 1. smART system architecture.

• Frontend Web3: DApp built with Scaffold-ETH 2 and deployed on Vercel.
• Ponder: Framework for indexing on-chain events into a relational PostgreSQL database.
• GenAI Validation Service: Multimodal model for deliverable verification, backed by PostgreSQL and Redis.
• IPFS: Distributed storage for large deliverables and dispute evidence.
• Smart Contracts: Handle state transitions, payments, deadlines, and contract lifecycle.
• Kleros: Decentralized arbitration system used for resolving disputes through juror voting.

The user interface is built on Scaffold-ETH 2, which provides wallet connectivity, contract interaction hooks, and reusable Web3 components. The stack consists of TypeScript, React, HTML and CSS. The final DApp is deployed on Vercel as a Platform-as-a-Service (PaaS), enabling fast iteration and continuous delivery. The frontend primarily integrates the MetaMask wallet provider for user authentication and transaction signing, although compatibility with additional wallets is also maintained.

Since several application views require aggregated or historical information, Ponder listens to blockchain events and synchronizes them into a PostgreSQL database. This enables efficient querying of listings, contract histories, user activity, and dispute states. It requires an Alchemy RPC provider to connect to the Ethereum network and process new blocks in real-time.

An AI model analyses submitted deliverables to verify whether they align with the work agreed upon. This component leverages Google's Gemini models, integrating text and image understanding to evaluate both relevance and quality of the content. The results are cached through two layers: PostgreSQL for persistence and Redis for fast retrieval, reducing repetitive inference and improving performance.

Large audiovisual deliverables and dispute evidence are stored in IPFS. IPFS (InterPlanetary File System) is a peer-to-peer distributed file system that seeks to connect all computing devices with the same system of files. Uploaded files are identified by their content hash. Only the resulting hash is written on-chain, allowing the blockchain to act as an integrity verifier while avoiding the cost of storing large files directly on the network. The provider used for IPFS uploads is Pinata.

The blockchain layer manages the lifecycle of each work agreement, ensuring deterministic and verifiable execution. Smart Contracts enforce deadlines, freeze and release funds, and record immutable references to off-chain assets. They were written using Solidity, and the primary tool used for development, testing, and deployment is Hardhat. Their internal logic will be explained in the Smart Contract Logic section.

Disputes between freelancers and clients are resolved through Kleros, which assigns a random set of jurors who analyze the evidence and vote on the outcome. The system includes fee deposits, reimbursements, and an appeal mechanism with additional staking incentives to discourage frivolous claims.

The platform relies on four primary smart contracts written in Solidity and deployed using Hardhat. Each contract serves a specific purpose in the ecosystem, working together to manage work agreements, user profiles, and dispute resolution in a decentralized manner. These were all deployed on the Ethereum Sepolia testnet for testing and demonstration purposes.

The main smart contracts deployed on the Ethereum Sepolia testnet are:

This contract manages the Talent marketplace, where freelancers post service offerings (Talents) and clients can hire them by creating specific work orders (HiredTalents). The workflow follows these stages:

• Talent Creation: Freelancers publish their services with base pricing, estimated duration, and minimum notice time.
• HiredTalent Request: Clients create work orders under existing Talents, depositing the agreed payment amount in escrow.
• Acceptance: Freelancers accept or reject incoming requests. Upon acceptance, a deadline is set based on the estimated duration.
• Deliverable Submission: Freelancers upload their work deliverables, which are stored as IPFS hashes on-chain.
• Deliverable review: Clients review the submitted work. They can either approve it, request revisions, or raise a dispute.
• Completion Confirmation: Once the client approves the work, the payment is released to the freelancer.
• Rating System: Clients can rate completed work on a 1-5 scale to build reputation.
• Cancellation: Either party can initiate cancellation. If both agree during the ongoing phase, the client receives a full refund.

This contract handles the Gig marketplace, where clients post work requests and freelancers apply with proposals. The process differs from Talents in that clients initiate the job posting:

• Gig Creation: Clients post job requests with descriptions, maximum duration, and base payment amounts.
• Application Submission: Freelancers submit proposals with their proposed payment, timeline, and pitch comments.
• Application Management: Clients can accept, reject, or review multiple applications. Freelancers can withdraw pending applications.
• Acceptance & Payment: When a client accepts an application, they deposit the agreed payment amount and the gig transitions to in-progress state.
• Deliverable Submission: Same as in HiredTalents, freelancers upload their work deliverables, stored as IPFS hashes on-chain.
• Deliverable Review: Clients review the submitted work. They can approve it, request revisions, or raise a dispute.
• Rating System: Clients rate completed gigs to build freelancer reputation scores.
• Cancellation: Similar to HiredTalents, with mutual agreement required for refunds during the ongoing phase.

A dedicated contract for managing user profiles on the platform. It stores and validates user information including:

• Username, biography, and email address
• Profile and banner images (stored as IPFS hashes)
• Social media links (X/Twitter, Instagram, LinkedIn, ArtStation, Sketchfab, custom URLs)

The contract enforces length constraints on all fields and validates URL formats for social media links. Profile data is mapped by wallet address and can be updated by the owner at any time.

This contract serves as the interface layer between smART and Kleros for dispute resolution. It implements a unified dispute management system that handles:

• Dispute Creation: Generates internal dispute IDs that map to external Talent/Gig IDs for tracking purposes.
• Fee Management: Collects arbitration fees from both parties. If only one party pays within the deadline, they automatically win.
• Evidence Submission: Allows both parties to submit evidence (IPFS links) throughout the dispute lifecycle.
• Kleros Integration: Creates disputes in the Kleros arbitrator once both parties have paid, implementing the ERC-792 arbitration standard.
• Appeal Handling: Manages multi-round appeals with asymmetric staking (winners stake 100%, losers stake 200%).
• Crowdfunding: Enables third parties to contribute funds to either side of an appeal in exchange for potential rewards.
• Ruling Execution: Distributes payments based on arbitrator decisions and handles fee reimbursements and rewards.

The ArbiterProxy uses a multi-owner pattern for access control and maintains separate event streams for Talent disputes and Gig disputes, allowing the frontend to track dispute states efficiently without complex on-chain queries.

All contracts implement comprehensive state management with enum-based states (e.g., WaitingForApproval, Ongoing, Finished, Cancelled, Disputed). State transitions are strictly enforced through require statements to prevent invalid operations. The contracts also include:

• Modifier-based access control to restrict function calls to authorized parties
• Input validation for string lengths, payment amounts, and addresses
• Event emission for all significant state changes to enable efficient indexing by Ponder
• Emergency cancellation functions restricted to the contract owner

For resolving conflicts that may arise between associated parties, smART integrates with Kleros, a decentralized arbitration protocol focused on dispute resolution within the blockchain economy. Community members act as arbitrators for disputes originating in different domains.

Kleros users stake tokens in specialized courts to increase their probability of being selected as jurors for disputes filed in those courts. When a dispute arises, jurors are provided with all pertinent information about the work, and both contract parties can submit additional evidence to support their arguments. A random group of jurors is selected to form a "jury", who vote based on the evidence provided. The system proportionally rewards jurors who voted with the majority and penalizes those who did not, creating a clear incentive for honest voting and careful analysis of the evidence.

The dispute resolution process in smART follows a structured flow to ensure fairness and transparency. Figure 2 illustrates how the dispute flow works from start to finish.

Figure 2. Dispute flow overview.

The main steps in the dispute resolution process are as follows:

The financing of arbitration is a crucial part of the process. For a dispute to be valid, both parties must deposit the corresponding arbitration fees into the smart contract. The fee deposit process works as follows:

• A dispute is created when one of the parties deposits a fee, then a 10-day deadline is set for the other party to deposit theirs.
• If only one party deposits the fee within the deadline, the contract automatically rules in favor of the party that paid, without creating an actual dispute in Kleros.
• If both parties deposit the required funds, the dispute is formally created in Kleros and the winning party will be reimbursed when the process concludes.

This mechanism ensures that only serious disputes proceed to arbitration, as both parties must demonstrate commitment by depositing fees.

Once the initial voting is completed, the involved parties have the opportunity to appeal the decision during a specified period. The appeal mechanism includes enhanced incentives:

1. Fee Deposits: Both parties must deposit arbitration fees again for the appeal round.
2. Asymmetric Staking: The staking requirements differ based on the current ruling:
   • The party winning the current ruling must stake 100% of the appeal cost (WINNER_STAKE_MULTIPLIER).
   • The party losing the current ruling must stake 200% of the appeal cost (LOSER_STAKE_MULTIPLIER).

This additional deposit serves as a guarantee. If the appeal proves unfounded and the party loses again, the extra amount is awarded to the winning party as compensation for time lost. Conversely, if the appeal is valid and the decision is reversed, the amount is returned to the appealing party. This system effectively disincentivizes malicious appeals.

If one party cannot meet the required fee (during the appeal phase), the platform provides the ability for other users within the application to contribute funds to help pay that fee. As an incentive:

• Contributors specify which side they support (freelancer or client).
• If the funded party wins the appeal, contributors recover their contribution plus a proportional share of the additional amount the losing appellant forfeited.
• If the funded party loses, contributors lose their contribution.

This aligns incentives for third parties to help finance cases they consider just and likely to win. The crowdfunding mechanism is implemented through the fundAppeal function in the ArbiterProxy contract, which tracks contributions by round and by contributor address.

Throughout the dispute lifecycle, both parties can submit evidence to support their case. Evidence is submitted as IPFS URIs pointing to JSON files containing:

• Descriptions of the work performed or issues encountered
• Links to deliverables, screenshots, or other relevant files
• Communications between the parties
• Any other supporting documentation

The platform automatically includes the last submitted deliverable as evidence when a dispute is created. Additional evidence can be submitted at any time before the dispute is ruled upon. The contract emits standard ERC-1497 Evidence events that Kleros jurors can access.

Once the dispute concludes and a final verdict is reached (whether in the first instance or after an appeal), the corresponding contract (HiredTalentsContract or GigsContract) acts accordingly:

• Ruling 1 (Freelancer wins): The agreed-upon funds are released to the freelancer, and the deliverable is marked as approved.
• Ruling 2 (Client wins): The funds held in escrow are returned to the client, and the deliverable is marked as rejected.
• Ruling 0 (Refused or tied): The payment is split evenly between freelancer and client.

The finalization process is triggered by calling the finalizeDispute function, which queries the current ruling from the ArbiterProxy, executes the ruling through Kleros if necessary, and distributes funds accordingly. All contributors to appeal crowdfunding also receive their reimbursements and rewards during this process.

At any point before a dispute is formally raised in Kleros (i.e., before both parties have paid), either party can dismiss the dispute. Dismissal results in:

• Full refund of any fees paid by either party
• The work contract returns to its previous state (typically Ongoing)
• The dispute can be re-launched later if issues persist

This mechanism allows parties to resolve misunderstandings or issues amicably without incurring arbitration costs. However, a party can only dismiss a dispute once before it is raised. If the dispute is re-launched dismissal is no longer possible and it must proceed to arbitration. This prevents abuse of the dismissal feature to avoid paying the arbitration fees, while still allowing for a chance to resolve minor conflicts without escalation.