EARTHIUM LITEPAPER
An Open Coordination Layer for AI Agents, x402 Payments, and Tokenized Real-World Assets

The current Earthium prototype is designed to demonstrate the following flow:

• A user connects a compatible Solana wallet.
• The user selects a simulated RWA product.
• The system presents a test price or payment requirement.
• The wallet requests transaction approval.
• The user authorizes payment using a Devnet test token.
• An Earthium Solana program processes the supported instruction.
• A simulated RWA token is minted or transferred to the user.
• The transaction can be inspected using a Solana explorer.

Solana defines Devnet as a public environment for application testing. Devnet tokens are not real, free test SOL is available through faucets, and the Devnet ledger may be reset. Mainnet is the live production environment.

Therefore, the current prototype demonstrates technical execution but does not yet demonstrate:

• Ownership of a real asset.
• Legal enforceability.
• Real custody.
• Real redemption.
• Regulated issuance.
• A live oracle integration.
• Sustainable liquidity.
• Independent security review.
• Production readiness.

The following information should be added before publication:

The website should not display random or shortened 0x values as Solana transaction references.

Solana public keys and transaction signatures are represented using base58-style strings. Hexadecimal values may still be used for document hashes, but they must be clearly labeled as document or record hashes rather than Solana addresses.

AI agents may discover useful APIs, datasets, compute services, verification tools, or applications but have no simple way to pay for them programmatically.

Traditional systems often require:

• User accounts.
• Passwords.
• Subscriptions.
• Credit cards.
• Manual checkout.
• Repeated human approval.
• Closed platform relationships.

Payment systems, applications, blockchain programs, data providers, and verification services often use incompatible interfaces.

A user or agent must manually coordinate multiple systems to complete one task.

Many tokenized assets fail to clearly explain:

• What the token represents.
• Who issued it.
• Who owns the underlying asset.
• Where the asset is held.
• What legal rights token holders receive.
• How the asset is valued.
• Whether redemption exists.
• What happens if the issuer fails.
• Which jurisdiction governs the arrangement.

A blockchain token is a digital record.

It only becomes a meaningful representation of a real-world asset when supported by enforceable agreements, credible issuers, reliable custody, accurate data, and a working redemption process.

Minting a token does not independently create ownership rights over an offchain asset.

Infrastructure projects are often controlled by a small team while external contributors receive little ownership, recognition, or transparent compensation.

Earthium intends to experiment with an open contributor model supported by a publicly visible token reserve.

Earthium's initial token, programs, test transactions, and user experience will focus on Solana.

Additional chains may be considered in the future through independent adapters. Earthium will not describe itself as omnichain until multiple production implementations are publicly operational.

Users should describe the result they want and define limits such as:

• Maximum payment.
• Accepted payment assets.
• Allowed services.
• Time limit.
• Required output.
• Transaction permissions.
• Risk restrictions.

Earthium-compatible systems should coordinate the remaining steps where possible.

Developers should be able to build modules, integrations, applications, agents, and verification tools without requiring private permission from the original team.

Earthium will not claim that every real-world dependency can be made trustless.

Issuers, custodians, auditors, data providers, legal agreements, and jurisdictions should be identified clearly.

Claims should be supported by public evidence.

Evidence may include:

• Program IDs.
• Transaction signatures.
• Public repositories.
• Verified builds.
• Mint addresses.
• API documentation.
• Test instructions.
• Security reports.
• Published authority addresses.

Earthium may begin with founder-led development.

Governance and operational control should be distributed gradually as the project gains working products, contributors, security processes, and active participants.

Earthium will not include zkVMs, restaking, validity proofs, solver auctions, institutional finality, or similar concepts merely because they sound advanced.

A feature should only be described as active when its implementation can be inspected and tested.

A standard x402 interaction may involve:

• A client requests a paid resource.
• The server responds with 402 Payment Required.
• The response includes the payment requirements.
• The client prepares and signs a payment payload.
• The client resubmits the request with payment information.
• The server verifies and settles the payment.
• The server provides the requested resource.

The x402 flow is appropriate for:

• Paid APIs.
• Data access.
• AI inference.
• Document analysis.
• Asset-information requests.
• Verification services.
• Agent-to-agent services.
• Usage-based developer tools.

x402 does not inherently require one specific wallet experience.

Depending on the application, a payment may be:

• Approved manually by a user.
• Signed by an agent-controlled wallet.
• Executed under a predetermined spending policy.
• Managed through a delegated or session-based permission system.

The current Earthium user interface may use Phantom or another Solana-compatible wallet to request manual approval.

Earthium's initial x402 services should use a stable payment asset where practical.

A stable payment unit makes API and service prices easier to understand.

$EARTH does not need to become the mandatory payment asset for every Earthium service.

