Compliant Settlement Layer and Tokenisation Engine

Section 1

The engagement

This proposal covers a compliant settlement layer for DataVault's real-world asset exchange: an on-chain registry of approved holders, permissioned token contracts that enforce it, and an API through which the DataVault platform deploys and manages both.

The asset class

The engine is built for pre-extraction mining and energy assets: gold, copper, diamond, rare earths, and geothermal. These are tokenised before the resource comes out of the ground, so the token represents an entitlement against an asset that will be produced rather than one already held in a vault.

The registry itself is agnostic to the underlying asset. It governs who may hold a token and under what conditions, so any asset DataVault chooses to issue as a security uses the same infrastructure. The assets above are the first application, not the boundary of it.

What the asset class requires

This proposal is built for instruments treated as securities rather than commodities. RubySDK expresses no view on that classification and does not advise on it; we supply the infrastructure the classification requires.

What follows from it is structural. Where an asset is treated as a security, the register of holders is maintained on chain, where the asset settles, rather than on the platform that issued it. Once a token can move from one wallet to another without passing back through a platform's front end, an off-chain register no longer determines ownership.

In practice that means one specific artefact. An on-chain list of approved and restricted holders, enforced at the contract, so that a transfer to an unapproved wallet fails whether or not the trade was initiated on DataVault's platform. Everything about it is standardised, and section 2 sets out the standard.

The boundary

The boundary this proposal assumes is that DataVault retains the exchange, the client relationships, the assets, the tokenomics, the metadata storage and analytics, and the chain publishing. RubySDK supplies the registry, the permissioned token contracts, the redemption logic, and the API that connects them. Nothing in this proposal asks DataVault to replace the portal, the API layer, or the trading platform.

Section 2

What RubySDK provides

RubySDK issues permissioned security tokens using ERC-3643, the T-REX standard, and this proposal is built to it. It is not a RubySDK invention and it is not a proprietary variant: it is the token standard the regulated tokenisation market has converged on, and it exists precisely to solve the problem of an on-chain holder list.

The four parts of the standard

Unapproved trades

An attempted trade by an unapproved party needs no custom on-chain logic beyond rejecting it. Rejection is the standard behaviour of the compliance module. The transfer function calls a check, the check fails, and the transaction reverts with a reason code. There are no custom rules to write for invalid trades, and DataVault's platform can read the revert reason to show the user why the trade did not settle.

Where KYC sits

KYC stays with DataVault. RubySDK does not perform identity verification and does not want DataVault's customer records. What goes on chain is the verified claim, not the personal data: a signature from the trusted issuer asserting that the wallet behind a given identity passed verification, with a claim topic and an expiry. No name, no document, no date of birth, no address. That is what makes user-to-user transfer possible without moving personal data on chain.

Section 3

The custom layer: redemption against the underlying asset

The one piece that is genuinely custom for a pre-extraction asset is redemption. A token issued before the resource is out of the ground has nothing to redeem against until the mine is in operation, so the token needs a defined period during which a holder may redeem against the underlying asset once production begins. RubySDK proposes to implement this as a redemption period on the token.

This is an extension to the compliance and transfer-restriction layer, not a rewrite of it. The redemption period is a state on the token that the compliance module reads, in the same way it reads a lock-up. The design below is RubySDK's proposal, implemented against DataVault's commercial rules and confirmed in Discovery.

Where DataVault already holds redemption logic of its own, we take that as the input specification rather than write our own from an assumption. If the existing implementation is sound, we adapt it to sit behind the compliance module rather than replace it. Where existing code assumes an unrestricted token, we will say so in writing during Discovery and propose the minimum change.

Section 4

Integration architecture

The integration assumes a web portal in front of an API layer through which third-party services extend the platform, which is the shape most exchange platforms take. RubySDK becomes one of those third-party services. The integration is machine to machine over JSON and HTTPS, and it does not require DataVault to change the portal, the API layer, or the exchange. The specifics of that layer are confirmed in Discovery rather than assumed here.

The calls

Events back to DataVault

Every write returns the on-chain transaction hash, so DataVault's platform can confirm state against the chain rather than trusting the API response. In addition, RubySDK posts webhooks to an endpoint DataVault nominates, signed so DataVault's API layer can verify origin:

• token.deployed with contract address and chain
• identity.registered and identity.revoked
• transfer.rejected with the compliance reason code
• redemption.period.opened and redemption.period.closed
• redemption.executed with holder identity, quantity, and reference

Where DataVault would rather poll than receive webhooks, every event has a matching read endpoint. Authentication is by signed API key over mutual TLS. Writes carry an idempotency key, so a retried call after a network timeout does not produce a second on-chain transaction.

What a first integration honestly needs

Three of these calls carry the phase one use case: deploy a token, register a holder, query eligibility. Redemption periods are not needed until the first mine is producing. A working integration against our sandbox is a small piece of work once the specification is agreed. We estimate days rather than weeks, though the effort on DataVault's side depends on the shape of their API layer and is confirmed in Discovery. The work that takes time is not the API surface. It is agreeing the compliance ruleset per asset, agreeing the claim format with DataVault's KYC provider, and testing rejection behaviour end to end.

