Frequently asked questions

What is the difference between a mandate and a budget?

Both are spending limits in XCR, and they bind different things at different moments. A budget (Agent SoW section 7.7) caps what a piece of work may cost. It lives on the engagement, and the agent's spend is metered against it as the work runs. A mandate ceiling caps what a person may commit. It lives on the person's authority, spans every engagement they approve, and is checked once, at approval time, before the commitment exists.

The two compose. An engagement's committed price, budget included, is what gets checked against the approver's per_engagement ceiling, so a purchasing manager with a 10M mandate cannot approve an engagement whose budget is 12M. After formation, the mandate has done its job and the budget governs the spend. Both are one idea applied to different subjects: a budget is the owner bounding the agent, and a mandate is the organization bounding the person.

How does a mandate get funded?

It does not. A mandate is permission, not money. It holds no balance, reserves no credits, and nothing about issuing one moves funds. Payment comes from a balance the mandate points at: the holder's own account by default, or the organization's balance when the mandate names the organization as payer.

The authority check and the funding check are independent, and both must pass for work to proceed. A person can hold a 50M XCR mandate against an empty balance: they may commit the organization, but the engagement cannot settle until the balance is funded. Authority comes from the charter; money comes from the balance.

Who pays for work approved under a mandate?

Whoever the mandate says. Its settlement.payer field names the payer: holder, the default, means the approving person's own account settles the engagement; organization means it settles from the organization's balance, and the mandate's ceilings bound that person's draw on it.

The organization payer is how a company actually wants to run: fund one treasury instead of topping up every employee's account, and let the mandates already on file say who may draw how much. One rule keeps it sound: a sub-mandate can name the organization as payer only if its issuer's mandate does, because nobody can grant a draw on a treasury they do not hold. And every settlement from the treasury leaves a draw record naming the engagement, the mandate, the holder, and the amount, so the organization can always answer where the money went and on whose authority.

How does a mandate relate to an agent's identity?

Three documents answer three different questions. The agent's own identity, its keys and its name on the mesh, says which agent is speaking. The charter says which organization is behind it. The mandate says which person may commit that organization.

Agents do not hold mandates; accounts and the people behind them do. The agent negotiates, drafts, and does the work under its own identity. Where the engagement's terms demand a person, the mandate holder approves with their own credential, and the approval record carries the mandate id. The agent acts; the person commits.

Does every engagement need a mandate?

No. Individuals never need one: an owner approving their own engagement is both the person and the authority, and there is no gap to close. Organizations need the check only where the engagement's terms demand person approval. Small work an agent takes on its own, under its owner's budgets and spending controls, is unchanged by this specification.

What happens when an employee leaves?

Their mandate is revoked by a signed act: one document, from the issuer or from root authority. The revocation takes effect the moment it is recorded, and it cascades to every mandate they issued below theirs. Engagements they validly formed before the revocation stand; revocation stops future acts, it does not unwind contracts. There is no membership list to edit, because membership is the set of accounts holding mandates in force, so the person drops out of the organization automatically.

Is the organization legally bound by what its keys sign?

That is a question for a court, and the specification says so plainly. The system proves one thing: the organization's own keys, on its own domain, signed the delegations its people act under, and a specific person with current, sufficient authority under those delegations approved a specific act. Whether the delegations themselves would hold up legally is graded recorded, always. A counterparty who needs legal certainty about a company has due diligence for that; what the protocol gives them is the signed chain.

Do I need a charter to work on the mesh?

No. Individuals are the common case, and nothing changes for them. A charter is for an organization that wants to be a verifiable principal: to have its offers, its accounts, and its approvals traceable to the entity rather than to a display string. If you are one person with one account, you already are your own authority.

Who should hold the root keys?

The allocators: the people entitled to commit the organization's money, a CFO, a managing partner, an owner. Root keys are check-signing power, not IT credentials. The person who runs the technical setup is the administrator, whose keys file and maintain the record but can never issue a mandate or approve anything. A setup should end with each root key in an allocator's hands, the day-to-day mandates issued, and the root keys put away.

What happens if the domain proof disappears?

The charter is suspended, not deleted. The registry re-checks the DNS record or well-known path over time, and anyone can re-check it at any moment. While suspended, the chain does not verify and approvals under it refuse. When the proof returns, the charter is restored, and everything issued under it stands as it was.

More questions belong here as they come up. The specification is the authority: the specification, and the worked example shows the whole lifecycle: worked example.