Terms

Last updated: 2026-10-21.

Parties

You are a reader of this site, or the person who sends an early-access request. If you send a request for a company, name that company on the form. The request still does not create a customer contract.

The steward named in the governance of A-REX Core is the A-REX Foundation. That is the name under which the original authors publish the specification. The governance states that the Foundation is not yet a registered legal entity. Until it is, it acts through its founding maintainers. It has no members, no budget, and no legal personality.

The published contact is seanluis47@gmail.com. That address is the contact published for the standard. It is not a corporate office.

These pages state no corporate address, no registered office, no data-protection officer, and no governing law.

What these pages are

This site, a-rex.pages.dev, explains A-REX Core and a documented platform design.

These pages are a lookup text. They state who publishes the site, which licence covers which work, what early access covers, what stays confidential, what you must not say about the token, how to report a vulnerability in the specification, and how a change to these pages is marked.

These pages are not a customer contract. This site has no tenant agreement, no participant agreement, no data-processing agreement, and no custody disclosure. The legal research lists those documents as still required. Where that research marks a point as an inference, this page says so. An inference is not a contract, and it is not a decision by a regulator.

Questions about personal data on this site are answered in the privacy policy, and only to the extent that policy already states them. That policy covers the documentation site. It is not a privacy policy for a hosted tenant.

Three different things

Keep these three apart.

The standard. A-REX Core is the normative specification: the text, the interfaces, the metadata schema, and the copy prepared for an Ethereum Request for Comments (ERC). The text this site describes is draft 2.1.0-alpha.2. It is not yet an ERC. The governance of the standard is separate from any product. A documentation site and a commercial product can change without changing the standard.

The reference implementation. arex-contracts is one implementation of the standard. It has its own maintainers. It can change without changing the standard. Its licence is MIT. The specification text is not that code.

The documented platform. The platform documents describe a hosted product built on A-REX Core. They describe controls, proposals, and human approval. They are a technology description. They are not an offer, a service agreement, or a contract to operate a tenant. This site states no prices. The design documents publish no price list. Nothing on this site makes the Foundation a nonprofit, names a production customer, or reports a completed audit.

The founders of the steward also build commercial products on A-REX. The governance states that conflict. Those products receive no early access to undisclosed specification changes, no exclusive conformance status, and no say beyond that of any other implementer.

Licence

The specification is CC0-1.0. A contribution to the specification repository is dedicated to the public domain under CC0-1.0. The contributor confirms the right to make that dedication. No contributor licence agreement is required. No patent pledge beyond CC0 is required. A contributor discloses any patent they know of that reads on a proposal.

The reference implementation is MIT.

The explanatory pages on this site are not the specification and not the reference implementation. Reading them grants no licence to an unpublished repository.

The words "A-REX Core conformant" follow the implementer criteria named in the governance. There is no paid listing, no membership fee, and no certification fee. This site does not sell a certification.

The token

The legal research says a future contract, and the token metadata, must call the token a traceability record of a physical lot and of its physical holding. The same research marks that description as an inference. It is not a verified legal classification.

Until a contract exists, use these words, and do not replace them with a stronger claim:

• The record confers no title to the goods.
• The record creates no pledge over the goods.
• The record cannot be redeemed for the goods.
• The record pays no yield.
• The record is not a means of payment.
• The record is not offered as an investment.
• This site states no price for the record.
• Do not write that the record is "backed by" the goods.
• Do not write "1 token = 1 tonne", or "1 token = 1 t", as a statement of title.

A future tenant contract is the document for a binding clause, a governing law, and a forum. None of those exists yet. This section does not supply them.

The same research recommends that a future contract describe A-REX as a technology provider, not a virtual-asset service provider (VASP) and not a financial custodian. That recommendation is an inference. It is not a licence, a registration, or a conclusion that a regulator has accepted.

The research also states, as an inference, that the token must not be issued as a Brazilian rural product note (CPR), a certificate of agricultural deposit (CDA), or an agricultural warrant. A registry reference may be stored as an attestation. The token is not that register.

Personal data and the chain

The documented design forbids personal data on the chain. An origin reference is a salted commitment. Names, tax identifiers, and geolocation stay off the chain and encrypted. Public metadata is not a place for personal data. A hash that has reached a chain cannot be erased. The design forbids the data for that reason.

The legal research lists work that is still open: destroying the salt or the key when a person asks for erasure, a data-protection impact assessment, and the relation between erasure and a five-year retention period under the EU deforestation regulation (EUDR). This page does not complete that work.

In the documented platform, tenant data is reachable only through a support session the tenant owner grants. The design records that session in the tenant's audit chain. That is a documented control. It is not a promise that staff can never see tenant data, and it is not a contract.

Human approval

The security model documents the controls below. The gaps are part of the same description.