Section 5

Security controls

The registry is the record of who owns a security. The controls over it are therefore part of the deliverable, not an operational detail settled later. This section sets out the architecture RubySDK commits to. Where a control depends on DataVault's own key management, signing arrangements, or incident process, that is stated and settled in Discovery during weeks 1 to 2 rather than specified here against an assumption about DataVault's environment.

Keys in the architecture

Separation of authority

ERC-3643 exposes these powers as distinct roles, and the deployment keeps them distinct. Registering a holder, revoking a holder, freezing an account, forcing a transfer, and pausing the token are five different authorities held by four different keys. No single key can both admit a holder to the registry and move that holder's tokens. The registrar key RubySDK operates is the narrowest of them: it writes registry entries and nothing else, so a compromise of RubySDK's key cannot move a DataVault client's asset.

Freeze and force transfer

These two powers can act on an asset the holder controls, so they are treated differently from the rest. Both sit on the token agent role, held by DataVault, not by RubySDK. Neither can be invoked through the RubySDK API, in this or any later phase: they are exercised by DataVault directly against the contract, and RubySDK does not hold the key that exercises them, so the authority and the audit sit with the party that carries the regulatory obligation. Every invocation emits an event carrying the acting address, the affected holder, the amount, and the block, which makes each use permanently attributable on chain. The authorisation process that precedes an invocation, meaning who at DataVault may request a freeze and what evidence is required, is DataVault's to define; Discovery records it so the contract roles match the policy rather than the reverse.

Audit trail and independent verification

Every state-changing call returns the on-chain transaction hash. Registry writes, claim updates, revocations, deployments, redemptions, and rejected transfers all emit events. DataVault can reconstruct the full history of the registry from the chain alone, using its existing chain-publishing infrastructure, without querying RubySDK and without trusting a RubySDK-held log. That is the point of putting the register on chain: verification does not depend on us, and a discrepancy between our API and the chain resolves in favour of the chain.

Identity data

No personal data goes on chain. KYC is performed by DataVault or its provider, and the underlying records stay there. What is written on chain is a claim: a topic identifier, the issuer's address, and the issuer's signature, attached to the holder's on-chain identity contract. It asserts that the wallet behind that identity satisfied a named verification requirement, and it carries an expiry. It contains no name, document, date of birth, address, or account reference, and it is not a hash of the personal data from which the data could be confirmed by guessing at candidates. RubySDK does not receive, store, or process DataVault's customer records at any point in the integration.

Key compromise and recovery

The mechanisms that exist today:

• Agent revocation. The owner key removes a compromised agent, including RubySDK's registrar key, in a single transaction. Registry writes from that key stop at that block, with no dependency on RubySDK acting.
• Registry integrity after compromise. Registry state is reconstructible from chain events, so entries written by a compromised key can be identified by block range and corrected by the replacement key rather than requiring redeployment.
• Holder key loss. The recovery function moves a holder's balance to a replacement wallet bound to the same on-chain identity, invoked by DataVault's token agent role.
• Pause. The owner key halts transfers on the token while an incident is assessed.
• Rotation. Agent and registrar keys are rotated on a fixed schedule and on any suspicion of compromise, by appointing the new key and revoking the old.

What is not written yet is a joint incident runbook: detection thresholds, notification times between the two organisations, named contacts on each side, and the decision to pause. We are not going to claim one exists. Producing it is a Discovery deliverable in weeks 1 to 2, written against DataVault's existing incident process rather than imposed on it, and signed off before production go-live in week 8.

Signature schemes and post-quantum migration

Two layers of signing sit in this architecture and they migrate differently. Transaction signing is a property of the chain: the registry design does not depend on which scheme sits underneath it, so a chain-level migration to a new scheme does not require the registry to be rebuilt. Claim signing sits in the application layer, inside the architecture described above: the trusted issuer signs a claim and the holder's identity contract verifies that signature on chain. That is where the migration question actually bites. The answer is that claims carry expiries and are re-signed on renewal, so the claim layer migrates through ordinary operation rather than through a rebuild, and renewal is the migration path. Key material held in dedicated key-management hardware can be regenerated under new schemes as part of scheduled rotation. RubySDK tracks post-quantum developments and will support new schemes when the chain and the issuer tooling support them, rather than deploying them now.

API surface

Authentication, transport, and replay protection for the API are described in section 4: signed API keys over mutual TLS, with idempotency keys on writes so a retried call cannot produce a second on-chain transaction. Endpoint scoping follows the key separation above, so the credential DataVault's API layer uses for registry writes cannot reach a function it does not need.

RubySDK does not hold DataVault assets in the phase 1 architecture. Any custody arrangement would be scoped separately, with the insurance certificate provided for counsel's review before any assets are held.

Section 6

Privacy and confidentiality

Phase one does not require a confidential chain. The registry, the compliance modules, and the token can be deployed on the EVM chain DataVault nominates, and that is the fastest route to a live registry inside 60 days.

Confidentiality becomes a requirement at institutional scale, when counterparties will not accept that their positions, holdings, and settlement patterns are readable by anyone with a block explorer. RubySDK's existing work on that problem carries forward from the earlier proposals:

