Privacy Policy

Who Is Responsible for Your Data

Vowels Group LLC ("eIOU", "we", "us") is responsible for the personal data we process to operate this website, answer inquiries, manage newsletter subscriptions and tester applications, and provide nodes we host. Contact privacy@eiou.org about that processing or your rights.

The eIOU protocol records bilateral obligations on participants' nodes. It does not require a central ledger. That does not mean all data stays on one device: counterparties keep their own records, hosted-node administrators can access the systems they operate, and inference sends content to the services doing the work. Independent node operators, MCP clients, and inference providers are responsible for their own processing; their notices also matter.

Data Collection

How Data Collection Works

Important: eIOU is a decentralized protocol. Each Docker node operates independently and stores its own data. Your wallet keys, contacts, and obligation history live inside that node, not on any central server.

Our organizational data flows include the following:

• Anonymous analytics (off by default, opt-in): If you explicitly enable analytics on your node, it sends an initial setup event and daily aggregate usage reports through Tor. Reports include a persistent pseudonymous identifier, node version, timestamps, and aggregate counts (transaction counts, contact count, volume per currency). The identifier scheme depends on your node version: current source generates a random identifier per installation; older versions derived it from the node public key. The documented payload excludes individual transaction records, contact details, counterparties, IP addresses, and private keys. Aggregate volume totals are included. A persistent identifier and small aggregate counts should not be treated as a guarantee against identification. You can disable analytics at any time through the GUI, CLI, or API. See the current analytics implementation; check the source matching your installed version for its exact behavior.
• Hosted nodes (optional onboarding): We offer eIOU-hosted nodes as a convenience for users who'd rather not run their own Docker container. When you use a hosted node, the container runs on infrastructure we operate. We do our best to protect your hosted wallet data, and our long-term goal is to encrypt it so that only you can access it. During the current open alpha we have not yet achieved that goal: we retain administrative access to nodes we host, and we may use that access for internal debugging, support, incident response, and product development. We may also be compelled to share information by a valid government order, in which case we would comply only to the extent the law requires and would notify you unless prohibited from doing so. Self-hosting lets you choose and control the host and its access permissions. Hosting providers, administrators you authorize, plugins, or a compromised system can still affect confidentiality. See gitlab.com/eiou-org/eiou-docker.
• Contact-form and email submissions: When you fill out the contact form on this website or email one of our addresses, we receive what you sent (name, email, organization if you choose to provide it, topic, message) to respond and handle related support or security follow-up.
• Newsletter subscriptions: Your browser sends your email address and anti-bot challenge token directly to Brevo, our mailing-list provider. See Newsletter and form security for the recipients, purpose, and unsubscribe options.
• Website requests: Cloudflare handles page requests and form delivery; Google Analytics receives visit information only after analytics consent. See Website Analytics.
• MCP alpha tester requests: The dedicated tester flow requires your eIOU node address and records your selected MCP client, confirmation that you control the node, and any optional name or contact email you provide. Cloudflare Workers and Email Routing deliver that request to the eIOU pilot mailbox so we can assess pilot fit and coordinate access. We do not ask for or accept wallet seeds, wallet passwords, bearer keys, or provider credentials. Requests remain in the pilot mailbox only while needed for access coordination, support, security follow-up, and the pilot record; ask privacy@eiou.org to access or delete yours.

What Your Node Stores Locally

Every eIOU node, whether you self-host or use one we host for you, maintains the following data in its configured storage (usually Docker volumes):

• Obligation Data: The minimum information needed to record eIOU obligations: parties, amount, currency, timestamp
• Contact Data: The peers your node knows about, with whatever profile information they've chosen to share with you. Encrypted end-to-end (ECDH + AES-256-GCM) when it traverses the network, and encrypted at rest via MariaDB Transparent Data Encryption
• Network Data: Addresses used to reach peers (HTTP, HTTPS, or .onion identifiers)
• Cryptographic Material: Wallet private keys, the BIP39 24-word seed phrase, and encryption keys for at-rest data. The node encrypts wallet private keys and the mnemonic; protection of the master encryption key depends on deployment settings. Plugins may use separate secrets

How Data Is Used

On your node

The core node uses its records for:

• Processing and facilitating eIOU obligations within the network
• Maintaining network integrity and preventing fraud (signature verification, chain integrity checks, replay protection)
• Enabling peer-to-peer trust relationships
• Recording obligation history so you can audit and reconcile against your contacts

By the eIOU organization

Our organizational uses include:

• Anonymous analytics (if you opted in) is used to track aggregate ecosystem health: how many nodes are active, rough transaction volume by currency, version distribution. We do not use it to identify people or build advertising profiles
• Hosted-node operational data: during the current alpha we retain administrative access to nodes we host. We use that access to keep nodes running, debug issues, respond to support requests, and develop the product. We do not export hosted-node data for marketing, advertising, sale, or any commercial purpose outside operating the service
• Contact-form submissions are used to reply and manage related support or security follow-up
• Newsletter addresses are used to send the updates you requested and manage subscriptions and opt-outs
• MCP alpha tester requests are used only to review pilot eligibility, coordinate access, support approved testers, and investigate security or abuse reports connected to the pilot

Purposes, Legal Bases, and Retention

Draft legal-basis mapping — awaiting controller confirmation: The proposed bases, where the GDPR applies, are consent for newsletter delivery and optional analytics; requested pre-contract steps or contract performance for service applications and hosted-node delivery; legitimate interests for inquiries, security, abuse prevention, and support; and legal obligations where a specific law requires a record. Vowels Group LLC still needs to confirm the applicable basis for each activity and the associated assessments. This proposal does not establish those assessments or authorize unrestricted reuse for product development.

Current alpha limitation: Retention schedules and service settings for our mailboxes, hosted-node backups, newsletter consent records, and website service logs still require confirmation by Vowels Group LLC. Do not assume a particular automatic deletion deadline. The considerations below identify arrangements that need to be confirmed; contact privacy@eiou.org for the applicable arrangements before submitting data that needs a firm retention limit.

• Inquiries and tester applications: Retention depends on whether an inquiry is unresolved, an application or pilot relationship is active, or a support, abuse, or legal issue still needs the record. A completed application does not automatically erase the delivery email or its backups.
• Newsletter: The subscription is used while you remain subscribed. Unsubscribing stops newsletter delivery; a limited suppression or consent record may remain to respect your opt-out and demonstrate how the subscription was obtained. Brevo's delivery and security records have their own retention arrangements.
• Hosted nodes: Live node data supports the hosted service and obligation history. Contact us about hosted-node deletion and backup arrangements. Closing or deleting a hosted node does not delete counterparties’ independent copies.
• Website and analytics: Security logs support abuse detection and incident investigation. Analytics retention depends on our service settings and the providers' policies; this notice does not promise a verified fixed period for those records. Revoking analytics consent stops future collection through the website but does not itself erase past submissions.
• Inference: The client, node operator, seller, and upstream provider have separate storage and deletion arrangements. The specific plugin behavior described below is not a retention promise for those other systems.

Independent operators must explain their own purposes, legal bases, recipients, and retention. The European Commission's transparency guidance explains the information individuals should receive.

Data Storage & Security

Decentralized by Design: The eIOU protocol has no central server. Obligations are bilateral records held by the two counterparties involved. Each side stores its own copy in its own node. There is no global ledger, no distributed-ledger replication, and no central authority that can rewrite obligation history.

End-to-end encryption: The node protocol uses ECDH key agreement and AES-256-GCM to protect contact-message payloads between peers. This protects content in transit; it does not hide it from the receiving peer or an administrator with access to either endpoint. It is not a blanket encryption claim for website forms, plugins, or inference providers.

Encryption at rest: The node uses MariaDB Transparent Data Encryption for database contents, with the database encryption key regenerated into RAM from the core master key on startup. Wallet private keys, auth codes, the mnemonic, and automatic backups use AES-256-GCM. Encryption of the core master key on persistent storage requires optional volume-passphrase configuration. Without it, access to the configuration storage can expose the key needed to decrypt protected data. Plugin secrets may use a separate master key stored on disk; encryption does not prevent a host administrator or an attacker with sufficient system access from reading usable keys.

Seed phrase is the root of trust: Core wallet keys, Tor identity, and core encryption and backup keys derive from the BIP39 24-word seed phrase generated on first boot. Whoever holds the seed phrase controls the wallet. Store it securely offline and outside version control. Plugins can use independently generated secrets, so a wallet seed is not a backup of every plugin credential.

No central database: There is no central ledger for all eIOU obligations. We do operate organizational records such as mailboxes and subscription lists, and can access the nodes we host. These data flows are described in Data Collection above.

Tor & Anonymous Usage

Tor is built in and enabled by default. Every eIOU node starts a Tor daemon and auto-generates an .onion address on first boot. The default transport priority is Tor › HTTPS › HTTP, so nodes prefer the most metadata-private option available without any configuration on your part.

Tor reduces exposure of network addresses and communication metadata by distributing traffic across relays. It does not guarantee anonymity or prevent traffic correlation: an observer able to monitor both ends can compare timing and traffic patterns. Account identifiers, prompt contents, endpoint compromise, and traffic sent outside Tor can also identify participants. See the Tor Project's explanation of remaining attacks.

Some operations are deliberately Tor-only. Most notably, contact status pings emit recognizable timing patterns that would let an HTTPS observer reconstruct the contact graph if they were ever permitted to fall back to HTTPS. If Tor is unavailable, pings simply fail rather than silently downgrading transport privacy.

A VPN is not a substitute for Tor in this threat model: a VPN provider can observe your source IP and destination connections, while Tor distributes that trust across independently-operated relays. A VPN can still be useful as an additional layer for hiding destinations from your local ISP, but do not disable Tor on the assumption that "a VPN covers it."

Data Sharing

We never sell, rent, or trade personal data. See Data Collection for the full inventory. The data we do hold is shared only as follows:

• Service providers we depend on: Cloudflare provides website hosting, DNS, Workers, Email Routing, and Turnstile anti-bot checks. Brevo handles newsletter subscriptions and email delivery. Google Analytics receives page-visit telemetry after consent. Cloudflare handles request metadata and the contents of forms delivered through its email pipeline; the newsletter is submitted directly to Brevo. See Website Analytics below for the Google Analytics specifics.
• Legal process: If we ever receive a valid legal demand we would comply only to the extent the law requires, and we'd notify the affected user unless prohibited from doing so. The scope of what we can produce depends on what we actually hold. That can include node analytics submissions with pseudonymous identifiers, contact-form emails, and MCP tester requests. For users of hosted nodes during the current alpha it additionally includes anything stored inside the node we operate on their behalf, since we retain administrative access to hosted nodes during alpha (see the Hosted nodes bullet under Data Collection). Self-hosting does not automatically give us your node database. We may still hold records you send us, obligations involving a node we operate, or inference data processed through a service we operate.
• With your explicit consent: Anything else only with your specific authorization for a specific purpose.

What your own node shares peer-to-peer is separate. When you transact with a counterparty, your node and theirs exchange the obligation data, addresses, and contact details needed to settle. The counterparties retain their own copies. We receive those records when we operate a participating node or host the relevant infrastructure.

MCP Inference: Who Sees Your Prompts and Outputs

Connecting an MCP client to your own node does not keep inference content only on that node. The intended route is your client → your node → the selected seller → the seller's configured model service. The last step may be a local model on the seller's hardware or an external API provider.

• Your client: Receives your input and the returned output. Its application, conversation history, cloud features, and telemetry can create additional copies according to the client's settings and provider policy.
• Your node and its operator: Process prompts, conversation context you submit, and outputs. On a self-hosted node you manage access and logging. On a node we host, our administrative access also applies to inference data processed or stored there.
• The selected seller: Receives the request content needed to run the model and handles the result. Its operator can access that content and may have application, proxy, security, or billing logs.
• The upstream model provider: Receives the submitted content and generates the output when the seller uses an external service. That provider's account settings and terms determine storage, abuse review, training use, and deletion. eIOU does not promise zero retention or no training across all providers.
• Payment intermediaries: Receive the payment and routing information needed for obligations. The plugin's direct buyer-to-seller work connection does not send prompts or outputs through nodes that only relay payment.

Fallback can change recipients. If the configured routing policy permits retrying a failed request through another seller or upstream service, the same input may reach that additional recipient. A failed attempt may already have received the input. The plugin does not retry a stream after output has been delivered to the client, but that safeguard does not erase earlier recipients' copies. Ask your node operator which routes and fallback choices are enabled.

What the plugin records: In v0.29.3, usage records include model, token counts, charges, and request identifiers. Route-attempt history records the route, timing, outcome, and cost rather than prompt or output content; its maintenance task prunes entries older than 14 days when that task runs successfully. The explicit federated-deal workflow also stores the submitted user prompt in the buyer node's job record. That job record does not store the generated output, but this is not a guarantee about client history or operator logs. There is no equivalent automatic expiry shown for job prompts or usage records in this version.

Each operator must tell you its logging and backup practices and retention periods before you rely on them. Deleting local history or disconnecting the plugin does not delete seller or upstream copies. See the federation documentation and plugin storage implementation.

Newsletter and Form Security

When you subscribe on the homepage, your browser submits your email address, locale, anti-bot field, and Cloudflare Turnstile challenge token directly to Brevo's subscription endpoint. Brevo processes the subscription and sends newsletter-related email for us. Subscribing is optional and is your consent to receive those updates; use the unsubscribe link in a newsletter or email privacy@eiou.org to withdraw it.

The newsletter loads Turnstile when you start a subscription submission. The MCP tester confirmation also uses Turnstile. Cloudflare processes browser and network signals, including IP address, user-agent, TLS information, and the site origin, to detect bots. These security checks are separate from optional Google Analytics and can run when analytics consent is declined. Cloudflare also uses signals to improve its bot detection under its own responsibility, as described in its Turnstile Privacy Addendum.

Brevo and Cloudflare receive ordinary connection metadata when your browser contacts them. Their processing can involve infrastructure outside your country; the applicable locations, safeguards, and service retention settings are not fully specified in this alpha notice. Contact us for those details. See Brevo's privacy policy for its handling of personal data.

Plugins

The eIOU node software supports plugins: optional add-ons that may extend the node by contributing Web GUI sections, CLI subcommands, REST API endpoints, payback-method rail types, and event subscribers. A plugin may also run additional services inside or alongside the node container, expose publicly reachable endpoints that accept requests from people other than you, and transmit data it can access to external services in order to do its work. Plugins are disabled by default; the operator must explicitly enable each one. Plugins fall into two categories with different privacy implications, but those categories determine who is responsible for a plugin, not what it is technically able to do.

Bundled plugins (authored by eIOU and shipped inside the official Docker image): these follow the data practices disclosed by eIOU. Most access only the same on-node data your node already holds and transmit nothing outside the node beyond what this policy discloses. Where a bundled plugin's core function involves transmitting data to an external service or accepting inbound requests on a public endpoint, that behavior is documented and you enable it deliberately. Bundled plugins are open source and verifiable in the eiou-docker repository.

