You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To aid investigating market proposals, a tool to speed up configuring a fuzzing sim is needed.
Tools should ease the following tasks:
configuring a market proposal
tuning the agents in the scenario
A FuzzingConfig class should be added which would allow a user to specify the following:
a market proposal JSON
an asset proposal JSON
market parameters to fuzz (related to @TomMcL work)
desired market metrics
One (or more) FuzzingConfig instances can then be passed to a FuzzingScenario which will use the configs to configure the necessary agents and add them to the environment.
The above approach would also allow a "registry" of fuzzing configurations to be built.
Stretch goal: Currently markets in a fuzzing run are segregated, i.e. each market uses it's own asset and it's own agents. At some point it would be nice to investigate cross-margin in the fuzzing runs. May be worth considering how this would effect this FuzzingConfig approach whilst building it.
Description
Market Configuration
Updates to the ConfigurableMarketManager should already allow JSONs to be passed, some considerations will be needed for termination and settlement triggers as well as extracting the relevant fields from the asset proposal JSON.
Agent Configuration
Currently the agents within the FuzzingScenario are tuned to give a sensible market for an ETH/USDT product pair, when using a different pair (e.g. LINK/USDT or BTC/USDT) the market can become unrealistic (e.g. for a LINK/USDT market the spread becomes large, and the traded volume small).
To counter this when creating a FuzzingConfig a user should be able to specify configurable market metrics which are price “agnostic” i.e. markets using the same metrics should behave similarly regardless of the product-pair. Agent parameters would then be automatically calculated to approximately yield these metrics.
The following market metrics should be configurable:
24hr volume (specified in quantum)
would adjust the order sizes of the traders and the MM arrival rates.
stretch goal: allow the volume to be defined by the volume extracted from historic candles.
stretch goal: allow traders to vary their volume over the duration of a sim, i.e. pass a volume_process arg in a similar fashion to the price_process arg.
market-maker inventory (specified in quantum)
would adjust the MMs inventory boundaries.
order-book spread (specified as a %)
specifying would automatically adjust the MMs market kappa.
order-book depth (specified as a %)
specifying would automatically adjust the MMs tick spacing (assume the number of levels is fixed).
order-book shape
not entirely sure how this one will work, want to avoid weird order book shapes.
Example
An instance of a FuzzingConfig object may look something like this:
FuzzingConfig(
asset_proposal_json=""" { "rationale": { "title": "VAP-002 - Create Asset - Tether USD ($USDT)", "description": "## Summary\n\nThis proposal requests to list Tether USDT ($USDT) as a settlement asset on the Vega Network as discussed in: https://community.vega.xyz/t/vap-002-create-asset-tether-usd-usdt/4239.\n\n## Rationale\n\n- USDT is the largest stablecoin and widely used across DeFi.\n- The Name, Symbol & Decimals are all driven by the values of the ERC20 contract so will not be discussed here.\n- Given USDT has 6 decimals and 1 USDT = 1 USD, its conversion to quantum decimals is 1000000\n- The withdrawal delay is set to 1 to act as a buffer in case of a bridge exploit.\n- The lifetime limit is set to $10,000 USD (equivalent) which would be sufficient for alpha mainnet given the high leverage."" }, "terms": { "newAsset": { "changes": { "name": "Tether USD", "symbol": "USDT", "decimals": "6", "quantum": "1000000", "erc20": { "contractAddress": "0xdAC17F958D2ee523a2206206994597C13D831ec7", "withdrawThreshold": "1", "lifetimeLimit": "10000000000" } } }, "closingTimestamp": 1684170000, "enactmentTimestamp": 1684195200, "validationTimestamp": 1684160000 } } """,
market_proposal_json=""" { "proposalSubmission": { "reference": "BTC/USDT-230630", "terms": { "closingTimestamp": "1684846800", "enactmentTimestamp": "1684850400", "newMarket": { "changes": { "instrument": { "name": "BTC/USDT expiry 2023 June 30th", "code": "BTC/USDT-230630", "future": { "settlementAsset": "bf1e88d19db4b3ca0d1d5bdb73718a01686b18cf731ca26adedf3c8b83802bba", "quoteName": "USDT", "dataSourceSpecForSettlementData": { "external": { "oracle": { "signers": [ { "ethAddress": { "address": "0xfCEAdAFab14d46e20144F48824d0C09B1a03F2BC" } } ], "filters": [ { "key": { "name": "prices.BTC.value", "type": "TYPE_INTEGER", "numberDecimalPlaces": "6" }, "conditions": [ { "operator": "OPERATOR_GREATER_THAN", "value": "0" } ] }, { "key": { "name": "prices.BTC.timestamp", "type": "TYPE_TIMESTAMP" }, "conditions": [ { "operator": "OPERATOR_GREATER_THAN_OR_EQUAL", "value": "1688112000" } ] } ] } } }, "dataSourceSpecForTradingTermination": { "internal": { "time": { "conditions": [ { "operator": "OPERATOR_GREATER_THAN_OR_EQUAL", "value": "1688112000" } ] } } }, "dataSourceSpecBinding": { "settlementDataProperty": "prices.BTC.value", "tradingTerminationProperty": "vegaprotocol.builtin.timestamp" } } }, "decimalPlaces": "1", "metadata": [ "base:BTC", "quote:USDT", "class:fx/crypto", "quarterly", "sector:defi", "enactment:2023-05-23T14:00:00Z", "settlement:2023-06-30T08:00:00Z" ], "priceMonitoringParameters": { "triggers": [ { "horizon": "3600", "probability": "0.9999", "auctionExtension": "120" }, { "horizon": "14400", "probability": "0.9999", "auctionExtension": "180" }, { "horizon": "43200", "probability": "0.9999", "auctionExtension": "300" } ] }, "liquidityMonitoringParameters": { "targetStakeParameters": { "timeWindow": "3600", "scalingFactor": 1 }, "triggeringRatio": "0.7", "auctionExtension": "1" }, "logNormal": { "riskAversionParameter": 0.000001, "tau": 0.0001140771161, "params": { "sigma": 1.5 } }, "positionDecimalPlaces": "4", "lpPriceRange": "0.8", "linearSlippageFactor": "0.001", "quadraticSlippageFactor": "0.0" } } }, "rationale": { "description": "## Summary\n\nThis proposal requests to list BTC/USDT-230630 as a market with USDT as a settlement asset on the Vega Network as discussed in: https://community.vega.xyz/.\n\n## Rationale\n\n- BTC is the largest Crypto asset with the highest volume and Marketcap.\n- Given the price, 1 decimal places will be used for price due to the number of valid digits in asset price. \n- Position decimal places will be set to 4 considering the value per contract\n- USDT is chosen as settlement asset due to its stability.", "title": "VMP-001 - Create market - BTC/USDT Future - 2023/06/30" } } } """,
daily_volume=1_000_000,
market_maker_spread=0.001,
market_maker_depth=0.05,
)
The text was updated successfully, but these errors were encountered:
Summary
To aid investigating market proposals, a tool to speed up configuring a fuzzing sim is needed.
Tools should ease the following tasks:
A
FuzzingConfig
class should be added which would allow a user to specify the following:One (or more)
FuzzingConfig
instances can then be passed to aFuzzingScenario
which will use the configs to configure the necessary agents and add them to the environment.The above approach would also allow a "registry" of fuzzing configurations to be built.
Stretch goal: Currently markets in a fuzzing run are segregated, i.e. each market uses it's own asset and it's own agents. At some point it would be nice to investigate cross-margin in the fuzzing runs. May be worth considering how this would effect this FuzzingConfig approach whilst building it.
Description
Market Configuration
Updates to the
ConfigurableMarketManager
should already allow JSONs to be passed, some considerations will be needed for termination and settlement triggers as well as extracting the relevant fields from the asset proposal JSON.Agent Configuration
Currently the agents within the
FuzzingScenario
are tuned to give a sensible market for an ETH/USDT product pair, when using a different pair (e.g. LINK/USDT or BTC/USDT) the market can become unrealistic (e.g. for a LINK/USDT market the spread becomes large, and the traded volume small).To counter this when creating a
FuzzingConfig
a user should be able to specify configurable market metrics which are price “agnostic” i.e. markets using the same metrics should behave similarly regardless of the product-pair. Agent parameters would then be automatically calculated to approximately yield these metrics.The following market metrics should be configurable:
Example
An instance of a
FuzzingConfig
object may look something like this:The text was updated successfully, but these errors were encountered: