Open USD (OUSD): What It Actually Means for Payments

TL;DR

• On 30 June 2026, Open Standard announced Open USD (OUSD) — a dollar stablecoin backed by 140+ companies including Stripe, Visa, Mastercard, Coinbase, BlackRock and BNY, governed by a partner board rather than a single issuer.
• The headline engineering fact, not the headline business fact, is that OUSD launches natively on Solana from day one — issued as a native token on each chain, not as a bridged wrapper. Tempo and other L1s are referenced as future targets.
• For platforms that already accept USDC/USDT, adding OUSD is incremental, not architectural — if your token handling is abstracted. If you hardcoded a contract address somewhere, this is the moment you pay for it.
• The real work is in four places: token identity per chain, Solana’s account model and Token-2022 semantics, incoming-payment detection (webhooks/indexing), and cross-chain movement.
• The single biggest UX unlock — and the thing that finally makes stablecoin payments feel like fiat — is gas abstraction. Nobody wants to buy SOL just to move dollars. Paymasters and sponsored fees are no longer optional.
• The biggest enterprise blocker is on-chain transparency: if competitors all transact in OUSD on a public chain, balances and flows are visible to anyone. The answer isn’t anonymity — it’s confidential-but-compliant privacy (ZK confidential transfers with auditor/view keys). Expect this to become table stakes.

This is a builder’s-eye view of the OUSD announcement. It is deliberately not written for investors. If you run a wallet, a payments platform, a payout system, an exchange, a treasury tool, or any product that already moves stablecoins, this is the integration reality and the architecture decisions that come with it.

What Open USD actually is (the 60-second version for engineers)

Open USD is a USD-pegged stablecoin operated by Open Standard, an independent company whose board is made up of its partners. Its founding CEO is Zach Abrams, co-founder of Bridge — the stablecoin-infrastructure company Stripe acquired for $1.1 billion. That lineage matters: the people behind OUSD have already built the unglamorous plumbing (mint/redeem APIs, on/off-ramps, orchestration) that makes a stablecoin usable by a business, which is usually the part that decides whether one of these launches becomes real volume or a press release with a logo wall.

Three design principles drive it:

• Zero-fee mint and redeem, no volume caps. You move between USD and OUSD without the per-transaction mint/redeem economics that make USDC/USDT expensive at scale.
• Reserve yield flows to partners. The interest earned on the T-bill reserves backing OUSD is distributed to the businesses that adopt and distribute it, minus a management fee — instead of being kept by the issuer. This is the same incentive design Paxos pioneered with USDG / the Global Dollar Network, now assembled at a much larger scale.
• Consortium governance. No single company controls the roadmap. For developers, the relevant promise here is “you have recourse if the roadmap doesn’t serve you” — though whether a 140-member board moves faster or slower than a single issuer is an open question you should price into your planning.

The market reacted exactly how you’d expect a structural threat to land: Circle’s stock fell roughly 12–13% on the day. USDC (~$70B) and USDT (north of $145B) remain far larger, and notably neither Circle nor Tether is in the consortium. OUSD goes live later in 2026.

That’s the business context. Now the part that’s actually our job.

Why “natively on Solana from day one” is the most important sentence in the announcement

Most coverage treated the chain choice as a footnote. It’s the opposite — it’s the design decision that determines how hard your integration is and how safe the asset is to hold.

Native issuance vs. bridged wrappers. A stablecoin can exist on a chain in two very different ways:

1. Natively — the issuer mints the canonical token directly on that chain. The token on Solana is OUSD, fully reserved and redeemable, with the issuer’s mint authority behind it.
2. As a bridged wrapper — someone locks the real token on Chain A and mints an IOU representation on Chain B. That wrapper is only as trustworthy as the bridge that backs it.

OUSD is taking route 1 on Solana. This is the right call, and it has direct consequences for you:

• The OUSD you receive on Solana is the real, redeemable asset — not a wrapper whose peg depends on a bridge’s solvency.
• You integrate against a mint address (Solana’s equivalent of a token contract), not a wrapped-token contract from a third party.
• When OUSD expands to additional chains, the safe pattern is native issuance on each chain plus a canonical cross-chain mechanism (more on that below), not a sprawl of incompatible wrapped versions.