Third-party plugins (anything not bundled, including plugins from a publisher whose signing key you have chosen to trust and eIOU-authored plugins not yet shipped in the official image): the node software enforces a mandatory sandbox on every plugin. Sandboxed plugins run in their own isolated process under their own Unix user, with no filesystem access to wallet secrets, no direct database access to core tables (contacts, transactions, API keys, balances, payback methods, or other plugins' tables), and no ability to read wallet private keys, the BIP39 seed phrase, the master encryption key, or API-key plaintext. The node refuses to install or enable any plugin that has not opted into the sandbox.

Within that sandbox, a plugin can access a controlled, read-only set of queries that it declares in its manifest and the operator approves at install time. Depending on the permissions the operator approves, that access may include contact information (names, pubkey hashes, online status, and, with additional permission grants, the full address book), transaction records (memo, amount, counterparty), wallet balance, payment requests, and payback-method preferences. Any data accessible to a plugin can be transmitted off the node by the plugin's own code. An external plugin's privacy practices depend on its publisher and operator. An eIOU-authored plugin that is distributed separately, such as MCP passthrough, is also covered by the relevant disclosures in this policy; placement outside the bundled image does not remove our responsibility for our own processing.

Signature verification within the node software is a technical control you use to limit installations to publishers whose signing keys you have chosen to trust; it does not constrain what a plugin does after installation, and it is not an endorsement or audit by eIOU.

Plugins that serve other people: a plugin may expose a publicly reachable endpoint on your node that accepts requests from third parties (for example, a plugin that resells access to a service in exchange for eIOUs). When you enable such a plugin, your node receives and processes input submitted by those users, and the plugin may forward that input to external services to carry out the request. How those users' data is handled is governed by you as the operator and by the plugin's publisher, alongside this policy where Vowels Group LLC also processes the data. Where a plugin's publisher provides its own privacy terms, those terms govern the publisher's handling of that data; where it provides none, this policy's disclosures continue to apply to the extent the plugin processes data on your node. If you operate a service like this, you are responsible for telling its users how their data is used.

What this means for your data: if you run only bundled plugins, the inventory in Data Collection remains accurate. If you enable any third-party plugin, the sandbox protects wallet secrets, but the data you authorize the plugin to access (through the permissions you grant at install time) can be transmitted off the node by the plugin. Review each third-party plugin's manifest, its requested permissions, its documentation, and its source before granting trust. Disabling a third-party plugin does not retroactively undo any data it may already have transmitted off the node.

Website Analytics

This website (eiou.org) can use Google Analytics 4 (measurement ID G-BKZVJNW6GJ) to understand aggregate traffic: which pages are visited, how visitors find the site, what devices and rough geographic regions are common. We use this only to decide where to invest documentation, content, and product effort.

Consent required. Google Analytics is not loaded until you accept the consent banner that appears on your first visit. If you reject (or never respond), no Google Analytics script is fetched, no analytics cookies are set by this integration, and it sends no analytics data to Google. Your choice is stored in your browser's local storage and can be changed via the "Cookie preferences" link in the page footer. Rejection disables this integration on the current page, including an already-loaded tag; it does not recall requests already sent or erase existing analytics cookies or records. If local storage is unavailable, your choice applies only to the current page.

If you do accept, Google Analytics loads and, by default, sets cookies in your browser and sends Google information including connection metadata such as your IP address (used by Google to derive approximate location, rather than logged or stored as an IP address in GA4), user agent, referrer, and the URL of each page you visit. See Google's explanation of regional data collection. We do not currently make use of Google Ads, conversion tracking, audience-remarketing, Google Signals, or cross-device identity linking integrations.

This is a website-only data flow. Google Analytics is loaded by the marketing website, not by the eIOU node software. This website analytics integration is not part of the node. Plugins or upstream inference services you configure may separately contact Google or other providers.

Additional opt-out options: beyond rejecting the banner, you can use any browser-level tracker blocker (uBlock Origin, Privacy Badger, Brave's built-in shield, Firefox's strict ETP mode), install Google's official opt-out browser add-on, or use browser privacy controls. Browser or network choice alone is not a guarantee that analytics requests are blocked.

Your Rights

You can manage your node locally and make requests about personal data processed by Vowels Group LLC. These are separate controls:

• Access your data: Your obligation history, contacts, balances, and settings are queryable directly from your node via the GUI, the eiou CLI, or the REST API
• Take your data with you: The CLI's eiou backup create produces an AES-256-GCM-encrypted database dump you can move to a new host or keep as an offline archive. Volume-level backups (raw tar of MariaDB, config, and backups) are documented in the Docker repository's README
• Delete local node storage: docker compose down -v removes the Compose containers, named volumes declared by the project, and attached anonymous volumes. It does not remove external volumes or files on bind mounts, and it is not a secure-erasure guarantee. Separately review host snapshots, copied backups, exports, and logs. Counterparty records, external backups, and upstream logs survive local deletion. See Docker's removal rules. For a node we host, contact us to coordinate deletion
• Reduce network exposure: Use Tor and review the transports your node and plugins actually use. Tor reduces exposure but does not guarantee anonymity or protection against traffic correlation
• Opt out of analytics: Node-level anonymous analytics is off by default; if you've turned it on, disable any time via the GUI, CLI, or API. Website-level Google Analytics is gated by the cookie consent banner; revoke at any time via "Cookie preferences" in the footer
• Rights over organizational processing: Depending on applicable law, you may request access, correction, erasure, restriction, or portability, object to processing based on legitimate interests, and withdraw consent without affecting earlier lawful processing. Email privacy@eiou.org; we may need proportionate identity verification. Legal obligations and other people's rights can limit erasure. You may complain to your local data protection authority. Requests to us do not automatically reach independent counterparties or inference providers

Children's Privacy

eIOU is intended for adults of legal contracting age in their jurisdiction (generally 18+ in the US). Creating and accepting eIOU obligations is a financial act that minors may lack legal capacity to perform.

We do not direct the website at children, do not knowingly collect personal information from anyone under 13 (the threshold defined by the US Children's Online Privacy Protection Act), and would delete any such information promptly on becoming aware of it. If you believe a child has provided personal information through our contact form or another channel, please email privacy@eiou.org and we will remove it.

Changes to This Policy

We may update this Privacy Policy as the protocol and the organization evolve. The "Last Updated" date at the top of the page reflects the most recent revision, and every prior version is preserved on this site, with the version selector near the top of the page linking to each one once material changes have been published.

For material changes (anything that meaningfully expands what data we collect, who we share it with, or how it's used) we'll announce the change on the project's GitLab repository and on the website itself before the change takes effect, so you have time to review and act on it (revoke consent, stop using a hosted node, etc.). Minor copy edits and clarifications don't trigger an announcement.

Contact Us

For questions, concerns, or requests about this Privacy Policy or our privacy practices:

Open Source Transparency

The eIOU node software is open source under the Apache License 2.0 and is currently in open alpha. The source lets you inspect technical behavior. Organizational practices and provider account settings require separate confirmation:

• Anonymous analytics: implementation at files/src/services/AnalyticsService.php, daily cron at files/scripts/analytics-cron.php, and background documentation in docs/ANONYMOUS_ANALYTICS.md
• End-to-end encryption: payload encryption code paths and threat model documented in SECURITY.md
• Tor integration: Tor daemon configuration, hidden-service publication, and circuit-health logic visible in eiou.dockerfile and the related startup.sh
• This privacy policy itself: every prior version is preserved on this site and accessible via the version selector near the top of the page

The node-software repository accepts community contributions at gitlab.com/eiou-org/eiou-docker.