This a working draft
- User obtains a forwarding address based on any verifiable ID (email, OAuth, SMS, etc), powered by Grindery Wallet’s smart wallet infrastructure. This can be done with authentication but is not required. User also needs a client wallet address for user identification purpose, they can either use their own wallet address, or, if user doesn’t have / doesn’t want to use their own wallet, they can choose to use forwarding address as client wallet address directly. User sends a tx to associate the new forwarding address with client wallet address so that it can only be used to fund the user.
- User can send token (USDC) to the forwarding address from any crypto wallet or use a operator (on-ramp designed specifically for Grindery protocol) or any standard on-ramp to do so.
- When tokens are received on a forwarding address, it is now ready to be deposited, user now sends another tx to deposit received fund to the Billing Ledger smart contract that works like a pre-funded escrow.
- The user can then authorize any provider wallet address to debit the user’s Billing Ledger balance. User signs an approval message which includes scope of the authorization, specifying provider wallet address, amount per charge, total chargable amount, and more. User then sends a tx to commit the signed message to the Billing Ledger smart contract to save the authorization.
- The authorized provider wallet can then debit (or bill) a user by signing a charge request (key charge data packed into bytes) and temporarily saving the signed request to a buffer. Provider should check user balance before charging and providing service to the user, otherwise the charge request will be rejected on settlement if user doesn’t have enough balance. After some time, provider submits all buffered requests in batch to Billing Ledger’s smart contract.
- Each time a batch of charge requests are submitted to the Billing Ledger smart contract, balance of users and provider will be updated to settle the charges. The smart contract verifies all charge requests to ensure that:
- They are signed by correct provider
- The charge is authorized by user
- User has enough balance to fulfill the charge
- Timestamp in the request is within past 15(?) minutes
All invalid charges requests are rejected. In the future we will allow user/provider to define custom verification condition.
Settled charges are emitted as logs for off-chain system processing and allows user to dispute (see below).
- The provider wallet can then withdraw tokens from the billing ledger to any wallet including off-ramps, exchanges and specialized operators.
Revenue
Two options:
- Charge on settlement
- Charge on withdrawal
Cache
In step 3: Cache service monitors deposit activities on forwarding address, and automatically sends deposit tx on behalf of user. This makes the process more convenient and helps user to save gas fees.
In step 5: Optionally wallet can submit the charge to a cache service which will process charge request together to reduce latency and cost, and perform balance check for convenience of provider. All charge requests are signed with provider’s private key so Cache (and any third party) can’t modify or forge it in any way.
Reputation and balance
I guess this is only a endpoint that checks the users gas tank balance as out standing charges to give provider balance, number of TX, number of disputes, total TX volume, etc? Look below at “provider specific credit”?
Joe: Agreed
Dispute
After settlement, there is a time window (2h? 24h?) when user can send a tx to request dispute to get refund for specific charges. To specify what charge to dispute, user just supply the whole provider-signed charge request (can be obtained from logs of settlement tx) in the dispute tx. The smart contract then:
- Verify that the charge request is in dispute window by timestamp included in the request
- Verify that the charge was not disputed before
- Reverse the charge
- Record the dispute event so that it can’t be disputed again.
Bill-through settlement
What happens on our “ledger” has a charge by an MCP (say $1) for a request. The assistant then resells this as $2 and keeps $1. How does this work?
Joe: Assistant can simply issue a $2 charge to user and pays $1 from its own provider wallet. After settlement the balance will be correctly updated.
Provide specific credit
Provider wallets can also credit user in the billing ledger. This means providers can collect any kind of payment or simply give users “credits” that can only be settled by the provider wallet.
Multi-token support
Can you explain how the system will work with different tokens? Like what we are planning for Grindery? What is the logic step by step? Where does it fit in above?
Joe: We currently only handle multi-token support at the point of deposit (token is credited at real-time exchange rate to USDC) and withdrawal (USDC amount is converted to requested token at real-time exchange rate)
Token Lock
Tokens deposited can not be withdrawan. This allow operators to crage fiat/cards and deposit USDC withour beeing classified as a crypto exchange
How it works V3