Services
Which parts are UGTP's own, which are third-party, and what each one owns in an operation.
Built and run by UGTP
Our own services
These are ours end to end: we deploy them, we operate them, and an incident in one is ours to fix.
UGTP service
UGTP Engine
Build, sign for, submit, and track an operation on whichever rail carries it, behind the public gateway transaction API.
Lifecycle stage
Preparation, submission, broadcast, and lifecycle tracking
Trust boundary
The gateway passes validated operation intent into UGTP execution services; the account's signature is produced client-side and never leaves the client unsigned.
Inputs
- Owner account
- Calls or typed actions
- The client's signature or signed transaction
Outputs
- An unsigned UserOperation, an EIP-712 request, or an unsigned transaction
- The operation identifier
- Lifecycle status, transaction hash, and replacement count
Plan for
- Deterministic simulation revert
- The prepared operation expires before submit
- A duplicate operation for the same signed payload
- A previous operation for the same account is still in flight
Operational ownership
UGTP operates the Engine boundary exposed through the public transaction, account, and fee APIs.
Approved source
Repository evidence: ugtp-gateway src/services/operation-rail.service.ts and src/services/user-operation.service.ts on origin/develop; the accounts and transactions groups in src/content/endpoints.ts.
UGTP service
UGTP Paymaster
Sponsor gas for an operation on the UserOperation rail and collect the UGTP fee from the transferred asset.
Lifecycle stage
Fee estimation and UserOperation execution
Trust boundary
The operation relies on UGTP fee policy, priced before it is signed and enforced on-chain when it executes.
Inputs
- The UserOperation
- The network
- The transferred assets or the named fee token
Outputs
- Gasless execution
- The worst-case and expected fee in the fee token
Plan for
- The requested fee token is not supported on the network
- The fee estimate is unavailable
- The transfer leaves less behind than the fee it must pay
Operational ownership
UGTP operates fee policy and the Paymaster boundary exposed by public fee and operation responses.
Approved source
Repository evidence: ugtp-engine contracts/contracts/UgtpPaymasterV1.sol and api/src/features/fee/fee.service.ts on origin/develop; ugtp-gateway src/constants/ugtp-fee.ts; the fees and transactions groups in src/content/endpoints.ts.
UGTP service
Avalanche executor
Execute an account-signed EIP-712 request on Avalanche C-Chain, where there is no chain-level EIP-7702 to delegate to.
Lifecycle stage
Allowance setup, request preparation, and relayed execution
Trust boundary
The account authorizes one specific request; UGTP countersigns its fee terms and relays it, and the contract refuses anything the account did not sign.
Inputs
- The account's EIP-712 signature over the returned request
- A one-time ERC-20 allowance
- The fee terms the request carries
Outputs
- Relayed gasless execution
- The fee collected in the ERC-20 fee token
Plan for
- The account has granted no allowance for the token yet
- The named fee token is not registered on the rail
- The signed fee terms expire before the request is relayed
- The native coin is requested, which this rail cannot move
Operational ownership
UGTP operates the executor contract, its relayer set, and the fee terms it countersigns.
Approved source
Repository evidence: ugtp-engine contracts/contracts/UGTPAvalancheExecutor.sol and contracts/deployments/43114-latest.json on origin/develop; ugtp-gateway src/constants/executor-rail-networks.ts and src/services/executor-fee-terms.service.ts.
Third-party, plugged in
Services we plug in
Someone else's software or contracts, reached through our API. We choose them, price against them and handle their failures — but we do not control their behaviour, which is why each profile names its trust boundary.
Third-party
LI.FI routing
Provide route discovery and execution data for UGTP same-chain swaps and cross-chain swaps and sends.
Lifecycle stage
Swap and send quoting, route preparation, and routed transfer tracking
Trust boundary
Routing data crosses from the UGTP gateway to an external routing provider before the operation is signed or executed.
Inputs
- Source and destination network
- Input and output token
- Amount and slippage
Outputs
- Quote and route
- Execution calldata
- Routed transfer progress
Plan for
- No serviceable route for the corridor
- Route simulation rejects the amount as below a bridge or DEX minimum
- The route moves between quote and prepare
- The bridged transfer reaches a failed terminal state
Operational ownership
LI.FI operates the external routing provider; UGTP owns the gateway integration and the user-facing API contract.
Approved source
Repository evidence: ugtp-gateway src/services/swap.service.ts, src/services/send.service.ts and src/services/plain-swap.service.ts on origin/develop; the swap and send groups in src/content/endpoints.ts; LI.FI official documentation.
Official provider documentation ↗Third-party
Private tokens
Wrap a supported public token into its encrypted form, move it with a hidden amount, and unwrap it back. The encrypted-token contracts are third-party: AvaCloud's Encrypted ERC-20 (eERC), upstream ava-labs/EncryptedERC. UGTP deploys them on Avalanche C-Chain, relays the operations and prices them.
Lifecycle stage
Registration, deposit, private transfer, and withdraw
Trust boundary
The client builds the encrypted-token calldata and its proof; UGTP relays it and prices the operation in the public underlying without receiving a private transfer's amount.
Inputs
- The private token symbol from the token list
- Client-built encrypted-token calldata
- The public underlying amount, for a deposit or withdraw only
Outputs
- A prepared operation on the executor rail
- The product fee, charged in the public underlying
- The cost quote a client can gate a Send button on
Plan for
- The account is not registered yet, which is a one-time prerequisite
- The account holds the private token but not enough of the public underlying to pay
- An amount is supplied for a private transfer, which is refused
- The symbol names no active private token on the network
Operational ownership
UGTP operates the relaying rail and the product fee; the encrypted-token contracts are on-chain and the client owns its own proofs and viewing keys.
Approved source
Repository evidence: ugtp-gateway src/routes/private.routes.ts, src/controllers/private.controller.ts, src/constants/private-tokens.ts, src/schemas/private-operation.validation-schema.ts and src/enums/operation-kind.ts on origin/develop; the private group in src/content/endpoints.ts; the vendored ava-labs/EncryptedERC contracts and AvaCloud's own documentation.
Official provider documentation ↗Third-party
EntryPoint and account delegate
Execute user operations on chain, and provide the code an EIP-7702 account adopts. Both are canonical eth-infinitism v0.9 artifacts at the same address on every network that carries the UserOperation rail; UGTP deploys neither.
Lifecycle stage
Account activation, and execution of every UserOperation-rail operation
Trust boundary
The user's own address points at third-party code once it delegates, so UGTP verifies the runtime bytecode at the delegate address against the approved implementation before building an operation for that account, and fails closed if it differs.
Inputs
- The account's EIP-7702 authorization
- The signed user operation
Outputs
- The delegate marker an account's code reports
- On-chain execution of the operation
Plan for
- The account is delegated to a delegate that is not the approved implementation
- The network has no chain-level EIP-7702, so no delegation can exist there
- A validation rule of the EntryPoint rejects the operation
Operational ownership
eth-infinitism publishes both contracts and UGTP operates neither; UGTP owns which delegate it accepts and the verification that enforces it.
Approved source
Repository evidence: ugtp-engine api/src/config/eip7702.ts on origin/develop, which pins the EntryPoint v0.9 singleton, the Simple7702Account v0.9 implementation, and its approved runtime codehash.
Third-party
Chainlink price feeds
Value the dollar-denominated part of a fee in the fee token. The fee-collecting contracts read a Chainlink USD feed for the token and for the network's own coin; the gateway fetches no price itself.
Lifecycle stage
Fee preview, and fee collection at execution
Trust boundary
The price is read on chain by UGTP's own contracts rather than passed in with the request, and a feed outside its configured staleness window is rejected rather than used.
Inputs
- The fee token
- The network's native coin
Outputs
- A USD price per unit, at the feed's own precision
Plan for
- A feed reports a stale or non-positive answer, and the operation is refused rather than priced on it
- A token with no usable feed cannot be a fee token at all
- The price moves between the preview and settlement, which is why the reserved figure is the worst case
Operational ownership
Chainlink operates the feeds; UGTP owns which feed backs which token, the staleness window it must answer within, and the decision to fail closed.
Approved source
Repository evidence: ugtp-engine contracts/contracts/UgtpPaymasterV1.sol and UGTPAvalancheExecutor.sol on origin/develop (IAggregatorV3.latestRoundData, StalePrice and InvalidPrice reverts), contracts/src/config/networks.ts (every supported fee token carries a mandatory USD feed), and api/src/features/fee/fee.service.ts (the preview is a read of those contracts).
Official provider documentation ↗