If you remember one thing: do not integrate bridged or “wrapped” OUSD as if it were the canonical asset. This is the same mistake that has burned teams with bridged USDC — wrong mint address, no issuer redemption, silent de-peg risk. Verify the canonical mint from Open Standard’s own documentation at launch and pin it.

What it actually takes to add OUSD to an existing platform

Here’s the honest checklist. If you support USDC on Solana today, you are most of the way there. If you only support EVM ERC-20 stablecoins, Solana introduces a handful of genuinely different concepts you have to handle.

1. Token identity is per-chain, and it’s not a “contract address”

On EVM chains, a stablecoin is an ERC-20 contract at a hex address (0x…). On Solana, a token is defined by a mint account identified by a base58 address, and balances live in token accounts, not in the mint itself.

Concrete tasks:

• Add the OUSD mint address as a first-class asset in your config, per chain. Treat “OUSD on Solana” and “OUSD on Chain X” as the same logical asset, different on-chain identity — and design your data model around that from the start.
• Address validation differs. EVM addresses are 20-byte hex with an EIP-55 checksum. Solana addresses are 32-byte base58 ed25519 public keys with no checksum casing. If your input validation, your “is this a valid address” regex, or your address book assumes 0x…, it will reject every Solana address. This is the most common day-one bug.
• Decimals. EVM stablecoins are frequently 18 decimals; SPL stablecoins on Solana (USDC, USDT) are 6 decimals. OUSD’s decimal precision should be confirmed at launch, but assume 6 on Solana. If any part of your code assumes 18-decimal wei-style math, your amounts will be off by 10¹² — a catastrophic, silent rounding/parsing class of bug. Use integer base-units everywhere and centralize decimal handling.

2. Solana’s account model will surprise an EVM-only team

This is where most of the “new work” actually lives.

• Associated Token Accounts (ATAs). A wallet can’t just “have a balance.” To hold OUSD, a wallet needs an associated token account for that specific mint. Sending OUSD to an address whose ATA doesn’t exist yet means you (or a relayer) typically create it as part of the transfer.
• Rent / account activation. Creating that token account requires a small, one-time rent-exempt deposit (on the order of ~0.002 SOL). This is the subtle trap: a brand-new user who has never touched Solana cannot receive OUSD without a tiny amount of SOL existing somewhere to open their account. Plan for sponsoring this — it connects directly to gas abstraction below.
• Idempotent ATA creation. Use the “create idempotent” path so concurrent payouts don’t race each other into “account already exists” failures. This is a real production concern for payout platforms doing fan-out.

3. Token-2022 (Token Extensions): confirm which token program OUSD uses

Solana has two token programs: the classic SPL Token program (what USDC/USDT use today) and Token-2022 / Token Extensions (what PayPal’s PYUSD uses on Solana). A compliance-oriented institutional stablecoin like OUSD may well choose Token-2022 for features such as confidential transfers, transfer hooks, interest-bearing balances, and a permanent delegate for freeze/clawback.

Why you must check this before writing a line of code: the two programs have different program IDs, and ATAs derive differently. Code, indexers, wallets, and explorers that assume classic SPL Token will silently fail to see or handle Token-2022 balances. If OUSD ships on Token-2022:

• Confirm your wallet/library versions support Token Extensions.
• Account for transfer hooks — a transfer can invoke additional program logic, which changes your compute-budget and failure-mode assumptions.
• Account for a permanent delegate / freeze authority — the issuer can freeze or claw back tokens for compliance. Your treasury and risk models need to know this is possible; it’s a feature for regulated money, not a bug, but it’s not how “trustless” ERC-20 behaves.

Treat “which token program?” as a launch-blocking question to answer from Open Standard’s docs — not an assumption.

4. Detecting incoming payments: webhooks and indexing differ from EVM

You asked specifically about parsing webhooks for incoming payments. This is one of the biggest mental-model shifts from EVM:

• On EVM, you detect an incoming stablecoin payment by watching for the ERC-20 Transfer(from, to, value) event log filtered by the token contract and the recipient. Logs are the source of truth.
• On Solana, there are no EVM-style logs to filter the same way. You detect token movement by inspecting a transaction’s pre- and post-token-balances for the relevant token account, and/or by parsing the instructions (Transfer / TransferChecked on the token program). Your indexer watches the recipient’s token account, not the wallet address directly.

Practical implications for your webhook/ingestion layer:

