Platform service
Approved setup, recurring service and support fees. State what is included and any minimum term.
AMNAYA PLATFORM / COMMERCIAL GOVERNANCE
DRAFT v0.1 · NOT ADOPTED · NO PAYMENT COLLECTIONPay for the service.
Keep the evidence accountable.
A reusable pay-and-use model for Amnaya projects: know the provider, approve the price, measure the usage and preserve the audit trail.
No published tariff, subscription, tax calculation, invoice collection or fee-bearing smart contract is activated. Complete an approved project order before any paid use.
THREE DISTINCT COST LAYERS
One transparent price schedule.
Measured usage
Define billable records and overage rates. Count a unique approved finalization once, with source evidence for every charge.
External costs
Disclose actual network, RPC and storage costs, any markup, tax and currency conversion. Set spending caps before transactions.
Payment never buys a favorable review, provenance certification or removal of an adverse finding. Public chain data cannot be promised deleted when service ends.
PROJECT ORDER / BROWSER-ONLY DRAFT
Agree the service before use.
This worksheet illustrates a monthly base-plus-record plan. It is an optional pricing model, not an Amnaya tariff. All money fields are entered manually; taxes and network amounts are allowances, not calculated legal obligations or live quotes.
PROPOSED CLAUSES / VERSION 0.1
Rights, charges and remedies.
Adapt these clauses to the actual provider, project and territory. They are drafting guidelines, not an adopted contract or a declaration of compliance.
PU01
Parties, authority and scope
The project order shall identify the platform provider, project customer, authorized signatories, project IDs, covered workflows, permitted users and start date. Where both functions belong to the same legal entity, use an approved internal service and cost-allocation mandate rather than a fictitious agreement between separate parties. Group affiliation alone does not authorize another entity to incur fees or access evidence.
Practice: Name the paying entity and budget owner for each of the eight projects. Record actual authority before activation.
PU02
Transparent fee schedule
No paid service shall start until the parties approve a schedule stating currency, setup fees, recurring platform fees, included usage, overage rates, storage/retrieval charges, support, third-party costs, applicable tax treatment and any minimum commitment. State all mandatory charges together and identify genuinely variable charges and their calculation. No fee is approved by this draft.
Practice: Present a complete order summary before acceptance; do not hide network costs or monitoring renewals in footnotes.
PU03
Usage meter and evidence
For a per-record plan, the proposed billable unit is one unique record when it is first finalized as approved, including a separately approved correction record. Proposals, reviews, rejected or unfinalized records, duplicate retries and status checks are not separately metered under that plan. Any other meter requires an explicit order amendment. Disputed or revoked records are flagged for review under the agreed credit policy; do not silently rewrite historical usage.
Practice: Use chain ID, registry address and record ID for idempotent metering; link each charge to its first finalization transaction and billing period. Reconcile reorgs before final billing.
PU04
Spend caps and overages
The order shall set a monthly total spend cap and any per-transaction network cap, with alert thresholds and an authorized overage approver. Warn before reaching the cap. Queue new optional writes at the cap instead of incurring unauthorized costs. Preserve approved safety, dispute and evidence-access procedures; document any funded emergency exception separately.
Practice: Require recorded approval for an increase. A budget estimate or pending transaction is not permission to exceed a cap.
PU05
Ethereum and third-party charges
Distinguish platform revenue from actual network, RPC, storage and other third-party charges. Identify who pays gas, which chain is used, the approval limit, any markup and any conversion method/time. Gas for a mined failed or reverted transaction may still be consumed. Evidence the actual transaction cost; an unsigned, rejected-before-broadcast or never-included transaction is not automatically a paid network event. No wallet custody, token transfer or unlimited spending approval is authorized by these terms.
Practice: Estimate before signing; prevent blind retries; reimburse provider-caused avoidable failed-write costs under the agreed incident/credit procedure. Settlement speed and L2 costs must be measured rather than promised.
PU06
Invoices, payment and tax
Invoices shall identify provider/customer entities, period, order version, quantities, unit rates, credits, taxes and payment instructions. Due dates and payment methods require agreement. Pay undisputed amounts on time; segregate a genuinely disputed amount without automatically disabling access to evidence. Taxes, withholding, exchange rates and intercompany allocation require review for the actual jurisdictions. No default interest or late-payment penalty applies unless expressly agreed and lawful.
Practice: Use invoice IDs and reconciliation reports. No payment processor, tax calculation or bank collection is implemented by this model.
PU07
Credits, failures and refunds
Define credits for duplicate billing, incorrect meter counts, undelivered prepaid services and provider-attributable failures in the order. Separate platform credits from consumed third-party gas. Investigate failed transactions and allocate costs according to responsibility and the agreed policy; do not make every fee nonrefundable by default. Unused prepaid balances and exit refunds shall follow the signed schedule and applicable law.
Practice: Record issue, cause, affected records/transactions, calculation, approver and credit-note reference. Do not double-charge a retry.
PU08
Billing queries and escalation
Provide a billing contact, invoice-query window, response timetable and escalation route. Acknowledge and investigate with itemized usage and cost evidence. A query window is an administrative target, not an automatic waiver of mandatory rights or latent billing errors. Do not treat a billing dispute as a reason to suppress provenance disputes, audit findings or complaints.
Practice: The configurator offers draft day counts only. Agree actual contacts, business-day definitions and escalation authority before adoption.
PU09
Permitted use and prohibited conduct
Grant a nonexclusive, project-scoped right to use agreed services during the approved term. Users shall act within permissions and provide information they are authorized to supply. Prohibit fabricated provenance, self-approval, impersonation, unauthorized cross-project access, credential sharing, malicious code, unlawful content and claims that a blockchain entry alone certifies truth, safety, title or regulatory compliance. Third-party access or resale requires written authorization.
Practice: Review participants and conflicts. Price or payment must never purchase a favorable review or remove an adverse finding.
PU10
Data, confidentiality and intellectual property
The project retains its rights in its submitted data and grants only the permissions necessary to deliver agreed services. Identify controller/processor or equivalent roles, hosting locations, subprocessors, confidentiality and lawful disclosures in a separate schedule. Keep personal, medical, sensitive location and commercial documents off public chains. Public identifiers, commitments and metadata may remain visible and linkable. Platform pre-existing IP and any project-funded deliverables require explicit ownership/licence terms.
Practice: No AI training, onward sale or cross-project reuse of project data without a separate valid authorization. Define encryption, access logs, retention, deletion and backup treatment.
PU11
AI, reviewers and credentials
AI may assist extraction, completeness checks, anomaly detection and drafting within approved data permissions. Human reviewers retain final approval and dispute decisions. Identify accountable operators, reviewers and resolver roles; payment does not replace independence. Keys and credentials shall remain under approved custody with least privilege, rotation and incident procedures.
Practice: Record model/version, sources, recommendations and human disposition. Never place signer secrets in an AI prompt or public webpage.
PU12
Service levels and dependencies
Specify measurable availability, support hours, incident response, backup/recovery objectives, verification latency and remedies in the service schedule. Separate platform performance from blockchain inclusion/finality, sequencer/RPC outages and source-evidence delays. No fixed uptime, gas price, finality time or regulatory result is promised by this draft.
Practice: Define measurement points and exclusions narrowly. Test recovery; use confirmed/finalized status rather than presenting queued records as anchored.
PU13
Change control and renewal
Material fee, service, network, policy and data-use changes require versioned notice and approval by authorized parties before effect, with a fair exit option. No retroactive rate changes or automatic subscription renewal is authorized by this draft. Any renewal, minimum term or notice period must appear in the accepted order.
Practice: Preserve the order version, effective date and acceptance evidence. Do not infer agreement from a document download or demonstration click.
PU14
Suspension and incident response
For ordinary nonpayment, give notice, a reasonable agreed cure period and proportionate limits on new optional services. Preserve secure read/export access to customer evidence through the agreed exit period, subject to lawful/security restrictions; do not erase or hold evidence hostage to an invoice dispute. Immediate suspension may be necessary for credible security or legal risks; record reasons, scope, communication and reinstatement conditions.
Practice: Separate financial suspension from integrity flags. Pausing a contract cannot erase its history; coordinate remaining gas-funded emergency actions.
PU15
Termination, portability and retention
Agree termination rights, notice, paid transition assistance, refund treatment and an export period. Supply agreed machine-readable records, documents, salts/verification instructions where authorized, transaction references and audit history. Delete or retain private copies under the approved schedule and legal obligations; public-chain history cannot be promised erased. State backup expiry and any remaining read-only verification arrangements.
Practice: Rehearse export and participant exit. Define who funds ongoing public verification, private storage and recovery after service end.
PU16
Responsibility, liability and dispute forum
Allocate responsibility for platform operations, evidence quality, independent review, third-party dependencies and customer actions in the accepted agreement. Negotiate any liability cap, exclusions, insurance and indemnities for the actual risk; do not insert a blanket waiver here. Preserve obligations that cannot lawfully be excluded. Identify governing law, dispute forum and escalation/mediation arrangements after territorial review.
Practice: The order export leaves liability, service levels, governing law and forum unset. Counsel reviews the actual India/U.S. or other cross-border arrangement.
PU17
Internal allocation and independent oversight
Allocate shared platform costs to projects using documented drivers such as authorized seats, finalized records, storage and support effort. Distinguish cost recovery from profit markup and avoid double recovery of included costs. Any related-party pricing, transfer-pricing or tax treatment requires appropriate review. Independent reviewers and grievance channels shall not depend on a positive commercial outcome.
Practice: Publish an internal allocation report to project budget owners; disclose connected-party interests and assess affordability for small producers.
PU18
Acceptance and operational activation
These guidelines are a draft template. They become operative only through proper adoption and a completed project order/service agreement accepted by authorized parties. The agreement shall establish precedence among the order, service levels, data/security schedule and use terms, while preserving mandatory law. No clickwrap, checkout, automatic debit or fee-bearing smart contract is created by this page.
Practice: Activation checklist: approved provider/customer identities; scope; price/meter/taxes; spend caps; data/security; service levels; remedies/exit; legal review; actual signatures and effective date. Retain acceptance evidence before enabling billing.
ACTIVATION GATE
No bill without a mandate.
- Identify the actual provider, payer and authorized signatories.
- Approve scope, rates, meters, external costs, taxes and spend caps.
- Approve data/security, reviewer independence and service levels.
- Agree credits, disputes, suspension, export and retention.
- Review territorial requirements, liability and contract precedence.
- Record actual acceptance and effective date before enabling paid use.
The current framework demonstrates controls and exports drafts. Billing enforcement, metering/indexing, payment processing and legally effective acceptance require separate implementation.
Drafting and technical references
UNCITRAL Notes on the Main Issues of Cloud Computing Contracts · Ethereum gas and fees · FTC Advertising FAQs