In that model, agents and the machine interface (MCP) have read and propose scopes. A propose action creates a pending proposal. A person approves it in a console session, with a second factor. The approver is a different person from the one behind the proposal. An owner may approve a proposal they created in a console session. A proposal that came from an API, from MCP, or from an agent cannot be approved that way by its own creator.

On a managed tenant administration account (a Safe), the documented design needs two signatures out of three. The three are the owner's passkey, a recovery passkey the client holds, and an operations key. The operations key alone does not reach the threshold. The client's two passkeys do. Where the design turns managed custody off (the EU, Argentina, Chile, Bolivia, and US-NY), the account is user-held: two passkeys, and no operations key.

Accounts created before 2026-10-21 may still name an offline recovery key held on the steward's side, until the client swaps it. A person confirms that swap. It does not run by itself.

A managed party account in the same model has one owner. That owner is a key held for the tenant. The rule that the account moves lots only after a person approves is a platform rule in the model, not a second signature on the account. The security model also describes a handover the owner approves, after which the platform refuses to act for that account. The principles document, from the same day, still records that exit as incomplete: the custody text promises more than the code delivers, and that key is still the only owner. These pages do not turn either document into a right you can enforce.

Reading these pages grants no right to operate a tenant, to sign a transaction, or to move a token.

Exit and portability

The principles state that a tenant can leave with its data in open formats, and that records, signatures, and reports can be checked without an A-REX account. The legal research says a future tenant contract must include exit and portability, including an EPCIS 2.0 export (a GS1 event format) and on-chain records that a third party can verify. That contract does not exist yet.

The same principles document records the gap. An EPCIS export covers at most 100 lots in one run. There is no whole-tenant export of the directory, of metadata documents, of proposals, or of the audit chain. Public metadata addresses are served by the platform. They stop resolving if the platform ceases. Treat portability as a design rule with that gap. It is not a delivered exit right.

Early access

Where the site offers early access, the request is for evaluation, implementation, and feedback. Send your own details. The programme is for companies and professionals. The privacy policy states that the site does not knowingly collect data from people under 18.

Sending a request does not create a customer agreement, a right to a tenant, or a right to a particular release.

Unpublished repositories

Material in the private repositories stays confidential until it is published. Do not publish it. Do not quote it to people who did not receive it for that evaluation. Do not treat a private tree as the public standard.

The principles record that, on 2026-10-21, the specification repository and arex-contracts were private. CC0-1.0 and MIT cover the material those licences name, once it is published. They do not make a private repository public.

No exclusivity

Early access grants no exclusivity. The governance gives a hosted product of the steward's founders no early access to undisclosed specification changes, and no exclusive conformance status.

Intellectual property

Use published specification text under CC0-1.0. Use a published reference implementation under MIT. Each licence states its own conditions.

Do not present the Foundation, a maintainer, or this site as the author of a statement they did not publish. Do not present yourself as the steward of the name A-REX. The governance keeps that role with the Foundation until a transfer it already describes. That transfer has not happened. These pages state no trademark registration.

Acceptable use

The acceptable use page states what you may do on this site and what you must not do. It covers early access, prohibited conduct, misrepresentation, the token wording, and sanctions screening. Read it with this page.

Security reports

Report a vulnerability in the specification, in its interfaces and schema, or in the reference implementation under the specification security policy.

Send the report to seanluis47@gmail.com. Use the subject A-REX security: and a short title. Do not open a public issue, discussion, or pull request for the report.

State what is affected, how it can be exploited, the impact, and whether you want to be credited. If you need encryption, say so in a first message that contains no details. The maintainers then agree a channel with you.

The policy sets these targets: acknowledgement within 3 business days; a first assessment within 10 business days; a fix or mitigation plan normally within 90 days of the report; public disclosure after a fix is available, or 90 days after the report, whichever comes first, unless you and the maintainers agree otherwise.

The Foundation is not a registered entity and has no bug bounty for the standard. Reporters are credited in the changelog and in the security note unless they ask not to be.

That policy does not cover a third-party implementation, unless the cause is in the specification. It does not cover an administrator who uses a role the specification gives them. It does not cover a malicious hook that the token administrator registered, unless the specification says that case is safe. It does not cover this documentation site, unless a page could lead an implementer into an insecure implementation.

The platform security model lists further open items: an external audit of the token and attestation contracts, a penetration test, and a bug bounty. None of them is in place. No mainnet release can be marked audited until that external audit exists. Mainnet is not offered. There is no bounty address and no payment for a report.

Changes

When this page changes, the date at the top changes with it. The new text applies to later use of the site. The change still creates no customer contract. If you do not accept the new text, stop using the site and send no new early-access request.

Contact

Questions about these pages: seanluis47@gmail.com.