Terms of Service for Web3 Marketing Projects

What do these terms cover?

These terms describe the working framework for services requested from MegaSatoshi; the written project scope defines the work for each engagement. Before work begins, that scope should identify the selected services, deliverables, timing, client inputs, approval points and fees. If a proposal or other written project document gives more specific details, use it to understand that engagement.

A service description on the website is a general explanation, not a substitute for confirming what a particular project includes. Ask for clarification if a requested item is missing or ambiguous. Do not assume a campaign includes extra formats, languages, platforms or revisions unless the scope says so.

For a practical overview of handoffs and approvals, read how we work. To discuss a proposed scope, send the project brief through contact. We can then identify open questions and document the work to be considered before you authorize it.

What should the client and MegaSatoshi prepare?

A project runs more clearly when each side knows what it owns. MegaSatoshi coordinates the agreed work, identifies requested inputs, shares materials for review where applicable and reports delivery in the format set out for the engagement. The client remains responsible for the accuracy and authorization of project information, claims, assets and instructions it supplies.

Use this kickoff checklist to prepare:

• Project name, official website, relevant token or product details, and target audience.
• The campaign objective, chosen platforms, requested deliverables and preferred timing.
• Approved brand assets, links, disclosures and any restrictions on wording or use.
• A primary decision-maker, an approval contact and a route for time-sensitive questions.
• Any applicable legal, geographic or platform requirements known to the project team.

Before work starts, confirm that supplied information is current and that you have permission to share the materials. If an input is not ready, flag it during planning rather than treating it as approved. The kickoff checklist gives both sides a clear basis for confirming scope and sequencing.

How are approvals and changes handled?

Approvals should be given by the contact identified for the project, using the channel agreed during kickoff. Review each draft or placement against the approved brief: check names, links, claims, visual assets, audience and requested call to action. Send consolidated, specific feedback so the team can distinguish a correction from a new request.

A request that changes the agreed platform, deliverable, timing or campaign direction should be reviewed before it is treated as part of the work. The parties can document the change and any resulting adjustment to fees or schedule in writing. This keeps the delivery record understandable and avoids relying on informal assumptions.

For work involving public-facing materials, provide final approval before publication or submission where approval is part of the agreed process. Keep a record of the approved version and the person who approved it. If you need to clarify how a particular engagement is recorded, ask before authorizing the next stage; the proposal should make the relevant checkpoints visible.

Where are fees and payment terms confirmed?

Fees, payment timing and any project-specific payment conditions are confirmed in the written proposal or other project documentation. Review those details before authorizing work, and ask for an updated written record if the scope changes. This page does not set a universal fee or payment schedule for every engagement.

Payment options listed for MegaSatoshi include USDT, USDC, BTC, ETH, SOL, TON and BNB. The proposal or invoice should identify the applicable amount, currency and payment instructions for your project; do not infer those details from a general service description. See payment methods for payment information, and consult pricing for service pricing context.

Keep the proposal, payment confirmation, approvals and delivery reports together with your project records. If a payment reference or project identifier is required, use the one supplied for that engagement. Raise any discrepancy with the project contact before the next work stage so it can be checked against the written scope.

How do platform rules affect Web3 marketing work?

Platform requirements are part of planning, but the platform retains control over its own review and display decisions. For example, CoinMarketCap or CoinGecko may assess listing submissions under their own processes, while visibility placements can be subject to platform availability and rotation; MegaSatoshi cannot promise acceptance, a particular ranking or a fixed display position. The agreed work is the delivery of the specified preparation, submission or placement activity, not control over the platform's decision.

Before approving campaign materials, check that project claims are supportable, destination links work and the content matches the platform and audience. Share known restrictions or prior review feedback early so they can inform the plan. Where an official platform rule is relevant, use the platform's own current guidance as the source of truth.

The project record should distinguish completed agency work from a third-party outcome. If a platform changes its requirements or a submission needs revision, discuss the practical next step with the project contact and record any scope change before additional work proceeds.

How should project information be shared?

Share only information needed to plan and deliver the agreed work, and identify material that should be treated as confidential when you provide it. Use the agreed project channel for briefs, approvals and account coordination. Do not send wallet seed phrases, private keys or other credentials that would give direct control of funds; a marketing engagement should not require them.

For personal information and its handling, read the privacy policy. For questions about service scope, payment records or a current project, use the contact page and refer to the relevant proposal or project identifier. If you are reviewing service assurances, consult guarantees and refunds for the applicable information rather than assuming terms that are not written into your project scope.

To begin, send MegaSatoshi your project brief, preferred platforms, target timing and the deliverables you want considered. We will review the inputs, flag open questions and return a written scope for your review before work is authorized.