• Subscribe at the token-account level. Map each user/merchant to their OUSD ATA and watch that. (For platforms that pre-derive ATAs, you can compute them deterministically from owner + mint.)
• Confirmation depth. Solana exposes processed → confirmed → finalized commitment levels. For crediting real money, key off finalized (or confirmed with your own risk tolerance and reorg handling). Don’t credit a balance on processed.
• Idempotency by signature. Use the transaction signature as the idempotency key so a webhook replay can’t double-credit. This is the Solana analog of de-duping on txHash + logIndex.
• Amount + mint verification. Always verify the transfer was the OUSD mint and the exact base-unit amount to the exact ATA — TransferChecked carries the mint and decimals, which is precisely why you should prefer it. Never trust a memo or an off-chain hint alone.
• Memos for reconciliation. Solana’s memo program is commonly used to attach an invoice/order ID to a payment. Build memo parsing into your reconciliation, but treat it as untrusted metadata, not authorization.

5. Mint / redeem and the reconciliation problem

Zero-fee mint and redeem is a genuine advantage, but it’s an API integration, not free magic. You’ll integrate Open Standard’s (or a partner’s) mint/redeem and on/off-ramp APIs, handle KYC/business-onboarding flows, and reconcile fiat settlement against on-chain mints.

The harder, quieter problem is multi-chain reconciliation: the same logical OUSD lives on multiple chains under different addresses. Your ledger must treat them as one asset for accounting while tracking them as distinct on-chain positions for settlement. Get this data model right at the start; retrofitting “the same dollar in two places” into a single-chain ledger later is painful.

The multi-chain problem: bridges, or something better?

You’re right that for a currency meant to be global, cross-chain movement is central. But “add a bridge” is the wrong instinct, and it’s worth being precise about why.

Third-party lock-and-mint bridges fragment a global currency. If OUSD on Chain B is just a wrapper minted by a bridge that locked OUSD on Chain A, you now have:

• Liquidity fragmentation — wrapped OUSD and native OUSD are not fungible without the bridge in the loop.
• De-peg surface area — the wrapper’s value depends on the bridge’s solvency and security, not on Open Standard’s reserves.
• The single largest exploit category in crypto history. Bridges have been the most-attacked piece of infrastructure in the space. You do not want your “stable” dollar’s peg riding on that.

The correct pattern is native issuance per chain + canonical burn-and-mint. This is the model Circle uses with CCTP for USDC: to move from Chain A to Chain B, the protocol burns the canonical token on A and mints the canonical token on B, with the issuer (or an issuer-sanctioned messaging layer) attesting the transfer. There is no wrapped IOU; the asset you hold on every chain is always the real, redeemable token.

For OUSD, watch for Open Standard to ship (or bless) exactly this kind of canonical cross-chain transfer mechanism as it expands beyond Solana. Build your cross-chain feature against that, not against a generic bridge aggregator. If you must support routing today, prefer routes that settle into native OUSD and make the “native vs. wrapped” distinction explicit in your UI and your risk checks.

Chains will compete on speed and fees — but don’t optimize yourself into a corner

You’re also right that users and businesses gravitate to whichever chain is fastest and cheapest. Solana being the day-one chain is partly a bet on exactly that: ~400ms settlement and sub-cent fees. Expect stablecoin-optimized chains — Plasma (already named in the launch as instant-settlement infrastructure, with a protocol-level paymaster) and Tempo — to compete hard for OUSD volume on cost.

The nuance worth putting in front of clients: gas is not the only cost that matters. The cheapest chain is worthless if:

• your counterparties and liquidity aren’t there (a cheap transfer to a chain with no off-ramp is a dead end),
• the redemption rail (fiat off-ramp) isn’t supported on that chain, or
• you fragment your own treasury across five chains chasing fees and drown in reconciliation and rebalancing overhead.

The right architecture is chain-agnostic at the asset layer with a deliberate, small set of supported chains — chosen for liquidity and redemption depth first, gas second.

The gas problem — and why this is where stablecoin payments finally feel like fiat

This is the most important section, and it’s the point you flagged that most teams underweight.

