Help Center & FAQ

Grumbuild is a decentralized freelance marketplace built on BNB Smart Chain (BSC), designed to bring trust and transparency to professional collaboration. It connects clients and freelancers through a structured workflow backed by on-chain escrow — meaning payments are governed by smart contracts, not held by a third party.

On Grumbuild, you can:

• Post jobs with defined milestones and hire verified freelancers (as a client)
• Create service gigs, apply to open jobs, and deliver work with on-chain proof via IPFS (as a freelancer)
• Negotiate terms, agree on milestone requirements, and formalize agreements through structured reference documents
• Fund and release payments securely through individual escrow contracts — one per milestone — deployed directly on BSC
• Earn GRMPS token rewards upon successful, dispute-free project completion

Every payment on Grumbuild is protected by a dedicated smart contract. Funds are only released when both parties fulfill their obligations, making the process fair, verifiable, and fully transparent on-chain.

Instead of holding money in a company bank account, Grumbuild uses smart contracts. That means:

• ✅ Funds move directly between wallets
• ✅ Escrow rules are enforced by code
• ✅ The platform never "touches" your money
• ✅ Everything is transparent and verifiable on-chain

In simple terms: the backend helps prepare transactions, but your wallet always stays in control.

1. Visit Grumbuild.com and click Sign Up
2. Enter your email + password
3. Add your basic profile details
4. Confirm your email (if prompted)
5. (Recommended) Connect your crypto wallet so we can link it to your account

1. Click Log In
2. Enter your email + password
3. Once you're in, connect your wallet (if it's not already connected)
4. You'll be taken to your dashboard where you can view your jobs, gigs, applications, milestones, notifications, and chats

Open Profile / Account Settings and update things like display name, bio and skills, location, and profile photo. Your updated profile will show everywhere - job posts, gig listings, chat messages, and proposals.

Because Grumbuild uses blockchain escrow, your wallet becomes your identity for payments. Your wallet address is used as your client wallet (to fund escrow milestones) or freelancer wallet (to receive payouts).

When you do important actions like funding escrow or withdrawing money:

1. The backend prepares the transaction data
2. Your wallet (MetaMask, etc.) asks for approval
3. You sign it
4. It goes on-chain

• ✅ You stay in control
• ✅ The platform never holds your funds
• ✅ Escrow rules apply automatically

1. Go to your dashboard → click Create Job
2. Fill out title, description, budget range (in BNB), deadline, tags/category, and optional cover image
3. Submit

Your job is saved, you receive a JOB_POSTED notification, and your job appears publicly so freelancers can apply.

1. Go to Create Gig
2. Add title, what you do, tags, budget range (BNB), and optional images
3. Save

Once posted, clients can discover you in gig search, message you, and propose work. A gig can turn into a job + milestones + escrow anytime.

1. Open a job listing
2. Click Apply / Bid
3. Submit your proposal/cover letter, your price (BNB), and estimated timeline

After you apply, you get a BID_SENT notification, the client gets BID_RECEIVED, and you can chat and finalize agreement details.

Think of these as your project agreement - but structured and easy to reference. They typically include what you're building/delivering, what is not included, timeline and key milestones, budget expectations, and acceptance criteria (how the client approves work). This helps prevent misunderstandings and protects both sides.

Either side can propose a document, edit it, and request changes. Once it's ready, both sides confirm the final version.

• ✅ The system tracks confirmation rounds
• ✅ Notifications are triggered for creation and confirmation
• ✅ The confirmed document becomes the "source of truth" for milestones and disputes

Each milestone gets its own dedicated escrow contract - the "vault" for that milestone's payment. When a milestone is ready to be funded:

1. Backend loads platform settings (fee recipient, arbiter, fee bps)
2. Reads milestone info (client wallet, freelancer wallet, amount, due date)
3. Calls EscrowFactory.createEscrow()
4. Factory deploys a gas-efficient clone (minimal proxy)
5. Escrow address is stored + linked to the milestone

1. Created - you agree on it in the job/requirements
2. Escrow deployed - contract is created for that milestone
3. Funded - client funds escrow on-chain
4. Delivered - freelancer submits work + CID
5. Approved - client approves the exact delivered CID
6. Withdrawn - freelancer withdraws payout from escrow
7. Completed - milestone marked complete

1. Client clicks Fund Escrow
2. Backend prepares transaction (to = escrowAddress, data = Escrow.fund(), value = projectAmount + buyerFee)
3. Client's wallet signs and sends on BSC
4. Contract marks milestone as funded + holds funds safely
5. Backend updates milestone status + sends MILESTONE_FUNDED notification

Fees are enforced by smart contracts and stored in basis points (bps). For example, 100 bps = 1% total fee, often split like 0.5% buyer fee and 0.5% freelancer fee.

On payout, the freelancer receives the project amount minus vendor fee, and the platform receives buyer fee + vendor fee.

"Grumbuild charges about 1% total, split between client and freelancer, and the escrow contract automatically routes it during payout."

When the freelancer clicks Deliver Work, they can either upload a file (up to 100MB) or paste an existing IPFS CID. If they upload:

1. Backend uploads to Pinata (IPFS)
2. Receives CID + calculates a content hash
3. Builds transaction: Escrow.deliver(cid, contentHash)
4. Freelancer signs it in their wallet

The escrow contract stores the CID and marks the milestone as Delivered.

1. Client reviews the delivered CID/files
2. Clicks Approve Work
3. Backend prepares approve(cid) transaction
4. CID must match exactly what was delivered
5. Escrow moves into Releasable state and emits an on-chain event

1. Click Withdraw
2. Backend prepares withdraw() transaction
3. Freelancer signs on-chain
4. Contract pays: platform fee recipient, freelancer payout amount, and optional reward distribution (GRMPS) if enabled

