NEAR introduced NEAR Business on October 20, 2026 as a confidential multisig treasury, initially available by invitation. The useful question for a team is not simply how many people approve a transfer. Decide separately who may approve it, who can read its underlying details, and who can produce the record needed to explain it later.
A launch announcement is the start of the review
The official introduction describes team-defined approval rules and exportable records. It says governance information is onchain while confidential payment details have a different visibility model. These are the product’s stated capabilities, rather than the result of our own funded-account test.
For a finance team, putting approvals and records in one interface can make a workflow easier to follow. It also makes a permissions review more valuable: the person who checks a supplier’s invoice may not be the person who releases funds or prepares the accounting export. A product label alone does not establish that your organization’s division of responsibilities has been implemented.
Write the permission matrix before choosing the threshold
Use the following worksheet during a walkthrough. It is an assessment checklist, not a claim that NEAR Business exposes every permission as an independent switch. Ask the provider to demonstrate the actual controls and record any responsibilities that must remain outside the application.
| Responsibility | Question to demonstrate | Evidence your team keeps |
|---|---|---|
| Prepare a payment | Who checks the recipient against the underlying obligation? | The approved invoice or other payment basis |
| Approve spending | Which people and rule authorize this exact instruction? | The instruction version and required approvals |
| Read sensitive details | Who can view the amount, recipient and notes? | The access decision and its business reason |
| Reconcile the result | Who obtains the record and compares it with delivery? | The receipt, outcome and unresolved differences |
Consider an illustrative two-of-three approval rule. Two approvals answer a spending-authority question only if the signers understand the same instruction. They do not, by themselves, answer whether an accountant can retrieve the supporting record or whether a former employee still has workspace access. Keep those questions in separate rows rather than treating the threshold as a complete security policy.
Confidential records still have readers
The NEAR Business privacy policy, updated October 8, describes cached confidential transaction records and operator access for service, security and legal purposes. It also warns that text entered into public onchain fields remains public. Therefore, assess who can see each class of information; do not interpret confidentiality as a promise that nobody can access payment details.
An internal reference such as an invoice code is often easier to manage than a long narrative containing someone’s personal information. First determine whether the field is public or confidential, then choose what belongs there. A private document link and an onchain proposal description should not be treated as interchangeable containers just because they appear in one workflow.
- List the people who prepare, approve, review and reconcile payments, including anyone covering an absence.
- Ask for a demonstration of the approval rule and the information each role can read.
- Use a fictional payment to check that everyone reviews the same recipient, asset, network and amount.
- Agree how a changed instruction will receive fresh approval; do not rely on an earlier screenshot.
- Plan how records and access will be handled when a team member leaves or a signer is unavailable.
Separate approval from the completed payment
A useful handover tells the next reviewer what was requested, what was approved and what result was observed. In a hypothetical vendor payment, the invoice might name the correct company while the pasted address belongs to a different recipient. The discrepancy belongs in the review before approval. Counting signatures afterward would not resolve the mistaken payment instruction.
Before a separate exchange, compare the intended asset and network with supported coins, read the order workflow, and use the simple-swap form to review that order’s details. This is not a claim of integration between NEAR Business and KOT.CASH. A treasury approval and an exchange order are separate records, and each should be understandable on its own.
FAQ
What does multisig mean in a NEAR Business treasury review?
Review the rule that authorizes a particular spending instruction. Review access to the underlying payment details separately, rather than assuming the approval threshold settles every permission question.
What is an example of a multisig approval check?
In an illustrative two-of-three process, ask whether two reviewers are approving the same recipient and amount. The example describes a review method, not the configuration of an existing customer.
What should a team check during multisig wallet setup?
List who prepares, approves and reconciles payments, and ask for a demonstration of the actual controls. Agree how records and access will be handled if a signer leaves.