The fiat analogy is exactly right. When you send someone $50 over an ACH or card rail, you don’t first go buy a separate “network fuel” asset. The fee (if any) comes out of the dollars themselves. Crypto broke this: to move a dollar-denominated token, you historically needed a second asset — SOL, ETH, MATIC — purely to pay gas. That is an absurd onboarding requirement for a payments product. No normal user or business wants to acquire and manage SOL just to move dollars. It is the single biggest reason “stablecoin payments” have felt like crypto rather than payments.

Gas abstraction is the fix, and it has matured to the point where you can hide the base asset entirely:

• On EVM (ERC-4337 / smart accounts): a paymaster sponsors the gas. The user signs a transfer of OUSD; the paymaster pays the network fee — either subsidized by you, or deducted in OUSD itself at quote time. The user never touches ETH.
• On Solana: the fee payer of a transaction does not have to be the sender. A relayer service can pay the SOL fee on the user’s behalf while the user only moves OUSD. With Token-2022, fee/transfer semantics make “pay for the movement in the token being moved” increasingly clean. The same relayer can also fund the rent for a new recipient’s token account, which solves the “new user can’t even receive without SOL” problem from earlier.
• The precedent already exists in production: Plasma runs a protocol-level paymaster that sponsors gas for stablecoin transfers, enabling zero-fee USDT sends with no separate gas token. This is the template the whole space is converging on, and it’s a strong hint about how OUSD-optimized chains will behave.

The architecture this points to: a smart wallet auto-connected to a paymaster/relayer, where the user holds and pays in OUSD only, and the base-layer gas is sponsored or silently settled in OUSD behind the scenes. That’s the design that makes a stablecoin transfer indistinguishable from a fiat payment from the user’s perspective — which is the entire point of the OUSD pitch (“money movement,” not “crypto”).

If you build OUSD support and don’t solve gas abstraction, you’ve shipped a crypto feature. If you do, you’ve shipped a payments feature. That distinction is the whole game.

The privacy problem nobody on the logo wall is talking about

Here’s a question that gets sharper the more successful OUSD becomes: if Visa, Mastercard, Amex, and a hundred other competitors all settle in the same token on the same public chain, who is comfortable broadcasting their balances and payment flows to their rivals?

This is the part the announcement is quiet about, and it’s arguably the hardest unsolved problem for enterprise stablecoin adoption. A public ledger is a feature for auditors and a liability for businesses. On a transparent chain like Solana, anyone with a block explorer and some patience can extract:

• Balances at any known address — your float, your treasury, your runway.
• The transaction graph — who you pay, who pays you, your suppliers, your payroll cadence, your customer concentration.
• Volumes and margins — if a competitor can see both sides of a flow, they can infer pricing and unit economics.

For a consumer this is a privacy concern. For an enterprise moving real money against competitors on a shared rail, it’s a commercial-intelligence leak that can be a hard blocker to adoption. “We’d love to move our settlement onto OUSD, but we’re not going to let the entire industry watch our books in real time” is a sentence that kills deals.

The key distinction: confidential, not anonymous

The naive answer — full anonymity, mixers, untraceable transfers — is a regulatory non-starter. A consortium-governed, fully-reserved, compliance-focused stablecoin cannot ship Tornado-Cash-style opacity; AML, sanctions screening, and the GENIUS Act framework all require that flows remain auditable. Mixers have been sanctioned precisely because they break that.

So the design target isn’t anonymity. It’s confidentiality with selective disclosure: hide the numbers from the public and from competitors, while still letting the issuer, auditors, and regulators see exactly what they’re legally entitled to see. This is the only version of privacy that a regulated stablecoin can actually adopt — and, conveniently, it’s also exactly what the relevant technology now supports.

How it actually works on Solana (Token-2022 Confidential Transfers)

Because OUSD is Solana-native and may well ship on Token-2022, the most relevant primitive is already in the standard: the Confidential Transfer extension. Instead of moving assets to a separate privacy network, the token itself carries encrypted state. The mechanics:

• Twisted ElGamal encryption hides the amount and the account balance. Publicly, a confidential balance reads as zero / opaque ciphertext; the real value lives in encrypted state.
• Zero-knowledge proofs (Bulletproofs range proofs plus sigma proofs for validity, equality, and zero) let the runtime verify a transfer is legitimate — no secret minting, no negative balances, amounts in range — without ever revealing the number.
• An optional auditor key baked into the mint. When the issuer sets a global auditor ElGamal public key on the mint, every confidential transfer must additionally encrypt its amount under that key. The auditor (issuer/regulator) can decrypt everything for compliance; the public and your competitors see nothing. That single mechanism is what makes this “confidential but compliant.”