• Oasis Sapphire is a confidential runtime that executes Solidity inside trusted execution environments. ERC-3643 deploys on it in its standard form, so the registry and the compliance modules run unchanged with contract state encrypted. Sapphire requires developers to invoke confidential execution explicitly, which is an architecture standard and an audit item rather than a technical obstacle.
• Secret Network encrypts contract state by default at the protocol level and supports native selective disclosure. It is CosmWasm-based, so ERC-3643 does not run on it natively and the contract library would require a port from Solidity.

On the evidence to date, and given that DataVault's requirement is EVM and standards-based, Oasis Sapphire is the stronger candidate for confidential deployment. The formal selection is a Discovery output, made against DataVault's asset classes, counterparty types, and jurisdictional obligations rather than against our preference.

Section 7

Phased delivery plan

Phase 1 is scoped to deliver within 60 days of signature. That is RubySDK's commitment, not an estimate. Phase 2 runs from day 60 to day 120. Phase 3 follows phase 2. The week structure below is what makes the 60 day target real rather than asserted, and it names what RubySDK delivers and what DataVault supplies at each step.

Phase 1: registry live, one mine tokenised end to end. Weeks 0 to 8.

Day 60 lands at the end of week 8. What is live at that point is the registry, contracts deployable through the API, and one mine tradable with holders recorded and enforced on chain.

Phase 2: remaining assets and production redemption. Days 60 to 120.

• The remaining assets tokenised, each with its own compliance ruleset.
• Redemption periods in production, opened as each mine begins operating.
• Deployment across any additional chains DataVault nominates, from one registry.
• Issuer operations hardened: freeze, forced transfer, and lost-key recovery procedures documented and rehearsed with DataVault's operations team.

Phase 3: confidential and institutional settlement.

• Migration of the token library to the confidential chain selected in Discovery, if DataVault elects to take it.
• Canton L1 deployment when RubySDK's Canton library lands.

Section 8

What this proposal assumes

The commitments in this proposal are RubySDK's own and hold as written. The items below are what the proposal takes as given about DataVault's side. Each is confirmed in Discovery during weeks 1 to 2, and any that turns out to be wrong is reported in writing at the end of week 2 with its effect on the schedule.

• DataVault's platform exposes an API layer through which third-party services integrate over JSON and HTTPS.
• DataVault, or its KYC provider, performs identity verification and signs the verification claims the registry trusts.
• DataVault nominates the chain for the first production deployment, from the chains it publishes to, or a chain nominated for this deployment.
• DataVault defines the compliance rules per asset: holder caps, jurisdiction restrictions, lock-ups, and holding sizes.
• Where DataVault holds existing redemption logic, it is available to us as the input specification. Where it does not, we write the module to DataVault's commercial rules.
• DataVault holds and operates the owner key and the token agent key, with the signer set agreed before the key ceremony.
• DataVault provides a test environment and sandbox credentials for its API layer.
• DataVault retains the exchange, the client relationships, the assets, the tokenomics, the metadata storage and analytics, and the chain publishing.
• The instruments are treated as securities on DataVault's own determination, which RubySDK does not advise on.

Section 9

What we need from DataVault to start

Section 10

Commercial terms

The structure is unchanged from the proposal issued on 18 May 2026: a fixed-fee first phase, a fixed price for the build quoted against a confirmed Scope of Works, and per-operation fees thereafter.

Phase 1 as scoped here is larger than the Discovery phase priced in the earlier proposals. Discovery there was a four to six week study that ended in a specification. Here it is compressed into weeks 1 to 2 and runs alongside build, so that what DataVault holds at day 60 is a live registry rather than a document describing one. The fee is unchanged.

Ongoing fees

After production deployment there are two ongoing streams: an annual technology licence for platform access, and per-operation fees collected on chain at the point of execution. DataVault pays network gas directly to the chain. RubySDK takes no share of gas and no basis-point fee on transaction value.

Metadata update, escrow creation, and escrow settlement are carried forward from the May 2026 schedule and are priced for when DataVault elects to use them.

Annual technology licence: to be agreed, covering platform access across DataVault's exchanges. Exchange launch fee: a one-off deployment fee for each additional DataVault exchange platform, to be agreed.

Section 11

Next step

This proposal is written to be handed to engineers and turned into a project without a further round of documents. The sequence that achieves that:

1. Agreement signed. Phase 1 scope as set out in section 7, at the fee in section 10.
2. Engineering kickoff within five working days of signature. DataVault's engineers and RubySDK's engineers, working directly. The commercial parties step out of the flow at that point.
3. Week 1 inputs delivered per section 9, so the week 2 specification and the phase 2 price are produced on schedule.

Everything else in this document is detail that engineering can settle between them once the agreement is in place.

RubySDK operates solely as a technology provider. RubySDK assumes no regulatory burden, licensing obligation, or compliance responsibility in connection with any DataVault AI exchange, tokenisation activity, or real-world asset transaction. All regulatory, legal, and compliance obligations remain exclusively with DataVault AI Inc. and its respective exchange entities. This proposal is confidential and is provided for the purposes of the parties' evaluation only.