Every escrow contract on Grumbuild is tied to specific wallet addresses - one for the client and one for the freelancer. These addresses are permanently written into the contract at the time of creation and cannot be changed afterwards. This means:

• As a client, the wallet you use to fund the escrow must be the same wallet that was registered on your Grumbuild account when the milestone was created. If you try to fund from a different wallet, the smart contract will reject the transaction because the sender address won't match the authorized buyer address.
• As a freelancer, the wallet linked to your account is the one that will receive the payout when you withdraw. If you switch wallets or connect a different address, you won't be able to call the deliver or withdraw functions - the contract only recognizes the original vendor address.
• Grumbuild also performs a wallet verification check before allowing sensitive actions. When you connect your wallet, the platform compares it against the address saved on your profile. If there's a mismatch, you'll be blocked from performing on-chain operations like funding, delivering, approving, or withdrawing.

In short: always connect the same wallet you used when you signed up or when the milestone was created. Switching wallets mid-project can lock you out of your own escrow, and there is no way to reassign wallet addresses on an existing contract. If you need to change your wallet, make sure to do it before any new milestones are created - and keep in mind that existing milestones will still be bound to the original address.

Disputes can arise at different stages of the delivery process, and understanding how they interact with the escrow lifecycle is important for protecting yourself:

• A client can initiate a dispute while the escrow is in the Funded or Delivered state. This is typically done when the client believes the work is incomplete, doesn't meet the agreed requirements, or hasn't been delivered at all despite the deadline passing.
• A freelancer can initiate a dispute while the escrow is in the Delivered state. This usually happens when the client is unresponsive, refuses to approve completed work without valid reason, or is deliberately stalling to avoid payment.
• Once a dispute is started, the escrow enters a locked state - neither party can approve, withdraw, or make further deliveries until the dispute is resolved. This protects both sides from any unilateral actions while the disagreement is being handled.
• The party that initiates the dispute must pay a dispute fee upfront. However, when the client initiates or responds to a dispute, their fee is automatically deducted from the funds already held in escrow — so the client does not need to make a separate payment. The freelancer, on the other hand, pays their dispute fee directly from their wallet. The other party then has a limited window to respond: 72 hours if the freelancer initiated, or 48 hours if the client initiated. If the responding party fails to pay their dispute fee within this window, the initiator can call a default resolution and automatically win the dispute.
• If both parties pay their dispute fees, an independent arbiter reviews the case and makes a binding decision. The arbiter can resolve in favor of either the client (funds returned) or the freelancer (funds released). The losing party's dispute fee is split between the arbiter and the platform fee recipient as compensation for the resolution service.
• To minimize the risk of disputes, both parties should use the requirement documents feature to clearly define deliverables, acceptance criteria, and timelines before work begins. A well-documented agreement serves as the "source of truth" and makes arbiter decisions faster and more predictable.

The dispute system is designed to be fair but also to discourage frivolous claims - the fee structure ensures that both parties have skin in the game, and the deadline mechanism prevents anyone from stalling indefinitely.

A dispute is a protected way to resolve disagreements - like when a client feels work is incomplete, a freelancer feels the client is delaying unfairly, or either side wants a neutral resolution. Disputes are handled on-chain using an arbiter address, a dispute fee, and deadlines (so nobody can stall forever).

Step 1: Start dispute

Client can start while Funded or Delivered. Freelancer can start while Delivered. The initiator pays a dispute fee. Deadlines apply: if freelancer starts → client has 72 hours to respond; if client starts → freelancer has 48 hours to pay fee and respond.

Step 2: If the other side doesn't pay in time

Initiator can call resolveDisputeByDefault() and wins by default.

Step 3: If both pay

Arbiter decides: resolveToVendor() (freelancer wins) or resolveToBuyer() (client wins). The losing dispute fee gets split between the arbiter + platform fee recipient.

This structure discourages fake disputes and encourages fast resolution.

Grumbuild keeps you updated in real time with a notification center. You'll see alerts for job and gig activity, bids sent/received, requirement docs created/confirmed, milestone funded/delivered/approved/withdrawn, dispute started/resolved, and chat messages and conversation updates. Real-time delivery uses WebSockets and private user channels.

If email is configured, important actions can also trigger emails (welcome, milestone updates, bid updates, etc.). Email failures won't break anything - you'll still get in-app notifications.

Chat is built to keep everything connected to the actual work. Conversations can exist for jobs, gigs, and applications. Messages are saved and tied to context. Attachments can be uploaded via the platform upload API. Notifications fire on message receipt and conversation updates. Your chats aren't floating randomly - they always relate to a job, bid, or milestone.

General uploads (avatars, gig images, job cover images):

Image-only MIME types, limited by platform constants.

Work delivery uploads (milestone delivery):

Up to 100MB per file. Supports common formats (PDF, docs, images, video, audio, etc.).

Grumbuild is built for BNB Smart Chain (BSC). The default dev config uses BSC Testnet (CHAIN_ID = 97). It's designed to move to mainnet by switching RPC + chainId configs.

Right now, Grumbuild uses BNB only - budgets, milestones, fees, and payouts are all in BNB. The system is designed so tokens like USDT/USDC (BEP-20) can be added later.

Fees are controlled in two places: smart contract parameters (buyerFeeBps, vendorFeeBps) and backend system settings (mirrors these configs). They are enforced automatically at payout.

Projects that do not have disputes are entitled to the rewards under the following considerations:

• The distributor having token balance
• Proper allowances being set

Use the Support / Contact page inside the app to send a message to the team. Your request is stored and forwarded to the configured support inbox, and we'll reply with next steps. Typical reasons include login or account issues, job/gig/milestone questions, escrow or dispute questions, and upload problems.