This is the cleanest answer to your point: competitors can’t read your balances or amounts, but Open Standard and regulators retain a cryptographic view key. Privacy from rivals, transparency for auditors.

The honest limitation: confidential ≠ fully private

This is the nuance most write-ups miss, and it matters for architecture: Token-2022 confidential transfers hide the amount, not the counterparties. A confidential transfer instruction still names the sender and receiver accounts on-chain — it just encrypts how much moved between them. So a determined competitor can still map that you transact with a given party and how often, even if they can’t see how much.

Hiding the transaction graph itself (who-pays-whom) is a separate, heavier problem that needs additional tooling:

• Stealth addresses (e.g., the ERC-5564 pattern on EVM) generate a fresh one-time address per payment so flows can’t be trivially linked to a single public identity.
• Shielded pools / ZK privacy layers (Aztec-style on EVM, shielded-pool designs generally) break linkability by pooling and re-proving, at the cost of complexity and composability.
• MPC / confidential-compute layers keep both data and computation encrypted for richer private workflows.
• Plasma, already named in the OUSD launch as settlement infrastructure, explicitly markets confidential but compliant transactions — a signal that the OUSD-adjacent chains are designing for exactly this tension.

A realistic enterprise stack therefore layers these: confidential transfers to hide amounts, plus stealth-address or shielded patterns where the relationship also needs hiding, plus auditor/view keys for compliance throughout.

What confidential balances do to your integration (this is the part that bites)

If OUSD enables confidential transfers, several things you built in the earlier sections change materially:

• You can’t just read a balance. Public balance shows zero; the real value is an encrypted ciphertext you must decrypt client-side with the account’s ElGamal key. There is no clean “get balance” — you fetch state and decrypt locally.
• Your incoming-payment webhook breaks. Remember the payment-detection section — on a confidential transfer, the amount is encrypted, so pre/post balance deltas and instruction data won’t hand you a plaintext number. You reconcile incoming payments by decrypting with the auditor/view key (if you hold it) or by having the payer share a proof/disclosure. Design your ingestion around encrypted amounts from the start, or it will silently fail to credit.
• More instructions, more latency. A confidential flow is multi-step — configure account, deposit, apply pending balance, transfer (with proof-context accounts), withdraw — and ZK proof generation adds client-side compute and latency. Plan for it in your UX and your throughput math. (Confidential transfer amounts are also capped at 48-bit and split into hi/lo components — a real encoding constraint.)
• Key management becomes a first-class risk. Lose the ElGamal key and the confidential balance is unrecoverable. You now own an encryption-key lifecycle — generation, backup, rotation, recovery — on top of the normal signing key. This is a product and security workstream, not a checkbox.
• Wallet, indexer, and explorer support is uneven. The same Token-2022 caveat from before, intensified: many tools can’t render or even detect confidential state. Validate your entire stack end-to-end before promising clients private balances.

The takeaway for builders: privacy is not a toggle you flip at the end. If commercial confidentiality is going to matter for OUSD — and for enterprise adoption it will — your balance reads, your payment detection, your reconciliation, and your key management all have to be designed for encrypted state up front. Retrofitting confidentiality onto a plaintext-balance integration is a rewrite, not a patch.

If you already have a project: how much work is this, really?

A pragmatic migration read for teams with existing systems:

• You already support USDC/USDT on Solana: OUSD is largely “add another mint, confirm the token program, point your indexer at the new ATAs.” Days, not months — assuming you didn’t hardcode anything.
• You support EVM stablecoins only: budget for a real Solana integration (account model, ATAs, instruction/balance-based payment detection, commitment levels). This is the bulk of the lift. The good news: it’s a one-time investment that also future-proofs you for the broader Solana stablecoin economy.
• You hardcoded a token contract address anywhere: treat this launch as the forcing function to abstract the asset. Put a PaymentAsset interface in front of everything — mint/contract, decimals, chain, token program, transfer + balance-detection strategy, mint/redeem rail — and make OUSD just one configured instance behind it. You’ll add the next stablecoin in an afternoon instead of a sprint.
• Compliance posture: because OUSD may carry a freeze/clawback authority, document for your own risk and legal teams that held balances can, in principle, be frozen by the issuer for compliance reasons. This is normal for regulated money but should be an explicit, recorded assumption — not a surprise.