Possible separation:

• Stablecoins for measurable service payments.
• $EARTH for ecosystem access, participation, contributor programs, curation, and governance.

A completed Earthium-compatible x402 request may generate a receipt containing:

• Request identifier.
• Service provider.
• Requested resource.
• Payment asset.
• Payment amount.
• Payer.
• Recipient.
• Network.
• Transaction signature.
• Settlement status.
• Completion timestamp.
• Response or output hash.

A receipt confirms that a payment and service interaction occurred.

It does not automatically prove that every piece of data returned by the service is correct.

Step 1: Asset Selection. The user selects a simulated asset, such as a demonstration bond, property share, commodity unit, or invoice. The displayed asset is not a claim over a real underlying asset unless a separate legal framework explicitly establishes such a claim.

Step 2: Price or Quote. The application displays the amount required for the test transaction. The current price may be a manually configured test value, a value stored in the application database, a value returned by a test API, or a value produced by an oracle integration. The website must identify which method is actually used. It must not claim "real-time global market pricing" unless a verifiable live data feed is integrated.

Step 3: Payment Requirement. The application or paid endpoint communicates the required payment. Where x402 is used, this should be demonstrable through an actual HTTP 402 Payment Required response and documented payment payload.

Step 4: Authorization. The user approves the test transaction through a compatible wallet.

Step 5: Test Payment. The application processes a Devnet payment using a test token with no real monetary value.

Step 6: Program Execution. The Earthium Solana program validates the supported conditions and initiates the mint or transfer operation. Solana token minting creates new units of an existing token mint and increases its total supply. Only the configured mint authority can authorize the mint operation.

Step 7: Simulated RWA Token. The user receives a simulated RWA token in the connected wallet. This token proves that the Devnet program successfully executed its programmed instructions. It does not independently prove legal ownership over an offchain asset.

Step 8: Onchain Receipt. The user receives a Solana transaction signature that can be inspected through an explorer. The receipt should identify the network as Solana Devnet. It should not be described as a mainnet transaction or permanent legal ownership record.

The interface allows humans or agents to:

• Connect a wallet.
• Search for available services or assets.
• Submit an intent.
• Review a quote.
• Set spending limits.
• Approve execution.
• Receive results and receipts.

An Earthium intent may contain:

• Intent identifier.
• Requester.
• Requested action.
• Input data.
• Maximum payment.
• Accepted payment assets.
• Allowed network.
• Expiration time.
• Required verification level.
• Execution permissions.
• Output format.
• Failure conditions.

The schema should remain open and versioned.

Developers and providers may register modules or services with:

• Service name.
• Operator.
• Endpoint.
• Supported actions.
• Input schema.
• Output schema.
• Payment requirements.
• Supported network.
• Version.
• Repository.
• Security information.
• Availability status.

The first registry may use a public database and repository before more decentralized alternatives are explored.

The payment adapter handles:

• Payment requirements.
• Supported assets.
• Payment payload construction.
• Verification.
• Settlement.
• Payment responses.
• Error handling.
• Receipts.

The current or future Earthium program may support functions such as:

• Asset-record creation.
• Issuer registration.
• Attestation recording.
• Status updates.
• Test-asset minting.
• Redemption-related burns.
• Authority checks.
• Payment-linked execution.
• Receipt creation.

The exact deployed functions must be documented from the source code rather than inferred from the interface.

Some services may remain offchain, including:

• Document storage.
• Search and indexing.
• Legal documents.
• Large metadata records.
• External API integrations.
• Oracle data retrieval.
• Agent inference.
• Analytics.

Relevant documents may be hashed, with the hash referenced by an onchain record.

The dashboard should display:

• Network status.
• Program ID.
• Supported assets.
• Asset records.
• Issuers.
• Attestations.
• Transaction signatures.
• Expiration and revocation status.
• Contributor Reserve activity.
• Development releases.

An Earthium-compatible asset profile should include:

• Asset identifier.
• Asset name.
• Asset category.
• Description.
• Issuing entity.
• Issuer jurisdiction.
• Underlying asset owner.
• Custodian.
• Asset location.
• Supporting documents.
• Document hashes.
• Valuation method.
• Valuation provider.
• Valuation date.
• Token-holder rights.
• Transfer restrictions.
• Redemption process.
• Expiration or maturity date.
• Applicable jurisdiction.
• Known risks.
• Attestations.
• Current status.

A token should not be described as ownership of an asset unless supporting legal documents establish that relationship.

Depending on the structure, a token may represent:

• Direct legal ownership.
• Beneficial ownership.
• A contractual payment right.
• A claim against an issuer.
• A fund interest.
• A revenue-sharing agreement.
• Access or usage rights.
• A non-binding digital representation.

