Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mavrodi.org/llms.txt

Use this file to discover all available pages before exploring further.

An Order is the core transaction unit in InviteBot. It connects one participant’s Intent (their offer to give help) with another participant’s Help Request (their request to receive help), and it directs the sender to transfer a specific amount to the recipient. As a Guider, you are involved at the critical decision points: you review new Orders before they reach your participant, you can reject problematic ones, and you oversee resolution when something goes wrong.
The system creates most Orders automatically through scheduled matching jobs that pair compatible Intents and Help Requests. You can also create Orders manually when needed. Either way, the same lifecycle applies.

​
Full lifecycle overview

Orders move through a defined sequence of statuses. Each status has specific people who can take action, and actions drive the transitions. 
DRAFT → NEW → ACCEPTED → PAID → RECEIVED
                              ↘ DISPUTE → RECEIVED
                                        ↘ CANCELED
         ↓          ↓
      REJECTED   REFUSED
DRAFT → CANCELED

​
Order statuses

​
DRAFT

The Order has been created but not yet activated. This happens when a Guider creates an Order manually with /order_add. Who can act: The Guider who created the Order. Available actions:
  • Move to NEW (activate the Order and send it into the review queue)
  • Cancel (→ CANCELED, terminates the Order)
At this stage, the Order is not visible to the participant. Use it to verify the details before activating.

​
NEW

The Order is active and waiting for the Intent holder’s Guider to review it and send it to their participant. Who can act: The Intent holder’s Guider. Available actions:
  • Accept and send to participant (→ ACCEPTED)
  • Reject (→ REJECTED)
This is the most important decision point in the lifecycle. You are verifying that the Order is appropriate for your participant before committing them to a transfer.

​
ACCEPTED

The Order has been sent to the participant (the sender). The participant now sees the recipient’s payment details and is expected to make the transfer. Who can act: The participant (sender); the Guider. Available actions:
ActorActionResult
ParticipantConfirm payment sent→ PAID
ParticipantRefuse to complete→ REFUSED
GuiderReject→ REJECTED
GuiderWithdraw (recall)→ REFUSED
Which payment details the participant sees depends on whether the Help Request is a system request and whether the participant is verified. Unverified participants are shown special verification payment details for their first transfer. Once verified, they see the standard or system payment details appropriate for the request type.
The participant has confirmed they sent the transfer. The recipient now needs to confirm that they received it. Who can act: The recipient; administrators. Available actions:
ActorActionResult
RecipientConfirm receipt→ RECEIVED
RecipientReport non-receipt→ DISPUTE
AdminConfirm receipt on participant’s behalf→ RECEIVED
AdminCancel Order→ REFUSED (also cancels the linked Intent and other open Orders on that Intent)

​
RECEIVED

The recipient confirmed that funds arrived. This is a successful terminal status. Who can act: No further actions required. What happens: Balances update in the linked Intents and Help Requests, notifications go to all parties, and any applicable MAVRO rewards are processed.

​
REFUSED

The participant declined to complete the Order, or the Guider recalled it. This is a terminal status. Common reasons:
  • Participant cannot complete the transfer in time
  • Technical issues with the payment method
  • Incorrect payment details
  • Personal circumstances
What happens: The system searches for a replacement participant for the same Help Request. The Order amount returns to the matching pool.

​
REJECTED

The Guider rejected the Order. This is a terminal status. Common reasons:
  • Participant has insufficient funds
  • Participant is unwilling to transfer
  • The Intent is already fully confirmed
  • Participant is unreachable or has blocked the bot
  • Help has not yet been received (waiting on prior receipts)

​
CANCELED

The Order was canceled. This typically happens from DRAFT status, or by an administrator intervening in an active Order.

​
DISPUTE

The recipient reported that they did not receive the transfer, despite the sender having confirmed payment. This status requires investigation. Who can act: Administrators; Guiders can assist with evidence gathering. Available actions (admin only):
ActionResult
Confirm receipt on recipient’s behalf→ RECEIVED
Cancel Order→ REFUSED (also cancels linked Intent and open Orders on that Intent)

​
Status and action matrix

StatusOrder creator (Guider)Intent GuiderParticipant (sender)RecipientAdmin
DRAFTMove to NEW, Cancel———Any
NEW—Accept/Send, Reject——Any
ACCEPTED—Reject, WithdrawConfirm paid, Refuse—Any
PAID———Confirm received, Open disputeConfirm received, Cancel
DISPUTE————Confirm received, Cancel
RECEIVED————Any
REFUSED————Any
REJECTED————Any
CANCELED————Any

​
Creating an Order manually

If you need to create an Order outside of the automatic matching process — for example, to pair a specific Intent with a specific Help Request — use the /order_add command: 
/order_add_A123_G456_1000
Where:
  • A123 is the Help Request (Ask) ID
  • G456 is the Intent ID
  • 1000 is the amount
The Order is created in DRAFT status. Review it, then activate it by moving it to NEW.
Manual Orders bypass the automatic matching logic. Verify that the Help Request and Intent are compatible (same currency, appropriate amounts) before activating. Incorrect manual Orders cause confusion for both participants.
You can view Orders created by or involving the system with: 
/system_orders

​
Handling disputes

When an Order enters DISPUTE status, your role is to gather evidence and escalate to an administrator.
1

Contact the sender

Reach out to the participant who confirmed payment. Ask for a screenshot or transaction record showing the transfer.
2

Check the payment details

Verify that the sender used the correct card number, phone, or wallet address. Mistakes here are common.
3

Contact the recipient

Ask the recipient to double-check their accounts. Transfers can be delayed by banks.
4

Escalate to admin

If the evidence is clear or the situation cannot be resolved at your level, use /admin to reach an administrator. Share the Order ID and any screenshots you have collected.
You cannot resolve a DISPUTE yourself — only administrators can make the final call to mark it as RECEIVED or cancel it. Your job is to investigate and present the facts.

​
Automatic Order creation

The system automatically matches open Intents with pending Help Requests and creates Orders on a regular schedule. This happens without manual intervention when:
  • A valid active Intent exists in the matching pool
  • A Help Request that you have approved is waiting
  • The amounts and currencies are compatible
When an automatic Order is created involving someone in your structure, you receive a notification and the Order arrives in your review queue at NEW status.