DevSwap Whitepaper
The Decentralized Protocol for Software Services and the $DSWP Utility Token
Version: V2.1 — Institutional Whitepaper Draft
Target Network: BNB Smart Chain — BSC
Settlement Asset: USDT
Utility Token: $DSWP
Current Status: Testnet, with Mainnet gated by audit, multisig, timelock, and liquidity-lock requirements
Editorial Date: May 24, 2026
Informational and Regulatory Notice
This document is provided for technical and business explanation only. It does not constitute investment advice, an offer to sell securities, a promise of profit, or any guarantee regarding the future price, liquidity, market demand, or value of $DSWP. $DSWP is designed as a utility token within the DevSwap ecosystem. It is not the settlement asset used between clients and developers. Settlement inside the marketplace is conducted in USDT, while $DSWP is connected to a technical deflationary mechanism: buyback and burn, activated only when the project is operationally and legally ready. Any public launch, token activation, or Mainnet deployment should be preceded by specialized legal review, independent security audits, and production-grade governance controls, including multisig ownership, timelocks, incident procedures, and locked liquidity where applicable.
1. Executive Summary
DevSwap is a decentralized peer-to-peer marketplace for software services built on BNB Smart Chain. Its purpose is to rebuild trust in freelance software work by moving the core trust layer away from a centralized platform and into transparent smart contracts. Instead of asking users to rely only on a company that holds funds, controls reputation, and decides disputes, DevSwap gives clients and developers a system where funding, state transitions, settlement, and economic flows can be verified on-chain.
The platform addresses structural problems in traditional freelance marketplaces: high fees, delayed payouts, platform-owned reputation, centralized dispute handling, opaque payment policies, and pay-to-bid mechanics. In DevSwap, the client funds work in USDT, the smart contract holds the funds according to the agreed terms, the developer delivers against defined scope or milestones, and funds are released when delivery is approved or when contract-defined review windows expire.
The economic model is deliberately simple. On every successfully released milestone, the developer receives 97% of the released amount. A 1.5% platform fee supports protocol operations, and a separate 1.5% is allocated to buy back and burn $DSWP when the token mechanism is enabled. The total fee is therefore 3%, split transparently into 1.5% platform fee and 1.5% buyback-and-burn allocation.
$DSWP is the ecosystem’s utility and deflationary token. It is not used as the payment asset between clients and developers because software work requires settlement stability. DevSwap separates the two functions: USDT provides stable settlement, while $DSWP captures a portion of network activity through a buyback-and-burn mechanism linked to actual marketplace usage.
DevSwap adopts a hybrid marketplace model inspired by the strongest parts of Fiverr and Upwork, while avoiding their centralized weaknesses. In “Gig Mode,” a client can buy a clearly scoped software service, usually as a single milestone. In “Job Mode,” a client can post broader work, review proposals, and fund one or more milestones. Technically, both modes converge into the same on-chain primitive: a Job with one or more funded milestones. The difference is the user entry point, not the contract foundation.
2. The Market Problem
2.1 High and Opaque Fees
Traditional freelance platforms monetize centralized trust. They hold payment flows, mediate disputes, control reputation, and charge significant fees for this position. For developers, this often means reduced net earnings. For clients, it often means uncertainty about how much of the payment actually reaches the person doing the work.
DevSwap addresses this by making the fee model contract-aligned rather than policy-driven. Fees are not a vague pricing-page claim. They are enforced as fixed basis-point splits when funds are released. There is one transparent model: the developer keeps 97%, the platform fee is 1.5%, and the buyback-and-burn allocation is 1.5%.
2.2 Delayed Settlement
In many centralized marketplaces, the developer may still wait days after the client has approved the work. This creates unnecessary liquidity pressure and keeps developers dependent on platform payout schedules.
In DevSwap, release is settlement. When a client approves a milestone, or when an eligible auto-release condition is met, the developer’s net amount is transferred on-chain in the same transaction. There is no additional platform-controlled clearance period after release.
2.3 Platform-Locked Reputation
Reputation in traditional marketplaces is usually owned by the platform more than by the worker. A developer may build years of ratings, only to remain dependent on a proprietary ranking algorithm or a closed profile that cannot be independently verified elsewhere.
DevSwap treats reputation as verifiable data. Instead of relying on a hidden score or an opaque ranking system, the protocol emphasizes public, itemized counters such as jobs completed, milestones released, disputes, dispute outcomes, total earned, and total spent. The objective is not to manufacture trust through badges, but to expose evidence that users can inspect.
2.4 Centralized Dispute Handling
Software-work disputes are rarely reducible to code alone. A smart contract can know that funds were deposited, a delivery was submitted, and a deadline passed. It cannot independently judge whether the code met the agreed scope, whether the design matched the acceptance criteria, or whether a deliverable is production-ready.
DevSwap therefore does not pretend that code can replace all human judgment. Instead, it minimizes the need for disputes through better milestone structure and clearer acceptance criteria, then provides a rule-based arbitration path when human judgment is unavoidable.
2.5 Pay-to-Bid Mechanics
Some marketplaces charge freelancers to apply for work or require internal credits to bid. This turns access to opportunities into a toll on job seekers.
DevSwap takes the opposite position: no bid token, no Connects-style mechanism, and no fee merely to apply. Proposals can exist off-chain and become economically meaningful only when the client accepts and funds the agreed work on-chain.
Traditional Platforms
- ✗ 10% - 20% Opaque Fees
- ✗ Delayed Settlement (Days)
- ✗ Platform Owns Reputation
- ✗ Pay-to-Bid Mechanics
DevSwap Protocol
- ✓ Flat 3% Total Fee
- ✓ Instant On-Chain Settlement
- ✓ Verifiable Portable Reputation
- ✓ Zero Application Fees
3. The DevSwap Vision
DevSwap is not merely “Fiverr on blockchain” or “Upwork with wallets.” Its deeper purpose is to redefine the source of trust in software-services marketplaces.
In centralized marketplaces, trust comes from the company:
- The company says the funds exist.
- The company controls payout timing.
- The company displays reputation.
- The company decides how disputes are handled.
- The company controls access to demand.
In DevSwap, trust is redistributed across verifiable layers:
- The smart contract: holds funded work according to explicit rules and executes settlement.
- The public ledger: records funding, status transitions, releases, disputes, and token burns.
- The application interface: helps users understand and act, without becoming the authority that can unilaterally move funds outside contract rules.
Users should not have to trust a marketplace more. They should be able to verify more.
Trust Distribution Model
4. Product Definition
4.1 What Is DevSwap?
DevSwap is a peer-to-peer marketplace for software services where clients fund work in USDT and developers receive settlement when work is accepted or contract conditions are met. The platform is designed for software builders, not for every possible service category.
Target service areas include: Web development, Mobile applications, Web3 contracts and integrations, DevOps and infrastructure, AI and data projects, UX/UI design for software products, and Technical documentation.
4.2 Core Participants
| Participant | Role in DevSwap |
|---|---|
| Client | Defines work, funds USDT, reviews delivery, releases milestones, or raises disputes when needed. |
| Developer | Accepts work or submits proposals, delivers milestones, and receives 97% net settlement upon release. |
| Smart contract | Maintains the work state, holds funded amounts according to contract rules, executes settlement, and routes fee/buyback allocations. |
| Arbiter | Resolves eligible disputes according to registry and timing rules. |
| Keeper | Triggers permitted maintenance actions such as deferred buyback execution or eligible auto-release paths. |
| Interface | Helps users read and write to the protocol, but does not independently control user funds. |
4.3 Two Marketplace Modes: Gig and Job
Gig Mode: suitable for clearly scoped software services (one milestone, fast purchase).
Technically: createJob([amount], metadataHash)
Job Mode: suitable for open or multi-stage work (proposals, multiple milestones).
Technically: createJob([milestone1, milestone2, ...], metadataHash)
5. End-to-End Work Lifecycle
5.1 Discover or Define Work
A client can explore DevSwap without connecting a wallet immediately. This is a deliberate user-experience decision. Wallet connection is requested only when it becomes necessary: at funding or other contract actions.
5.2 Specify the Work
Detailed briefs and criteria are stored off-chain (IPFS). The smart contract stores milestone amounts and a metadataHash. This keeps financial data on-chain while allowing project descriptions to remain flexible.
5.3 Fund the Work
Before funding, the client sees total USDT, fee split, and net developer payout. Funding follows: 1) USDT approval, 2) createJob. All milestones are funded at creation in V2.1.
5.4 Accept the Work
A developer accepts the funded work. Proposals accepted off-chain are not active until funded on-chain.
5.5 Deliver and Review
The developer submits a delivery reference. The milestone awaits client review. If the review window expires under eligible conditions, auto-release may be triggered.
5.6 Release and Settlement
When released: 97% to developer, 1.5% platform fee, 1.5% $DSWP buyback/burn. Payout safety: Developer's 97% is not blocked by buyback liquidity or slippage.
5.7 Disputes
Eligible parties can raise disputes. Normal flow freezes until resolved by a registered arbiter. Arbiters must be registered before the dispute to prevent manipulation.
Fund
Client locks USDT
Deliver
Dev submits work
Release
Instant Settlement
6. Work and Milestone State Model
6.1 V1 Task Model
None → Open → Accepted → Submitted → Released
6.2 V2.1 Job and Milestone Model
Job: None → Open → Accepted → Completed
Milestone: None → Funded → Submitted → Released
6.3 Why Milestones Matter
Software projects naturalmente unfold in phases. A milestone model reduces risk for clients and improves cash-flow for developers.
7. Fee Model and Economics
7.1 The Fixed Split
| Component | Share | Description |
|---|---|---|
| Developer net | 97% | Paid to developer upon release. |
| Platform fee | 1.5% | Supports protocol operations. |
| Buyback and burn | 1.5% | Allocated to $DSWP deflation. |
7.2 Why 3%?
Low enough to be competitive, while supporting operational sustainability and token deflation mechanics.
The 100% Value Split
8. The `$DSWP` Utility Token
8.1 What Is $DSWP?
A utility token on BNB Smart Chain designed for deflation linked to marketplace activity. Not for settlement.
8.3 Why Settlement is in USDT
Software work requires settlement stability. USDT provides this, while $DSWP captures network value through usage-linked burns.
8.5 Supply and Allocation
Max Supply: 100,000,000 DSWP
9. Technical Architecture
DevSwap consists of coordinated layers: 1) Web Interface (Next.js), 2) Smart Contracts (BSC), 3) Indexed Data (Subgraph), 4) Off-Chain Data (Supabase/IPFS).
10. Security Model
Principles: Checks-Effects-Interactions, ReentrancyGuard, SafeERC20, Pausable, and Multisig ownership. Payment-Safety: Developer settlement must not be blocked by buyback failure.
11. Dispute Resolution
Smart contracts cannot judge work quality. DevSwap uses a minimized arbitration layer with registered arbiters subject to timelocks and eligibility rules.
12. Verifiable Reputation
Reputation is public, countable data (jobs posted, milestones released, disputes, earnings) recorded on-chain.
13. UX and Trust Design
Trust-first design lead by funding status and BscScan verification. Wallet connection only when necessary.
14. Operational Transparency
Relevant triggers: work accepted, delivery submitted, milestone released, buyback executed.
15. Market Focus
Focused on software: Web, Mobile, Web3, UX, AI, DevOps, Technical Content.
16. Roadmap
Phase 0: Testnet Validation
Verification of 3% split and payment safety mechanics on BSC Testnet.
Phase 1: MVP (USDT Only)
Practical experience focusing on software niches before token reliance.
Phase 4: Token Activation
Post-audit liquidity provision and buyback/burn enablement.
17. Success Metrics
North Star: time-to-first-funded-milestone. Supporting metrics include trust conversion and developer settlement time.
18. Technical Facts
| Item | Address (Testnet) |
|---|---|
| EscrowV2_1 | 0x67Eca35d3d23401d53Fba988759F8A649BA67c3e |
$DSWP |
0x2DD2Cd306f32cd6709d4316EF0df125235654734 |
19. Risks
Technical (vulnerabilities), Operational (key loss), Economic (weak demand), Regulatory (digital asset classification).
20. Why DevSwap Can Win
Low fees (3%), immediate settlement, verifiable reputation, no bid-token tax, and stable settlement via USDT.
21. Conclusion
DevSwap succeeds by removing fees, delay, opacity, and platform dependency from software work. It is a protocol for verifiable funding and labor settlement.
Appendix A — Quick Numerical Summary
Max Supply: 100M DSWP | Fee: 3% | Network: BSC | Settlement: USDT
Appendix B — Short Positioning Statement
DevSwap is a decentralized marketplace using USDT for work settlement and $DSWP for utility/deflation.