The exact relationship must be disclosed.

An asset profile should identify:

• Who holds the underlying asset.
• How custody is verified.
• Whether the asset can be pledged elsewhere.
• What occurs if the custodian becomes insolvent.
• Whether insurance exists.
• How custody records are updated.

A real RWA product should explain:

• Who may redeem.
• Minimum redemption amount.
• Required identity or compliance checks.
• Redemption fees.
• Processing time.
• Settlement asset.
• Geographic restrictions.
• Failure procedures.

Without a credible redemption mechanism, the market value of a token may move independently from the stated value of the underlying asset.

An oracle or external data service may provide a reference value.

A reference price does not automatically force the market price of a token to match the underlying asset.

Maintaining price alignment may also require:

• Minting and redemption.
• Sufficient reserves.
• Arbitrage.
• Liquidity.
• Market makers.
• Reliable valuation.
• Clear legal claims.

Earthium will only describe a price feed as active after publishing the data source, feed identifier, update process, and failure handling.

A record may contain:

• Attestation identifier.
• Asset identifier.
• Attester identity or public key.
• Claim type.
• Claim summary.
• Supporting-document hash.
• Issue date.
• Expiration date.
• Status.
• Revocation reason.
• Signature.
• Network reference.

Examples include:

• Ownership documents reviewed.
• Custody balance confirmed.
• Valuation report received.
• Insurance policy active.
• Corporate registration verified.
• Invoice documentation reviewed.
• Redemption request completed.
• Asset information expired.
• Previous attestation revoked.

An attestation proves that a particular party made a particular claim.

It does not guarantee that the claim is absolutely true.

Users must still evaluate:

• Who issued the attestation.
• What evidence was reviewed.
• What was excluded from the review.
• Whether the attester is independent.
• Whether conflicts of interest exist.
• Whether the attestation remains current.

A record showing that a transaction or program instruction occurred.

A cryptographic fingerprint used to detect whether a document has changed.

A document hash does not prove that the document's contents are truthful.

A signed claim made by an issuer, verifier, custodian, auditor, or another identified party.

Rules executed directly by a Solana program, such as checking authority, status, limits, or expiration.

A verified build demonstrates that the executable program deployed on Solana corresponds to the published source code.

Solana notes that this improves transparency but does not by itself prove that the code is secure.

A validity proof normally refers to a cryptographic proof showing that a computation followed specific rules.

Earthium will not claim validity-proof functionality unless it has:

• A defined proof system.
• A prover.
• A provable program or circuit.
• Verification keys.
• A verifier implementation.
• Public proof examples.
• Reproducible source code.

Until then, the website should use:

• Onchain receipt.
• Program-validated record.
• Attestation record.
• Document hash.
• Verified transaction.

At launch, $EARTH primarily represents participation in the early Earthium community.

Initial uses may include:

• Access to community discussions.
• Participation in product testing.
• Submission of ecosystem proposals.
• Contributor identification.
• Funding or creating public bounties.
• Access to selected development updates.

As working software is released, $EARTH may support:

• Access to selected Earthium tools.
• Discounts on selected service fees.
• Contributor bounties.
• Module curation.
• Issuer or operator deposits.
• Beta-program access.
• Governance proposals.
• Ecosystem grants.
• Higher limits for selected services.
• Reputation-linked contributor programs.

A proposed utility should only be described as active when it is connected to working software.

$EARTH does not need to be the mandatory payment currency for every x402 request.

Earthium services may accept stablecoins or other supported assets.

This allows:

• Stable pricing for APIs and services.
• Flexible provider participation.
• Separation between service payments and ecosystem governance.
• Reduced pressure to create artificial token utility.

Holding $EARTH does not guarantee:

• Income.
• Dividends.
• Fee sharing.
• Price appreciation.
• Buybacks.
• Burns.
• Redemption.
• Ownership of Earthium.
• Ownership of any underlying RWA.

The token's relevance will depend on actual products, usage, integrations, contribution, and community participation.

The reserve is intended to reward measurable contributions such as:

• Smart-contract development.
• x402 integrations.
• Agent modules.
• RWA schemas.
• Security research.
• Bug fixes.
• Documentation.
• SDK development.
• Interface design.
• Testing.
• Data integrations.
• Third-party Earthium applications.

The reserve is intended to be acquired through the public launch or public market rather than through a concealed pre-mint allocation.

The final amount may be lower than 15% depending on actual acquisition conditions.

Earthium should publish:

• Reserve wallet address.
• Current balance.
• Distribution transactions.
• Recipient wallet.
• Reward amount.
• Contribution description.
• Supporting repository, pull request, report, or release.

The reserve may initially be controlled by a publicly identified project wallet.

It should progressively move toward:

