Context
A tokenized-asset issuer needed access and transfer policy to remain effective when users interacted directly with the onchain program. A front end could guide users through checks, but it could not be the security boundary: another interface or composed transaction could bypass controls that existed only in an application layer.
The issuer's policy was also more than a list of approved wallets. Eligibility was supported by attestations that could expire or be revoked. Different roles were permitted to perform different actions. Some activity occurred within time-bounded sessions. Transfers, issuance, redemption, administrative actions, reporting, and exceptions did not all share the same conditions. The protocol needed a coherent enforcement model without pretending that software itself determines legal compliance.
Challenge
A single allowlist check answers a narrow question at one point in time. It does not establish why an account is eligible, whether the evidence is current, what action is allowed, how authority is delegated, or what happens when a provider is unavailable. It does not necessarily cover secondary transfers, programmatic composition, or state changes after an account first passes the gate.
Lifecycle questions made the problem harder. An attestation might be valid when a session begins and expire before a later action. A holder might remain entitled to redeem after new transfers are restricted. An operational exception might need to unblock a legitimate process without granting a general bypass. Reporting needed to explain which policy evidence governed an action without publishing sensitive personal data.
The architecture therefore had to connect external evidence with deterministic onchain checks, define the roles allowed to update policy state, and keep failure modes reviewable. It also had to remain neutral about jurisdiction-specific legal conclusions: the program could enforce configured policy, but it could not decide what the policy should be.
Approach
We separated policy inputs from protocol enforcement. Attestation providers or institutional processes could produce evidence in an agreed form. The onchain system consumed only the minimum state needed to decide whether a requested action was permitted. This reduced disclosure while making the enforcement logic deterministic.
Roles were modeled by responsibility rather than collected under one administrator. The design distinguished authority to configure accepted evidence, authority to issue or revoke protocol state, authority to pause a class of action, and authority to handle an exceptional workflow. Each role was scoped to an operation so a legitimate support function did not become a universal override.
Sessions provided a bounded way to authorize repeated activity without treating the first eligibility check as permanent. The design specified how a session was created, what it permitted, how freshness was evaluated, and how revocation or changed evidence affected later instructions. Session state did not replace policy evidence; it made the relationship between evidence and a sequence of actions explicit.
Transfer controls were applied at the program boundary. Where token extensions or hooks were relevant, the architecture treated them as enforcement points in the asset lifecycle rather than isolated features. Issuance, transfer, redemption, and administrative transitions each had their own preconditions and exception behavior. Direct program use and composed transactions were included in the threat model.
Reporting was designed from the same state transitions. The system emitted enough stable information to explain why an action succeeded or failed and which class of policy state was applied, while avoiding unnecessary personal or provider data. Exception handling was auditable: an exception had a defined scope, reason category, authority, and end condition rather than an undocumented bypass.
Policy lifecycle and failure handling
The design considered degraded dependencies. If evidence could not be refreshed, the program needed a deliberate posture rather than an accidental mix of accepted and rejected activity. Revocation, stale state, provider migration, administrative key loss, and reporting interruption were treated as lifecycle events with recovery paths.
We also documented the boundary between legal advice, policy ownership, and technical implementation. The issuer remained responsible for the rules and their legal basis. Matariki's work focused on making those approved rules representable, enforceable, observable, and changeable under controlled authority.
Outcome
The architecture connects attestations, roles, sessions, transfer enforcement, reporting, and exceptions across the full asset lifecycle. Controls cover issuance, transfer, redemption, and exceptions rather than relying on an application-layer allowlist that covers only the preferred path.
Policy decisions remain outside the protocol. Approved policy state is enforced where value moves. Exceptional and degraded conditions are explicit. The design provides reviewable evidence about enforcement without claiming jurisdiction-specific conclusions.
What this demonstrates
Compliance-aware protocol design is the translation of policy into constrained state transitions, not the addition of a wallet gate. Matariki works across policy interfaces, program architecture, authority design, privacy minimization, and operational reporting so the enforcement model remains coherent under direct use and composition.
Confidentiality
This account excludes the issuer identity, jurisdictions, eligibility rules, attestation-provider configuration, role assignments, exception procedures, and deployment details. It describes a generalized architecture and does not offer a legal conclusion.