For ICE Data Services · Private
Working demonstration · fictional records · one Hive demo key
Approved rights, delivered data and reconciled usage in one record that ICE and its customer can each check. ICE's systems stay as they are.
Where ICE already is
"Our MCP connector is built to emphasize value delivered rather than volume consumed."
Billing on value delivered means both sides need to agree what was delivered and how it was used.
ICE on LinkedIn"We now offer a complete audit trail so that every output can be traced and trusted."
ICE already keeps its own trail. The open question is what the customer can check without asking ICE.
ICE Q2 2026 earnings call"AI and analysts extract deal terms into standardized, permissioned tables."
Private credit adds documents, reviewers, identifiers and access tiers that change over the life of a deal.
ICE Private Credit IntelligenceOur answer: a record both of them signed, that either one can check without asking the other, and that a reviewer can read without seeing everything.
One use, three views
Ashgrove, a fictional fund, has an agent with delegated authority. The record links the licence version, that authority, the source version, the delivery and both sides' usage declarations. One commercial use gets one billing id. Retries, agent steps, signatures and exports don't add charges.
Loading the example records…
Each question answered on its own
There's no single "all verified" badge. A case can pass every signature check and still be open on coverage, rights or agreement.
Take it with you
The file holds the original signed records this view may see, the ones left out listed by fingerprint, and a plain summary. The customer view also carries its own private values so they can be matched to their fingerprints.
Nothing you check leaves this page. With no file chosen it checks the case you just saved.
The three views are disclosure rules we'd build and test with ICE and the firm. Fingerprints alone don't enforce them, and in this demo the views aren't access control.
From a denial to an approved purchase
ICE's entitlement system still says no. If the customer opted in and the request is eligible, ICE sales gets a demand signal with the product and a count. An approved offer, an authorized acceptance and ICE's own entitlement change follow, each on the record.
Stays a plain denial
Hive never grants access, reads the contract or lets an agent buy. It keeps the steps people approved in one place.
Opted in and eligible. A person at ICE approves the offer, a person at the customer accepts it, and ICE changes the entitlement in its own system.
Sales leads created: 1, with product and count only.
Promise, provision, bill
Corvane, a fictional insurer, accepted 25 users. Implementation turned on 30. The invoice charged 25. The record shows the gap and the open handoff that owns it. The sales tour walks a longer order end to end.
Paid per call
Circle's Arc network went live on September 16, 2026, with ICE as a founding validator. Circle's Agent Stack gives agents their own wallets with spend limits, and nanopayments for small charges. If ICE sells data to agents per call, payments will arrive faster and smaller than any invoice. Arc shows that money moved. It doesn't show what the money bought, whether it was delivered, or whether a retry was charged twice.
"ICE's institutional customers are increasingly looking for ways to operate seamlessly across traditional and digital markets. Arc's native capabilities, including predictable fees and instant finality, address real friction points these customers raised."
Michael Blaugrund, VP, Strategic Initiatives at ICE, in Circle's Arc launch release. Circle describes its agent wallets and nanopayments on the Arc site.
Here Ashgrove, a fictional fund, lets its research agent buy ICE intraday evaluations at $0.004 a pull, up to $0.10 a session. ICE signs each pull. Ashgrove's side signs each payment. Your browser checks every record and works out the bill.
Loading the example records…
The meter, pull by pull
| Pull | Time (UTC) | ICE delivery and price | Payment (illustrative Arc reference) | What the record shows |
|---|
The payment itself lives on Arc, under Circle's rules. Hive keeps its reference and amount next to the pull it paid for.
The spend limit sits in Ashgrove's agent wallet. When the wallet refuses a pull, the record shows the refusal. Hive never approves, blocks or moves money.
A double charge, a missed payment or an old price shows up as an open line. ICE and Ashgrove decide what to do about it.
Fictional records signed with one Hive demo key. The payment references are illustrative: nothing was paid, nothing touched Arc, and there is no connection to ICE or Circle. In a test, each reference would be checked against Arc itself and the firm would sign with its own key.
Correction and reliance
Notice sent, notice received, correction acknowledged and answer updated are four different records. A firm that isn't on the record shows as outside it, so nobody reads silence as receipt.
| Firm | Sent | Received | Acknowledged | Updated | Check |
|---|
Checking the correction record…
This can run as an ongoing service for participating customers. It can't see into systems that don't take part, and it can't erase answers already kept.
Private credit
ICE already runs the extraction with analysts. The passport keeps which document version backed each term, who corrected what, who was entitled to receive it, and who acknowledged the amendment. The deal and its terms are fictional. In a test, confidential terms stay out of anything public.
Questions it answers
The identifier here is illustrative, not an ICE identifier. It links document versions. It doesn't show title, ownership or that the contract is valid.
A first test uses one consenting originator or lender and one tightly scoped deal.
Full terms: a deal participant entitled to the whole record.
Suggested uses
Live Ink, Carnac and Receipts are substrates Hive has built. Packages are the fourth. Each one puts the other three together into something ICE could offer its own customers, in whatever form ICE chooses.
We drew them from what ICE has said in public. ICE knows its customers, its contracts and where the demand really is, and we don't. Treat each one as a starting point to test, reshape or drop. See how each one sits on the substrates.
What a customer might getRights, delivery, usage and invoice reconciled between ICE and a consuming firm, as one record both can check.
What would have to be true firstOne real licensed workflow, and a measured gain over ICE's existing records.
What a customer might getThe customer's own copy of the record and its own checker, with selective disclosure, offered through ICE. This is the one that would reach ICE's customers directly.
What would have to be true firstCustomer demand, distribution terms, a support owner and the firm's own keys.
What a customer might getDocument, extraction, identifier, permission and amendment history for a deal, readable at the access level each participant has.
What would have to be true firstOne consenting participant and one scoped deal.
What a customer might getAccepted terms matched to what was turned on and what was invoiced, so a billing question has one place to start.
What would have to be true firstOne real sales to implementation to finance case.
What a customer might getWho relied on a value that later changed, what notice reached them and what they did next.
What would have to be true firstA planned correction drill with a known recipient list.
What a customer might getSubmissions, confirmations, exceptions and handoffs on one record the parties can each check.
What would have to be true firstRead-only access to the authoritative records, outside any operational decision.
What a customer might getDocuments, reviewed decisions, servicing changes and handoffs between the parties to a loan.
What would have to be true firstA mortgage owner, an approved interface and limits on borrower data.
What a customer might getPortable records of the approvals, changes and exceptions that matter, outside the system that made them.
What would have to be true firstA shown improvement over existing governance and logs.
What a customer might getEach pull an agent pays for on Arc, matched to its payment, its price list and the spend limit its firm set. Double charges and missed payments show as open lines.
What would have to be true firstICE choosing to sell data to agents per call, and one firm with an agent wallet willing to test it.
A filled substrate mark means today's demonstration uses it. An outlined mark means the written profile would. Every use rests on Receipts.
Where this page stands, measured five separate ways
Runs on fictional records. Five suggested uses have one; four are written profiles.
No connection to any ICE system or feed.
One Hive demo key signs everything. Separate control comes with a test.
No review by ICE or an outside firm of this build.
No customer has set or met acceptance criteria.
Each measure moves on its own, and only with a dated record of who moved it and for what scope.
Two ways to run it
Hive records beside ICE's systems. If the witness is down, the delivery still goes out and the record marks the countersignature late or missing. See the Outage case above. If Hive stops, nothing at ICE stops.
Some teams may want nothing released until it's on the record. That puts a step in ICE's path, chosen and run by ICE, so it needs its own measured latency, availability and failure plan, and it doesn't carry the shadow promise. Hive never holds or releases ICE data. The gateway run on the AI agents page used this setting.
What the record shows, and where it stops
The shared key lets any two of ICE, the firm and Hive cosign the witness log. That keeps the log running. ICE and Hive could sign without the firm, so it can't stand for commercial agreement. A usage declaration counts as agreed only when ICE and the firm each sign it.
An authorized MCP connection says the agent could reach the data. Training, caching, passing an answer on and combining sources are licence questions. Each product needs an ICE-approved rights mapping, and unclear cases stay open on the record.
A closed window covers the systems that report into it. It can't show that no other channel was used. A dropped event shows as a gap and the window reads not complete. Try Missing event above.
A record can note that a delegation was supplied. Checking that the delegation chain is valid is a separate step, and any commercial claim that rests on delegated rights needs it.
The private aggregate licensing protocol is a research option. A working demo of it isn't a production privacy promise.
Every record here is signed with one Hive demo key, so none of it is independent. In a test the firm holds its own keys and runs its own checker.
Where each piece of data goes
| Item | Where it stays | What Hive sees | What a reviewer sees |
|---|---|---|---|
| ICE values in a delivery | On ICE's path to the customer | A fingerprint and counts | Only what ICE discloses |
| The firm's prompt, holdings and recipients | With the firm | A salted fingerprint | Only what the firm discloses |
| Licence terms | With ICE | Version and fingerprint | The version, plus terms ICE discloses |
| Times, names and counts | On the record | All of it | What the review needs |
Times and counts are information too. They can show who is active and when, so access to the record is agreed party by party. In strict gateway mode the gateway handles the full response, and that gateway is ICE's.
The first test
ICE picks one licensed workflow and one firm willing to take part. We write down today's process, who sees the record, the firm's acceptance criteria and what a paid continuation looks like. The firm runs its own keys and checker.
Normal days land on the record. ICE and the firm each declare usage, and the record reconciles them.
The hard cases on purpose: a retry, a second job, a rights change, a missing event, another channel, a witness outage, conflicting declarations, a changed statement and a correction.
The readout. ICE and the firm decide go, change or stop. The free period and any paid continuation are written down separately before day 1.
The question on day 30: can ICE and the firm settle a licensing, usage or billing question faster than they can today, and each check the answer themselves?
Talk about the first workflow