• Multisignature control.
• Public reward criteria.
• Independent contribution review.
• Periodic reserve reports.
• Community proposal mechanisms.

The reserve should not be described as decentralized while one person retains unilateral control.

Wallets and agents should receive only the permissions required for a specific task.

Agent payment systems should support:

• Per-transaction limits.
• Daily limits.
• Approved-token lists.
• Approved-service lists.
• Network restrictions.
• Expiration periods.
• Revocation.

Earthium must publish and secure:

• Program upgrade authority.
• Token mint authority.
• Freeze authority, if any.
• Treasury authority.
• Contributor Reserve authority.
• Oracle-update authority.
• Attestation-revocation authority.

Production authorities should use multisignature control where practical.

The project should publish source code and pursue verified builds so users can compare deployed bytecode with the public repository.

Deploying a Solana program requires SOL, with the required amount depending on the compiled program size. The project should publish the program size and deployment-cost calculation before requesting mainnet deployment funds.

Testing should cover:

• Unauthorized mint attempts.
• Duplicate payment attempts.
• Incorrect asset identifiers.
• Expired attestations.
• Revoked verifiers.
• Payment failure.
• Partial execution.
• Replay protection.
• Incorrect decimal handling.
• Authority compromise.
• Oracle failure.
• Frontend manipulation.

Earthium will not claim to be audited unless it publishes:

• Auditor identity.
• Audit scope.
• Audit date.
• Full report.
• Findings.
• Remediation status.
• Commit or program version reviewed.

During early testing, users should use dedicated wallets containing only limited test funds.

The initial team manages repositories, technical priorities, project wallets, and releases.

Decisions should be documented publicly.

Recognized contributors participate in:

• Technical proposals.
• Module review.
• Documentation.
• Bounty evaluation.
• Security discussions.
• Product prioritization.

Community members may propose:

• Integrations.
• Grants.
• Development priorities.
• Treasury initiatives.
• Module standards.
• Contributor programs.

Where appropriate, Earthium may introduce:

• Multisignature authorities.
• Delegated working groups.
• Public voting.
• Treasury controls.
• Independent module operators.

Token voting will not replace security review, legal obligations, or technical expertise.

Current reported status: built, pending public verification.

• Build wallet connection.
• Build a test payment flow.
• Deploy an Earthium program to Solana Devnet.
• Process a test purchase.
• Mint or transfer a simulated RWA token.
• Return an onchain transaction record.
• Display the resulting token in the user's wallet.

• Publish the Devnet Program ID.
• Publish deployment transactions.
• Publish token mint addresses.
• Publish example purchase and mint transactions.
• Publish the source repository.
• Document all program instructions.
• Publish x402 endpoint behavior.
• Identify the facilitator or settlement method.
• Publish authority addresses.
• Produce a verified build.
• Remove unsupported website claims.

• Launch at least one functional paid API.
• Return a genuine HTTP 402 payment requirement.
• Support a documented Solana payment flow.
• Add payment limits.
• Add duplicate-payment protection.
• Return machine-readable receipts.
• Release buyer and seller integration examples.
• Publish an initial SDK.

• Publish an RWA asset-profile schema.
• Publish an attestation schema.
• Build document-hashing tools.
• Add expiration and revocation.
• Build issuer and verifier profiles.
• Add structured risk categories.
• Release a public asset-information dashboard.
• Maintain all assets as demonstrations unless legally backed.

• Complete security review.
• Calculate and publish deployment costs.
• Deploy the Earthium program to Solana Mainnet.
• Publish the Mainnet Program ID.
• Secure authorities through multisignature control.
• Launch production x402 services.
• Support non-investment or demonstration asset records.
• Avoid presenting experimental records as regulated financial products.

• Partner with a legally identifiable issuer.
• Select one limited asset category.
• Complete jurisdiction-specific legal review.
• Define token-holder rights.
• Establish custody.
• Establish verification procedures.
• Define minting and redemption.
• Publish risks and disclosures.
• Onboard independent verifiers.
• Conduct a limited pilot before broader access.

• Release an open module registry.
• Add structured intents.
• Support service discovery.
• Support multi-step workflows.
• Add agent spending policies.
• Enable third-party applications.
• Launch contributor bounties.
• Expand SDKs and developer documentation.

• Expand multisignature controls.
• Introduce public treasury reporting.
• Establish contributor working groups.
• Implement module curation.
• Test community proposals.
• Distribute appropriate operational responsibilities.

• Evaluate additional chains based on actual user and issuer demand.
• Build independent chain adapters.
• Keep Solana as the canonical home of $EARTH unless formally changed.
• Clearly label each chain and transaction format.
• Avoid creating duplicate uncoordinated token supplies.
• Do not describe Earthium as multichain until integrations are publicly operational.