OUSD vs. the incumbents: a developer-oriented comparison

(Figures are approximate and move; verify at integration time. OUSD specifics — token program, decimals, exact cross-chain mechanism — should be confirmed from Open Standard’s launch documentation.)

A realistic OUSD integration checklist

1. Pin the canonical OUSD mint address per chain from official docs. Reject everything else.
2. Confirm the token program (classic SPL vs. Token-2022) and update libraries/indexers accordingly.
3. Confirm decimals; centralize all amount math in integer base-units.
4. Fix address validation to accept base58 Solana addresses, not just 0x hex.
5. Implement ATA handling — idempotent creation, rent sponsorship for new recipients.
6. Rebuild payment detection on pre/post token balances + TransferChecked instruction parsing, keyed on the recipient ATA.
7. Set commitment to finalized for crediting; de-dupe on transaction signature.
8. Integrate mint/redeem + on/off-ramp APIs; build multi-chain-aware reconciliation.
9. Add gas abstraction (paymaster on EVM, fee-payer/relayer on Solana) so users never need the base asset.
10. Plan cross-chain around canonical burn-and-mint, never generic wrapped bridges.
11. Decide your confidentiality stance early. If competitive privacy matters, design balance reads, payment detection, reconciliation, and key management around encrypted state (confidential transfers + auditor/view key) from day one — it’s a rewrite to add later.
12. Document the freeze/clawback authority assumption for risk and legal.
13. Abstract the asset behind a payment interface so the next stablecoin is trivial.

FAQ

What is Open USD (OUSD)? A US-dollar stablecoin announced on 30 June 2026 by Open Standard, a partner-governed independent company backed by 140+ firms including Stripe, Visa, Mastercard, Coinbase, BlackRock and BNY. It offers zero-fee mint/redeem, no volume caps, and shares reserve yield with partner businesses.

Which blockchain does OUSD launch on? OUSD launches natively on Solana from day one, per Solana’s own announcement. Additional layer-1s such as Tempo are referenced as future targets, and Plasma is named as instant-settlement infrastructure.

How hard is it to add OUSD to a platform that already supports USDC? If you already handle USDC on Solana, it’s largely incremental — add the mint, confirm the token program, and point your indexer at the new token accounts. EVM-only teams should budget for a full Solana integration.

Do I need SOL to use OUSD? Technically the network charges fees in SOL, but with gas abstraction (paymasters on EVM, fee-payer/relayer on Solana) end users can transact in OUSD only and never hold SOL. Designing for this is strongly recommended.

Should I use a bridge to support OUSD on other chains? Prefer native issuance plus canonical burn-and-mint cross-chain transfers over third-party lock-and-mint bridges. Bridged wrappers fragment liquidity and add de-peg and security risk.

Can OUSD transactions be private if competitors use the same chain? Yes, with confidential-but-compliant privacy rather than anonymity. Solana’s Token-2022 Confidential Transfer extension uses ElGamal encryption and zero-knowledge proofs to hide amounts and balances from the public while an optional auditor key lets the issuer and regulators decrypt for compliance. Note it hides amounts, not the sender/receiver — hiding the transaction graph needs additional tooling like stealth addresses or shielded pools.

Is OUSD live yet? No. As of mid-2026 it is announced and expected to go live later in 2026. Confirm token program, decimals, and cross-chain mechanics from Open Standard’s official documentation at launch.

How Simplileap thinks about this

We build and integrate blockchain payment systems, so we read this announcement as an engineering roadmap, not a headline. The pattern is clear: stablecoins are converging on native multi-chain issuance, canonical cross-chain transfers, and fully abstracted gas — the three things that turn “crypto rails” into “payment rails.” OUSD’s day-one Solana decision and consortium economics are a strong signal that this is where serious money movement is heading.

If you’re evaluating whether and how to add OUSD — or you want your existing USDC/USDT integration refactored into a clean, chain-agnostic payment layer with gas abstraction built in — that’s exactly the kind of work we do. The teams that abstract the asset and solve gas now will add every future stablecoin in an afternoon. The ones that hardcode will keep paying for it, one launch at a time.