No-custody Card Program on Polygon’s Open Money Stack: Design Partner Slots Open

tl;dr

• Place a hold on stablecoin funds in any non-custodial wallet, then settle or refund, the same two-step flow card rails have run for forty years
• Works on any EVM chain: Ethereum, Polygon, Base, Arbitrum, and more
• Supports any ERC-20 (USDC, USDT, PYUSD, USDe) with no new token standard and no issuer integration project
• Non-custodial by design: Funds go to a permissionless contract and are held there during the hold period, locked by a contract with no admin access, so the issuer never takes custody
• Expired holds release permissionlessly: once the hold expires, funds can return to the user with no issuer involvement and no support tickets
• Working-in-progress primitives in functional prototype, not finalized product. Coming soon to our wallets product

Every card transaction in the world runs on a two-step flow. Authorize a hold, then capture later for the actual amount. Hold $200 at a hotel, settle $187. Hold $50 at a gas pump, settle $38. Every piece of merchant tooling, fraud logic, dispute handling, and accounting built in the last forty years assumes this model. It is the spine of how cards work, and it is not optional.

Stablecoins broke it. Transfers are atomic: money moves or it doesn't. There is no way to hold $200 now and settle $187 on Thursday, no window for fraud checks, no variable capture, and no auto-expiry. For a card issuer evaluating stablecoin rails, this is the dealbreaker. Not speed, not cost, but the absence of the one primitive their entire stack is built around.

Polygon Wallets is building hold and settle as a wallet-layer primitive. A requester can place holds on any wallet, then settle for the full amount, a partial amount, or let the hold expire and be returned to the user. The funds sit in a smart contract with no admin key, no withdrawal path, and only two ways out: settlement by an active operator, or permissionless release after expiry.

The prototype is fully functional, but the production version is still being shaped. What we need now are the production edge cases that only come from running a live card program, and design partners to help us get there.

Run a card program on stablecoin rails. No custody. Any chain.

How it works

A merchant, card issuer, or platform registers onchain as a Requester with metadata that identifies their business. The Requester's operators can then place holds on user wallets. The user grants spending authority by approving the Requester's onchain inbox, typically through a smart session that scopes the allowance by token, amount, and time, or through a one-time approval for ad-hoc holds. Once authorization is in place, operators can create and settle holds without further per-transaction user friction.

When a hold is placed, the specified amount of any ERC-20 token locks in a hold contract. The user's wallet shows the hold separately from their available balance, along with metadata on who placed it and why.

Settlement happens when the Requester captures. They can settle the full amount, a partial amount, or let the hold expire. Once a hold is expired, anyone can call release and return the funds to the user. No issuer action needed, no manual release, no support tickets.

The contract has no admin access, and no one can extract funds except through settlement or expiry: two exits, both deterministic.

One wallet integration covers any EVM chain your customers already use and any ERC-20 stablecoin they already hold.

Why the wallet is the right layer

A chain-level hold mechanism works on exactly one chain. Tempo built key_authorization into their protocol, so if you want hold and settle, you run on Tempo. If you run on Tempo, you run on Stripe's chain and you adopt their fee structure, their custody assumptions, and their stablecoin standard. The feature is real, but the lock-in that comes with it is also real.

A wallet-level hold and settle does not impose any of that. The same primitive runs on every EVM chain Polygon Wallets supports, and the chain decision stays yours.

Three things your product teams will notice on day one.

Non-custodial is the strategic edge. The hold contract has no admin access and no withdrawal path. Funds sit in the contract under a receipt NFT held by the user, and the issuer never takes custody at any point in the flow. The hold contract has no admin key and two deterministic exits, with the user holding the receipt NFT..

Any ERC-20 on day one. Your users already hold USDC, USDT, PYUSD, and USDe, and all of them work with holds out of the box. There is no issuer integration project, no new token standard, and no six-month rollout that you are not running.

Better UX than card pre-auths. Users can see exactly who placed the hold, how much is locked, and when it expires. The moment a hold expires, there can be a trigger to release in one transaction. Try doing any of that with a Visa pre-auth. You will be on hold with your bank for twenty minutes just to find out the hold exists.

Who this is built for

Card issuers going stablecoin-native. The card program runs on auth/capture, and without holds, you cannot issue a card against a stablecoin balance. With holds at the wallet layer, you can, on the chain you already settle on rather than the one that shipped the feature first.

Crypto exchanges with card products. Every exchange card program today runs auth/capture through a traditional processor. Holds at the wallet layer let the exchange run the same flow natively on stablecoin rails, without a card network intermediary taking margin on every swipe.

Neobanks and fintech card programs. Consumer-facing card products backed by stablecoin balances get per-user hold visibility and non-custodial architecture on any EVM chain. The user sees the hold in their wallet app, and the product is designed for the fintech to avoid certain custody risks.

Gig platforms and marketplaces. Hold funds when a ride starts and settle when it ends. Hold funds when a freelancer accepts a job and settle on delivery. Variable settlement amounts with automatic expiry and an onchain audit trail, all in one primitive that handles escrow, holds, and settlement together.

Design partner program is open

The hold-and-settle contracts are a functional prototype, not a finalized product. These are working-in-progress primitives, and we want to build the production version with the teams that will use it.

We are looking for design partners who are building card programs on stablecoin rails, operating exchange card products and want to move auth/capture onchain, or running marketplaces or gig platforms that need escrow and hold mechanics.

If your team is building any of the above and you want to shape how hold-and-settle works before it ships as product, we want to hear from you.

Apply for the design partner program →

Disclaimer

This post is for general informational purposes only and does not constitute legal, financial, tax, regulatory, or investment advice. Nothing contained herein should be construed as a solicitation, offer, or recommendation to buy, sell, or engage with any product or service, nor should it be relied upon as the basis for any decision.

‍Users and institutions are solely responsible for ensuring that their access to and use of any Polygon product or service complies with all applicable laws, rules, and regulations in their respective jurisdictions. Polygon Labs makes no representation or warranty that any particular program configuration, feature, or use case will satisfy the legal or regulatory requirements of any specific jurisdiction. Users and institutions are strongly encouraged to seek independent legal counsel regarding their specific compliance obligations before engaging with any Polygon product or service.

The features, use cases, and illustrative examples described in this post are subject to applicable law and may not be available in all jurisdictions. All statements regarding future products, features, functionalities, or capabilities are forward-looking in nature and subject to change without notice. Such statements should not be relied upon as representations of future performance or availability.

Polygon Labs reserves the right, in its sole discretion and without prior notice, to modify, suspend, limit, restrict, or discontinue the program or any component of the Open Money Stack (“OMS”), in whole or in part, at any time. Use of OMS is subject to OMS terms and conditions. Polygon Labs further reserves the right to restrict or terminate access to any code, feature, or support for any user or in any jurisdiction where required by applicable legal or regulatory obligations.

Blockchain technology, smart contracts, and decentralized protocols involve inherent and significant risks, including but not limited to technical vulnerabilities, regulatory uncertainty, and potential loss of funds. To the fullest extent permitted by applicable law, Polygon Labs shall not be liable for any damage of any kind arising from or in connection with the use of, or reliance upon, the program, the Open Money Stack, or any information contained in this post.